Email that quietly does not arrive
The one failure that hides from you specifically, because it always works when you test it.
Your app sends email whether you planned for it or not: password resets, sign-up confirmations, receipts, the notification somebody is sitting there waiting for. Sending it is a few lines of code and they were probably written for you. Getting it delivered is a separate problem, it is not a coding problem, and nothing in your code will tell you that you have failed at it.
Mail is not so much delivered as judged. When a message arrives, the receiving provider decides in a fraction of a second whether it looks like something its user wants, and it has never heard of you. So it asks the domain you claim to be sending from whether you are allowed to. Three records answer that question, and if your domain has none of them, silence is the answer.
- SPF
Lists who is permitted to send mail as your domain. Without it, anybody can claim to be you, and receivers assume somebody is. - DKIM
Signs each message with a key published on your domain. Proves the mail genuinely came from you and was not altered in transit. - DMARC
Says what to do when the first two fail, and is the only reason you ever find out that any of this is happening.
All three are DNS records, living in the same place your domain uses to point at your host. Your email provider generates the exact values and tells you what to paste where. It is fifteen minutes, once, and skipping it is the most common reason a new app’s password resets land in spam.
Transactional, they asked for it
- Triggered by something the user just did
- Resets, receipts, confirmations, alerts
- Expected within seconds, so failure is loud
- Stops counting as transactional the moment you add an offer to it
Marketing, you decided to send it
- Sent to a list, on your schedule
- Needs consent and an unsubscribe link that works
- Complaints here poison delivery of everything else
- Worth sending from a separate subdomain entirely
If somebody asked for a password reset ten minutes ago, how would I know whether it reached them?
For most new apps the honest answer is "I would not, unless they emailed me". Every sending provider has a dashboard showing delivered, bounced and marked-as-spam, included at no extra cost, and almost nobody opens it until the day it matters.
What to remember
- Sending mail is easy; being delivered is a separate problem with its own setup.
- SPF, DKIM and DMARC are DNS records that let a stranger’s mail server trust your domain.
- Transactional and marketing mail should never share a reputation.
Terms in this lesson
Field notes
Loaded from a deliberately slow source. The lesson above was already readable while this was still travelling. That is streaming, and it is the same trick a chat interface uses.
The digest that stopped for five weeks
A weekly email job silently stopped running after an infrastructure change. Nobody noticed, because a job that does not run produces no error. It was discovered when a customer asked whether they had been unsubscribed.
Why you alert on missing success
Everyone retried at once
A service had a brief wobble. Every client retried immediately, then again, then again. The retries were far more traffic than the original load, and the service never got a quiet moment to recover. The outage lasted forty minutes longer than the fault did.
The thundering herd
resolved in 900ms · region iad1
Hide field notes toggles a search param the loader reads. With it off, the slow promise is never created, so nothing streams.