<p>A contact form has two users: the visitor who needs a clear result and the site owner who needs a trustworthy message. I keep email delivery behind an Amplify Function so browser code never receives provider credentials. The server route validates and stores a small payload, then a DynamoDB stream invokes the function to send the notification. The interface confirms that the submission was accepted and queued; it does not claim that email delivery has completed.</p><p>I treat submission acceptance and email delivery as separate events. A 200 response from an API should mean the workflow reached a defined state, not that the handler swallowed an exception.</p>

<h2>Minimize the submitted fields</h2>

<p>I ask only for the information needed to reply: a name, reply address, subject or service choice, and message. Server-side validation repeats browser checks because a caller can bypass the form. Length limits protect logs and downstream providers from oversized input.</p><p>I normalize whitespace and reject malformed values. I do not accept a recipient address from the browser; the destination belongs in server configuration. Hidden fields, timing checks, and rate limits can reduce simple abuse without collecting more personal data.</p>

<h2>Put delivery in a focused function</h2>

<p>The <a href="https://docs.amplify.aws/react/build-a-backend/functions/set-up-function/">Amplify Functions documentation</a> shows how Amplify defines a function resource and handler. I give the function one job and grant only the permissions required to send the notification. It does not need broad data access if it only sends mail.</p><p>The handler records a request ID, outcome, and provider error category. It does not log the message body or full email address. Those fields create unnecessary privacy exposure in long-lived logs.</p>

<h2>Keep addresses and credentials out of the client</h2>

<p>The owner address and provider configuration stay in environment-specific server settings. Secret values use Amplify's secret mechanism rather than plain environment values that can appear in build artifacts. The <a href="https://docs.amplify.aws/react/build-a-backend/functions/environment-variables-and-secrets/">Amplify environment variables and secrets documentation</a> explains that distinction.</p><p>I set the verified sender address under my control and use the visitor's address as reply-to after validation. Using user input as the sender can fail domain authentication checks and makes spoofing easier.</p>

<h2>Return useful states to the visitor</h2>

<p>The interface needs pending, accepted, and validation-error states. In this asynchronous workflow, accepted means the record was stored and the notification was queued; later delivery failures belong in server-side retries and monitoring. I disable duplicate submissions while the request is pending and restore the form when submission fails.</p><p>I avoid revealing provider internals. The visitor gets a safe next step, while the server retains a request ID that can be matched to sanitized logs.</p>

<h2>Plan abuse and retry behavior</h2>

<p>Retries must match the failure. A timeout may justify one bounded retry; an invalid recipient or rejected sender configuration needs intervention. Blind retries can send duplicate email, so I attach an idempotency key or record the submission state when the workflow requires stronger delivery guarantees.</p><p>For higher-volume forms I queue delivery and acknowledge receipt after the queue accepts the job. A small site may use a direct function call, but it still needs rate limits and alarms.</p>

<h2>Test the complete path</h2>

<p>I test valid input, invalid input, provider rejection, timeout, duplicate submission, and a request that bypasses the browser. I verify that production sends to the approved mailbox and staging uses a safe destination.</p><ul><li>No secret or recipient is shipped to browser code.</li><li>Server validation has length limits.</li><li>Logs omit message content.</li><li>The visitor sees delivery failures.</li><li>Alerts cover repeated send errors.</li></ul>

<h2>Need help with Amplify?</h2>

<p>Terry Hunt Dev builds server-backed forms and integrations as part of its <a href="/services/aws-development">AWS development services</a>. If your contact form loses messages or exposes delivery logic in the browser, use the <a href="/contact">contact form</a> to request a review.</p>

Build an Amplify Gen 2 contact form email workflow with server-side validation, SES delivery, safe reply-to handling, abuse controls, and useful errors.

Sending Contact Form Email with Amplify Gen 2

Build an Amplify Gen 2 contact form that validates input, sends server-side email, protects secrets, and reports delivery failures.

AWS SES Resources & Benchmarks

Sending Contact Form Email with Amplify Gen 2

Need hands-on help with AWS SES?