A safer website
contact-form handoff.

Start with the right expectation

MessageHop contact intake is a dedicated path for a configured first-party website. It is not the normal sending API, a browser email relay, or a customer-message history feature. A visitor submission can be durably accepted before an internal team reads it; acceptance is not a response-time or inbox-read promise.

Contact-form configuration is currently Admin-managed and site-specific. There is no Customer Console screen for creating a site label, choosing a recipient mailbox, or selecting an email provider. Publishing this guide does not enable a contact form. Ask your approved MessageHop contact or account owner to begin the setup process. Do not point a live form at a MessageHop route until that approval is complete.

Prepare one clear request for each site

Give the accountable setup owner the following facts. They keep the form aligned with the right legal owner and prevent one website from routing to another team.

• The exact public website origin, including whether visitors use a subdomain.
• The Organization, Brand, and Project that own the site.
• The responsible legal entity, approved internal mailbox, and fixed sending identity.
• The proposed visitor fields, their purpose, and whether each is required.
• The live Privacy Policy URL, notice wording, consent/version requirement, retention period, and rights contact route.
• The accountable website owner, test date, and the old form-provider removal plan if one exists.

Do not send a mailbox password, a messaging credential, or a visitor data export with the request. The approved recipient and provider route are stored and used server-side.

Build the visitor experience around clarity

Keep the form small: name, email, optional phone, subject, message, and the policy notice approved for that site are the normal starting point. Use visible labels, native browser validation, keyboard-reachable controls, a clear Privacy Policy link, and a status message that screen-reader users can hear.

On success, say that the request was received and will be reviewed. On a failure, show a general retry message. Do not show provider errors, recipient addresses, tenant names, rate-limit details, or a delivery-status tracker. Do not add attachments or marketing opt-in to this flow unless a separate approved product and legal design covers them.

Test before changing the live website

1. Use synthetic information on the approved non-production or controlled test site.
2. Confirm the form succeeds only from the exact approved origin and that a missing or unapproved origin fails safely.
3. Confirm a repeated browser retry does not create duplicate internal work.
4. Check the internal team receives the safely rendered request through the approved route.
5. Exercise a generic unavailable state, a disabled-site state, and the published rights/deletion route.
6. Check mobile, keyboard navigation, visible focus, text scaling, and the Privacy Policy link before release.

After the owner records the evidence, remove the former browser form vendor endpoint, client-side key, and unused dependency if the old integration had them. Rotate a key if it was exposed beyond its intended public use.

Keep these boundaries intact

• Never embed a MessageHop sending credential, provider key, recipient address, or email-service secret in website JavaScript.
• Never use the authenticated message endpoint for an anonymous website form.
• Never let a browser choose the internal recipient, From address, provider, template, Organization, Project, retention period, or delivery status.
• Do not present a test form, placeholder recipient, or sample success message as a live support channel.

If you need account-specific help, sign in to the Customer Console and use Support. Include the site domain, safe test time, and any request ID you received; do not include credentials, complete visitor messages, or unnecessary personal data.