An email deliverability guide for developers: authentication, reputation and hygiene

Email deliverability is the share of your mail that reaches the inbox rather than the spam folder or nowhere at all. This email deliverability guide is about the gap between two numbers that are easy to confuse: delivery, which the receiving server tells you about, and placement, which it does not.

A message that is accepted produces a delivered event. That event says the receiving server took responsibility for it. It does not say the message was shown to anybody, and a message filed straight into spam produces exactly the same event as one that landed at the top of the inbox. Nobody sends you a webhook when you are filtered.

So deliverability work is inference. You watch the things that correlate with placement — bounces, complaints, engagement, authentication results, the reputation dashboards the large providers publish — and you keep the sending side clean enough that the inference rarely matters.

It is worth being clear about what is and is not in your control. You control who is on the list, what the message contains, which domain it comes from, and how quickly you stop mailing somebody who bounced or complained. You do not control the filter, and no amount of reading about it will give you a rule that holds next quarter. Every recommendation below is one of the four things you do control, which is also why none of them is a trick.

SPF says which servers may send for your domain. DKIM signs the message so it can be checked after it arrives. DMARC says what to do when neither lines up with your From address, and asks receivers to report what they saw. The article on the three records goes through each in detail; what matters here is what they buy you.

They buy you consideration. Passing all three means the receiving server believes the message is from who it says, which is the precondition for everything else and no more than that. A perfectly authenticated message from a domain with a bad complaint history goes to spam, correctly.

Sender reputation is a receiving provider’s running judgement about you, and it is scored on your domain before it is scored on your IP address. Domains are harder to change than addresses, so they are the more useful identity to judge, which is why a new domain starts with no history and a well-used one carries its past with it.

Two consequences. First, inbox placement for a brand new sending domain improves with a ramp rather than a launch: start with the recipients most likely to open and grow daily volume over a couple of weeks. Google’s guidelines say the same thing — send at a consistent rate, avoid bursts, and watch the domain’s reputation as the volume grows.

Second, most senders should not buy a dedicated IP. A dedicated address has no reputation until you build one, and low or uneven volume from a cold address does worse than the same mail from a well-run shared pool. Consider one when your volume is high enough and steady enough that the pool is diluting your own good behaviour, not before.

Some of this is required by the large providers and some is simply what well-behaved mail looks like.

• A text part beside the HTML. A message that is one large image with no text is a recognisable pattern, because it is what content filters cannot read.
• One-click unsubscribe on subscribed mail. RFC 8058 defines the header pair, and the large providers expect bulk senders to support it.
• Links on a domain with a history. A tracking domain registered last week, or a public URL shortener, is a signal you do not want attached to your mail.
• A From address a human recognises. Consistency matters more than cleverness: the same name and the same address, message after message.

List-Unsubscribe: <https://acme.example/u/8f2c>, <mailto:unsubscribe@acme.example>List-Unsubscribe-Post: List-Unsubscribe=One-Click

Rasket sets both headers on every broadcast. The one thing not to do is add them to transactional mail: an unsubscribe control on a receipt invites somebody to opt out of the proof they were charged.

The other half of content is consistency. Filters are pattern matchers, and a sender whose messages look the same week after week — same From address, same template, same link domain, a similar volume at a similar time — is a sender whose next message is easy to classify. A redesign that changes all four at once is not a deliverability problem in itself, but it does mean the next week of data is worth watching more closely than usual.

Nothing else on this page matters as much as who is on the list. Most deliverability problems are list problems wearing a technical costume.

1. Confirm the address before you mail it regularly. One message the recipient has to act on proves the mailbox exists and that somebody reads it. It is the single most effective control there is.
2. Suppress bounces and complaints automatically. The moment the event arrives, not in a weekly job. The bounce article covers which kind suppresses immediately and which gets a window.
3. Remove the disengaged. Somebody who has opened nothing in a year is more likely to become a spam trap than a customer, and removing them improves almost every rate you measure.
4. Never import a list you did not build. A purchased list is a bounce rate and a complaint rate in one transaction, and the damage lands on the domain your receipts go out from.

Four, weekly, per sending domain.

• Bounce rate. Bounces over attempted sends. Watch the trend rather than an absolute threshold; a climb means the list is decaying faster than you clean it.
• Complaint rate. Google asks senders to keep the spam rate reported in Postmaster Tools below 0.3%. Alert at a fraction of that, because by the time you cross it the filtering has already changed.
• Delivery rate. Accepted over attempted. A drop that is not matched by a bounce spike usually means something upstream refused you before the message was even offered.
• Engagement. Opens are a noisy signal and clicks are a better one, but both are relative measures: what matters is this week against last, per stream.

The metrics endpoint reports all four, broken down by period, domain, message or broadcast. Beyond your own data, the large providers publish reputation dashboards for senders, and DMARC aggregate reports tell you what receivers saw from anybody claiming your domain — including the systems you had forgotten were sending as you.

Reputation is scored per sending domain. If your campaigns and your password resets go out from the same one, a campaign that draws complaints drags down the resets beside it, and the failure is invisible until somebody cannot get into their account.

A subdomain each is the fix, and it costs one extra domain to verify. Sending campaigns from one and product mail from another means a bad campaign costs you campaigns. The article on the two kinds covers where the line actually sits, which is less obvious than it sounds once a receipt starts carrying a recommendation.

1. SPF, DKIM and DMARC published, with at least one of the first two aligned.
2. DMARC at the monitoring policy, with reports going somewhere a human reads.
3. A 2048-bit DKIM key, and a return path on your own subdomain.
4. Product mail and campaigns on separate sending subdomains.
5. Bounces and complaints suppressed automatically from the webhook.
6. Confirmed opt-in for anything that is not transactional.
7. One-click unsubscribe on subscribed mail; none on receipts.
8. A text part on every HTML message.
9. Bounce, complaint and delivery rates on a weekly review, per domain.
10. New domains ramped rather than launched.