Email for your first product: sending, replies and updates

Write the email jobs before choosing templates

A simple browser game may need only a monitored contact address. A tool with accounts may need verification or recovery messages. A service that finishes work later may need a completion email. These messages should state what happened, what to do next and how to get help. Do not invent an email sequence just because the provider includes an automation builder.

Optional product updates have a different purpose. Ask people whether they want them, describe the likely frequency and provide a way to stop. Creating an account does not have to mean joining every promotional list. Keep the preference separate so someone can stop a digest while still receiving necessary account messages.

Scroll to see all columns →

Set up a real sender and a real reply path

Use a domain you control and follow the sending provider’s DNS verification instructions. Resend, for example, documents domain verification for sending and optional receiving configuration. Sender verification and receiving mail are separate jobs. Preserve existing DNS records unless you know what they do; replacing an MX record can change where incoming mail goes.

Choose a recognizable sender name and an address that fits the purpose. Set Reply-To to a monitored destination when replies should go somewhere else. Send from the production configuration and reply from another account during your test. If nobody will read the receiving address, do not present it as a support inbox.

• Resend domain setup ↗

Make the template useful before making it ornate

Begin with a short subject that explains the event. Put the main action early, include a normal text link as well as a button, and make the message readable without images. Use a simple layout, your actual product name, generous text size and a footer with an honest contact route. Provide a plain-text alternative.

For a hypothetical saved-trip tool, a completion email might say: “Your weekend packing list is ready,” followed by the trip name, a view-list action and an explanation of whether signing in is required. Avoid placing sensitive trip details in a subject line. The link should lead to the correct person’s authorized view, not make a private list public merely to avoid login.

Draft an on-brand transactional email for a packing-list tool after a list is successfully saved. Include subject, preheader, concise heading, one main button, a text-link fallback, a support reply path and a plain-text version. Do not say the person joined a newsletter. Do not include private travel dates in the subject. Identify which template values must be escaped and which URL must be generated by the trusted backend.

Send after the event really happened

Trigger the welcome or completion message after the relevant durable account or product event succeeds. A form click is too early if saving might fail. When a provider webhook retries, your backend should recognize an already handled event so one signup does not produce several welcome emails. Keep credentials on the server.

Store enough delivery state to troubleshoot without copying unnecessary private content into logs. Distinguish queued, provider-accepted, delivered, bounced and complained where those states are available. A successful API response is useful evidence that the provider accepted a request; it is not proof that the person read it or that it reached their inbox.

Test the message as a recipient

Create a real test event using an address you control. Open the message on a phone and a desktop. Check the sender, subject, images, text alternative, button and reply path. Follow the link signed out as well as signed in. If the link expires, explain the recovery path instead of leaving someone with an unexplained error.

For an optional digest, subscribe, receive the intended test message, unsubscribe and verify the preference changes. Confirm that the next audience selection excludes that address. Keep necessary account mail separate from the optional list. Only schedule a weekly digest when you have a reliable content source, a useful editorial promise and a way to stop an empty or broken issue.