InfrastructureLesson 3 of 48 min

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.

The three records that vouch for you
  1. SPF
    Lists who is permitted to send mail as your domain. Without it, anybody can claim to be you, and receivers assume somebody is.
  2. DKIM
    Signs each message with a key published on your domain. Proves the mail genuinely came from you and was not altered in transit.
  3. 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

Show field notes toggles a search param the loader reads. With it off, the slow promise is never created, so nothing streams.