Transactional email that arrives: DNS, templates and ownership

A transactional mail that does not land is not a design problem. It is a broken product. The customer cannot get in. They cannot see the receipt. They think you never answered the booking. Support gets the same case you already 'sent'. You do not have a mail problem. You have a trust problem you measure as tickets.

Teams react the wrong way. They rewrite the subject. They add a logo. They switch from one 'smart' provider to another with the same missing DNS. They turn a marketing tool on for the same From because 'then we have everything in one place'. Inboxes do not look up your Figma. They look up whether you may send as the name you claim.

It is also an auth and billing question. Magic link and reset are the door in. Invoice and receipt are the door to 'you owe' and 'you paid'. If Stripe sends one and you send the other from a domain you cannot sign, the customer has two senders and one doubt. The billing model can be right, and the mail can still be the lie in the chain.

We write this because 'email hits spam' has become a tool purchase on top of the same zone. An honest setup is boring: you know which domain sits in From, which keys sign, what happens on bounce, and which mails you should not send because Stripe or the auth provider already does. Without that sentence you have a template. You do not have delivery you can defend.

Transactional email is mail the product owes the user because they did something, or because you owe them a state: reset, confirmation, receipt, 'your link', 'the payment failed', 'the invite is waiting'. It is expected. It is time-critical. It must not be a newsletter you put another badge on.

Marketing mail is mail you would like them to open. Different purpose, different consent, different reputation. When you mix them on the same From and the same IP pool, the reset inherits the reputation your campaign built. That is the common reason 'it worked in staging' and dies in production after the first blast.

DNS is not decoration. SPF says who may send as the domain. DKIM says the body was not tampered with on the way. DMARC says what the receiver should do when those two do not match — and whether From may look like you when the signature sits somewhere else. Alignment is the word most teams skip: the visible From and the signing identity must belong together. Otherwise pretty records do not help.

Ownership is the part the template debate hides. Who can change From? Who has DNS? Who sees that a reset bounced? Who is allowed to send 'a quick newsletter' from the same domain? If the answer is 'marketing has the tool, engineering has the code, nobody has bounces', you do not have a mail setup. You have three assumptions.

Start in the zone's records, not in the HTML. Find the From the user sees. Find which service actually sends. Check that SPF points at that service — and not at five historical ones you forgot. Check that the DKIM key matches what the provider shows now, not what you set two years ago. Check DMARC: p=none is a mirror, not a policy. Fine while you look. It is not 'we have DMARC' if you never move on, and never read the reports.

Then headers in a real inbox. Not your own, which already knows you. A fresh address at a large provider. Read Authentication-Results. Read whether SPF and DKIM match, and whether DMARC passed. Read which domain signed. If you cannot explain a fail, the template change is guesswork.

Only then copy and layout. Yes, 'RE: invoice' and large images without text can hurt. Yes, a URL that does not match the sender looks like phishing. But a pretty letter on a domain you may not send as is still a letter the filter is allowed to doubt. Conversely, a dull, short reset on an aligned domain can land even if it is ugly.

List-unsubscribe, open pixels and tracking domains belong to marketing. On a reset they are noise, and often a signal you do not want to send. Keep transactional mail short: why it came, what the user should do, a path that does not require them to log in to read the warning itself. Save the campaign for the pipe you have consent for.

Stripe can send receipt, invoice and 'update your card'. That is often the right call. Then you should not also send a homemade 'thanks for your purchase' from a domain you have not put DNS on. Two mails about the same payment are not better service. They are two chances for one to hit spam and the other to confuse. Decide who owns each type. Write it down. Turn off the one you do not want to own.

Auth providers send reset and invite unless you have asked to do it yourselves. 'Taking over' those mails without taking over DNS and bounce handling is how you get a prettier letter that does not land. If you send the magic link from Next.js yourselves, the route and the secret are yours — and so are From and DKIM. A fetch to an ESP in a Route Handler is not a setup. It is a call, until the zone's records match.

On Next.js the usual lie is that you have control because you own the repo. A server action sends via an SDK, env points at a test domain, and production inherits a From someone set in a dashboard. Or you render an HTML string in React and forget the text part exists. Inboxes and accessibility want a text body. Controlled HTML is fine. HTML alone is a signal spam filters know.

WordPress shops and 'a plugin that sends' fail in the same place with another face: WooCommerce or an SMTP plugin with a shared key, no DKIM, and a sender that looks like webmaster@hosting. The check is the same. Inventory first. DNS next. Template last. A new plugin on top of a zone you do not own is a fourth pipe.