The 12 emails every product has to send

Strip any product down to the messages it cannot skip and you find the same twelve emails, every time. Each one has a job, a deadline, and a way of failing that only shows up in production. This is the reference list: what triggers each email, what belongs in it, and the mistake teams make with it.

Identity emails

1. Verify your address

Sent the moment someone signs up with an email address. One link or one code, an expiry, and nothing else competing for attention. The classic failure is burying the link under a welcome pitch: the reader came to click one thing, so give them one thing.

2. Welcome

Sent after verification, not instead of it. This is the only email on the list that is allowed to sell, and even here the best ones teach instead: the first three steps, one link each. If your welcome email and your verification email are the same message, split them.

3. Password reset

The email with the strictest deadline on the list. A reset link that takes two minutes to arrive reads as a broken product, and the user who requested it is already sitting on the login page. Single-use link, short expiry, and a plain sentence for the person who did not request it. Never confirm or deny whether the address has an account in the email subject; that leaks membership to anyone who can type an address.

4. Magic link

A password reset that happens every session, which means every property of the reset email matters more: speed, single use, short expiry. The failure mode unique to magic links is the corporate link scanner that clicks the link before the human does, burning a single-use token. Either allow a second use within a short window or make the landing page confirm with a button press.

5. One-time code

The code beats the link when the user is on a different device from their inbox. Put the code first, in the subject if you can: 483920 is your ZevSend code lets the OS surface it without the app being opened. Expire it fast and say the expiry in the message. A code that arrives after it expires is worse than no code, so this email deserves your fastest sending path.

Money emails

6. Receipt

Sent immediately after any charge. Amount, what it was for, the last four digits of the method, and where to get help. Receipts get forwarded to accountants and pasted into expense tools, so they should render as plain readable text without images. This is also the email people search their inbox for months later; put the product name and the amount in the subject.

7. Invoice

The receipt’s formal sibling: numbered, dated, addressed to a legal entity, and attached or linked as a PDF that survives printing. If your customers are businesses, the invoice email is a compliance artifact, not a courtesy.

8. Renewal reminder

Sent far enough before the charge that cancelling is realistic. The teams that skip it save a support ticket this month and buy a chargeback next month. State the amount, the date, and the cancel path in one screen of text.

9. Payment failed

The one email on this list that directly protects revenue. Say what failed, what happens next, and give one link to fix the payment method. Send it on a schedule, not once: the first attempt catches typos, the third catches expired cards. Keep the tone factual; the reader has not done anything wrong.

Team and safety emails

10. Invite

Someone added a teammate; the teammate got an email from a product they have never heard of. Name the person who invited them and the workspace they are joining above everything else, because this email has to survive the "is this phishing" glance. Expire invites and show who has not accepted.

11. Security alert

New device, new location, password changed, recovery email changed. The rule: notify the OLD address about changes to the address, and never include a login link in a security alert, because that trains your users to click login links in security-shaped emails, which is exactly what phishing is.

12. Account deletion

Confirm the request, state what will be deleted and when, and give a recovery window. This is the last email you will ever send this person; a graceless one is a review, a graceful one is sometimes a return.

The rules that cut across all twelve

• These are transactional emails. Keep them off the domain or subdomain you use for marketing, so a newsletter complaint never drags a password reset into spam with it.

• Every one of them needs a reply path a human reads. A no-reply@ address on a payment-failed email is a support ticket you refused to receive.

• Retries must be idempotent. The user who clicks "resend code" three times should get the newest code, not three racing ones.

• Test rendering in Gmail and Outlook both. The twelve above are exactly the emails where a collapsed layout costs money or access, not clicks.