Sending Email From Your App Without Landing in Spam

The first time it happens it looks like a mystery. Password resets reach your own inbox in seconds. A customer says they never got one. You check the logs and the message was accepted, queued and delivered. It was delivered — into a spam folder, or into wherever Gmail files the things it has decided not to show anybody.

Deliverability has a reputation for being unknowable. It is not. There are three DNS records, a short list of requirements the large mailbox providers have now written down explicitly, and one architectural decision that nearly every team gets wrong on the first attempt. Those three things account for most of the cases we have seen.

The three records, and what each one proves

They are often described as though they were three versions of the same security measure. They are not. Each answers a different question, and a receiving server needs all three answers.

Record	What it proves	Where it lives
SPF	This server is permitted to send for this domain	A TXT record on the domain itself
DKIM	This message was signed with a key you published, and was not altered in transit	A TXT record at selector._domainkey
DMARC	What to do when the first two fail, and where to send the reports	A TXT record at _dmarc

In practice they look like this, and whichever provider you send through will hand you the exact values:

example.com.                TXT  "v=spf1 include:amazonses.com -all"
pm._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."
_dmarc.example.com.         TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

The part carrying the most weight is not any single record but the relationship between them, called alignment. A message can pass SPF for one domain while displaying an entirely different domain in the From line, which is the gap phishing walks straight through. DMARC closes it by requiring the domain a person actually sees to match either the SPF domain or the DKIM domain. Google and Yahoo both state that requirement in those words.

SPF has a limit that catches people out: a maximum of ten DNS lookups when the record is evaluated. Every include: costs at least one, and some providers' includes contain includes of their own. Add a fourth or fifth tool and the record quietly stops evaluating, which to a receiver looks the same as not having one.

What Gmail and Yahoo now require in writing

These used to be informal expectations passed around in forum threads. They are published requirements now, which makes them checkable rather than folklore. For anyone sending more than 5,000 messages a day to Gmail accounts, Google requires SPF and DKIM, a DMARC policy on the sending domain, alignment between the From domain and one of the two, a TLS connection for transmission, and valid forward and reverse DNS for the sending address. Marketing and subscribed messages must support one-click unsubscribe and carry a clearly visible unsubscribe link.

Then there is the number that governs everything else. Google asks senders to keep their reported spam rate below 0.30%, recommends staying under 0.10%, and says you should avoid ever reaching 0.30%. Yahoo applies the same threshold, calculated on mail delivered to the inbox, and asks that unsubscribes are honoured within two days.

Read those thresholds as a ratio rather than a percentage and the effect becomes obvious. Three complaints per thousand messages is the ceiling. On a modest list, that is a handful of people having a bad morning.

The decision most teams get wrong

Here is the mistake, and it is close to universal in a first implementation: password resets, receipts and the monthly newsletter all go out from the same domain.

Reputation attaches to the sending domain. The newsletter is the mail people mark as spam, because a newsletter is a thing you can grow tired of. A password reset is mail somebody asked for thirty seconds ago, and it is worthless if it arrives an hour late in a junk folder. Sharing a domain means the newsletter's complaint rate decides whether your users can log in.

So split them. The usual arrangement is transactional mail from a subdomain such as mail.example.com and marketing from news.example.com, each with its own DKIM key and its own reputation. Postmark's message streams exist for this reason and every serious provider has some version of it. If you take one thing from this article, take this: it costs nothing and it prevents the worst failure.

What sending actually costs

The figures below are published prices at the time of writing, and they move far more often than the technical requirements do. Treat them as the shape of the market rather than a quotation.

Provider	Free allowance	Entry paid tier	Suits
Resend	3,000 a month, capped at 100 a day	$20/month for 50,000	Products that want to be sending within the hour
Postmark	100 a month, with no overage	$15/month for 10,000, then $1.80 per 1,000	Transactional mail where arrival time matters
Amazon SES	Credits for new AWS accounts rather than a standing allowance	$0.16 per 1,000 messages, plus $0.12 per GB of attachments	High volume, and a team content to build the rest

The gap between the managed services and SES is roughly an order of magnitude, and what the difference buys is everything around the send: templates, suppression lists, bounce handling, dashboards, and somebody to talk to when a domain gets blocked. At a few thousand messages a month that gap is a couple of pounds and not worth a minute's thought. At several million it is a salary.

One SES detail to know before you plan around it: new accounts sit in a sandbox permitting 200 messages per 24 hours at one message per second, and only to verified addresses. Leaving the sandbox is a support request, and it is not instant. Do not find this out on launch day. The same forward planning applies to any outside dependency you build on — the questions we ask about whether a free API is worth building on apply just as well to the service that sends your mail.

The part nobody instruments

Most teams ship email as fire-and-forget: call the API, check for a success response, move on. That response means the provider accepted the message, not that a human received it. Everything interesting happens afterwards, asynchronously, and only reaches you if you asked to be told.

Three things are worth wiring up on day one:

• Bounce webhooks. A hard bounce means that address will never work. Continuing to send to it is the behaviour that damages a sending reputation fastest, so record it and stop.
• Complaint webhooks. Somebody pressed the spam button. That event should suppress future marketing to the address permanently, and if it lands on transactional mail you have a product problem rather than an email one.
• A suppression list you own. Providers keep their own, but if you ever change provider that list is the asset. Losing it means starting again and reintroducing every bad address on the first send.

These are the same class of signal as an application exception: something failed after the request finished and nobody will mention it unless you asked. If you already run error tracking in production, route delivery failures into it rather than building a second dashboard nobody opens.

What we would do first

Roughly in order of return on the time spent:

1. Publish SPF, DKIM and DMARC with the policy at p=none and a reporting address that reaches a person. Nothing changes for senders yet, and the reports start arriving.
2. Read a fortnight of DMARC reports. You will find a sender you had forgotten about. Everyone does.
3. Split transactional from marketing onto separate subdomains before either has meaningful volume. Doing it later means warming a new domain from nothing.
4. Wire bounce and complaint webhooks into the alerting you already have, and keep your own suppression list.
5. Tighten DMARC to quarantine, then reject once the reports are clean. This is the step that actually stops other people spoofing you, and the one most teams never get round to.

None of it is more than an afternoon's work. What makes it feel harder than it is, is that email failures are invisible by default: the send succeeds, the log is green, and the only person who knows is the customer who gave up and went somewhere else.