Email deliverability checklist for 2026 (the 12 things that matter)

The floor for 2026 is documented, dated and enforceable, and it is shorter than most checklists suggest: authenticate, keep complaints low, let people leave, and do not lie about who you are. Everything else on this page is either a way of proving one of those four or a consequence of them. What follows is twelve items, each with the specific command or header that proves it — plus the four items nobody can verify from the sending side, and six rules that circulate on checklists with no published requirement behind them.

The twelve, and the proof each one needs

A checklist item you cannot check is a belief. Each of these has an artefact you can produce.

1. One SPF record, under the ten-lookup budget. Proof: a recursive count of the DNS-querying mechanisms.
2. DKIM signing live mail with a key that exists. Proof: the DKIM-Signature header on a message you sent, plus the selector's TXT record.
3. A DMARC record whose tags say what you believe. Proof: the record itself, read tag by tag.
4. Alignment passing on a real message. Proof: dmarc=pass in Authentication-Results with your domain in header.from.
5. Forward-confirmed reverse DNS and TLS on the connection. Proof: a PTR lookup that resolves back to the same IP, and the Received header on a delivered message.
6. RFC 8058 one-click unsubscribe on every message that needs it. Proof: both headers present in the raw source.
7. Unsubscribes honoured inside two days. Proof: unsubscribe yourself and re-read the suppression list.
8. Spam rate under 0.30%, ideally under 0.10%. Proof: Google Postmaster Tools, when it has data.
9. Bounces classified rather than counted. Proof: the delivery status notification, opened and read.
10. Volume shaped, and you know which throttle is binding. Proof: configured limit versus actual sends, with the constraint named.
11. A tracking domain you own, over HTTPS — or no tracking. Proof: the href in a received message.
12. MX records and a monitored inbox on the sending domain. Proof: an MX lookup and a reply that arrives.

Items 1 to 5: what a receiver evaluates before it reads a word

The first five are binary, cheap and fixable in an afternoon. They are also the only part of deliverability where you are not inferring.

SPF. One TXT record beginning v=spf1, ending -all or ~all. The interesting constraint is not the record's contents but its cost: RFC 7208 section 4.6.4 caps evaluation at ten DNS-querying terms, counting every include, a, mx, ptr, exists and redirect — including the ones nested inside your vendors' records. Cross the cap and receivers return permerror, which means SPF authenticates nothing while your record still reads correctly. Nothing on your side reports this.

DKIM. The failure people expect is a missing record. The failure that actually happens is a selector nobody can find, because DKIM keys live at ._domainkey. and DNS has no way to enumerate what is under a label. Get the selector from the s= tag of a signature on real mail rather than from a setup document. The full procedure is in reading your own authentication records.

DMARC. A record beginning v=DMARC1 at _dmarc. in front of your domain. Two tags decide more than p does: sp, which governs subdomains and silently unprotects them if set to none, and rua, without which you receive no evidence at all.

Alignment. DMARC evaluates whether a *passing* mechanism shares an organisational domain with the address in the visible From header. On most sending platforms SPF authenticates the platform's own bounce domain, so it passes and contributes nothing, and DKIM carries the whole result alone. The only place to observe this is the Authentication-Results header that a receiving server writes on a message it accepted.

Reverse DNS and TLS. Google's sender guidelines require valid forward and reverse DNS and a TLS-encrypted connection from every sender, not only bulk ones. Forward confirmation is the part that gets missed: read the PTR for the sending IP, then resolve the hostname it returns and check you land back on the same address. If you send through a hosted provider, you do not control this and there is nothing to change — but you should know which category you are in before you spend a week on it.

Items 6 and 7: the two headers that decide whether someone complains or leaves

A recipient who wants out has two buttons available. One costs you a suppression entry. The other costs you a complaint that counts against the only ratio Google publishes a number for. Which button they reach for is a technical decision you make.

RFC 8058, published January 2017 as a Standards Track document, defines one-click unsubscribe. It requires two headers on the message:

• List-Unsubscribe containing an HTTPS URI. The RFC is explicit that the header must carry an HTTPS URI for one-click to apply, and a mailto: may be listed alongside as a fallback.
• List-Unsubscribe-Post: List-Unsubscribe=One-Click, verbatim, no variation.

The receiving provider then performs an HTTPS POST to that URI when the recipient clicks the native control. Without the second header the control does not render, and the recipient's remaining exit is the spam button.

Google's sender guidelines require one-click unsubscribe on marketing and subscribed messages from bulk senders, alongside a clearly visible unsubscribe link in the body. Google's own FAQ recommends fulfilling unsubscribe requests within 48 hours; Yahoo's sender best practices state the same requirement as honouring unsubscribes within two days.

Autocloz injects both headers on SMTP sends when the campaign's unsubscribe setting is on, which is the default. It cannot inject them on the API sending modes of Zoho Mail, ZeptoMail or SendCoreX, because those APIs take structured JSON rather than a MIME message and expose no custom-header field — on those paths the visible footer link still works and the RFC 8058 header does not exist. That is a real constraint worth knowing before you pick a sending mode, and it is why SMTP mode is the better choice for campaign traffic.

Items 8 and 9: the two numbers, and which one is actually published

Item 8 is the only ratio a mailbox provider states as a number. Google's guidelines say to keep the spam rate reported in Postmaster Tools below 0.30%, and below 0.10% as a guideline. Yahoo publishes the same 0.3% figure. Both are user-reported spam — the fraction of delivered messages a human marked as junk — not a filter's opinion of you.

Read that number with two caveats. It is reported against Gmail traffic only, and Google withholds data when daily volume is too low, saying only that data might be missing if the total number of messages for a given day is too low, without publishing the threshold. A small cold programme often sees nothing at all.

The arithmetic at low volume is the part that surprises people. A mailbox sending 40 messages a day produces one complaint at 2.5% for that day. The published threshold is not a per-day figure and single days are noise, but it means the ratio is uninformative until you have accumulated real volume — which is an argument for measuring over a window and against reacting to a single bad morning.

Item 9 is a discipline rather than a number. A bounce is a document, not a percentage: a delivery status notification with named fields, and the field that matters is the status code rather than the human-readable text. Treating every failure as one class is how valid contacts get deleted and how genuinely dead addresses get retried forever. The difference between a soft and a hard bounce, read properly sets out the classes and what each one should trigger.

Autocloz's free plan covers 5 users and 10 mailboxes with SPF, DKIM and DMARC monitoring and the warmup ramp included — start free if you would rather have the checks running than remember to run them.

Items 10 to 12: the ones you own and nobody else measures

Volume shape, and which throttle binds. Most people set a daily limit and assume it describes what happens. It rarely does, because several ceilings apply at once and the lowest one wins. In Autocloz a mailbox's configured daily limit is replaced by a ramp value while warmup runs, warmup traffic draws on a share of that same figure, an hourly limit multiplied by the open hours of the sending window forms its own ceiling, and a Monday-to-Friday window cuts the weekly average. Every one of those is individually correct and individually invisible. Before you raise a number, find out which constraint is actually binding.

The tracking domain. Your click-tracking links are a separate reputation entity from your sending domain. On a shared tracking domain you inherit the behaviour of every other sender using it. Open a received message, read the raw href behind a link, and check the hostname belongs to you and the scheme is HTTPS. If it does not, the honest options are to move it to a subdomain of your sending domain or to turn tracking off, and the second is more defensible than it sounds given how little an open actually tells you.

MX and a monitored inbox. A domain that sends but cannot receive is both a recognisable pattern and an operational hole: bounce notifications and replies go somewhere, and if that somewhere does not exist you never see either. dig MX yourdomain.com +short should return something, and a message sent to an address on that domain should arrive somewhere a person reads.

Four of these cannot be verified from your side at all

Being explicit about this is more useful than another item. Four things that matter are structurally unavailable to you.

How a receiver models your domain. Postmaster Tools shows Google's opinion in coarse bands, and only for Gmail, and only above an unpublished volume. Microsoft shows nothing to a sender who does not own the IP. Nobody publishes the model.

Where a specific message landed for a specific recipient. The 250 reply at the end of an SMTP transaction means the receiving server accepted responsibility for the message. The folder decision happens afterwards in a separate system, and nothing in the SMTP conversation reports it. Seed testing approximates the answer by mailing monitored mailboxes; it does not observe your actual recipients.

Whether your engagement signals are being counted. Every provider says engagement matters. None publishes the weighting, and no measurement available to you distinguishes "this signal helped" from "this signal was ignored".

Whether a blocklist listing is the cause of anything. A listing is a fact you can check. Whether the receiver that filtered you consults that list, and with what weight, is not.

Six rules that circulate on these lists with no published source

Each of these appears on most deliverability checklists, including earlier versions of this one. None of them traces to a primary source.

"Keep bounces under 2.5%." No mailbox provider publishes a bounce threshold. The figure is a sending-platform convention. Autocloz's own automatic pause is a 15% floor over a rolling 24 hours, applied to manual campaigns only when the operator has set no per-campaign or workspace threshold of their own, and it requires at least 100 sends in the window before it can fire at all — so tiny samples cannot trip it. That is a safety net against a genuinely bad list, not an assertion that 15% is acceptable.

"30 to 50 a day is the safe number." Widely repeated, never sourced. The provider caps are far higher and the reputational ceiling is unpublished, so any specific number is inference presented as fact.

"Avoid spam trigger words." The word lists in circulation descend from a specific open-source filter's rule set, and the scores involved are small relative to everything else a modern classifier weighs.

"Send on Tuesday at 10am." Recipient behaviour varies by role, industry and timezone, and no provider treats send time as an authentication or reputation input.

"Plain text only." There is no published requirement. What is defensible is the narrower claim: fewer remote resources means fewer things to fetch, and a message that could plausibly have been typed by a person is a better reference class than one built in a design tool.

"Warm up with a peer network." No mailbox provider documents counting engagement from accounts inside a reciprocal warmup pool. Volume shaping is the defensible half of warmup; the bot mail is not.

Keep three artefacts so the next check is a diff, not a repeat

Running this list once tells you the state today. Running it quarterly from scratch will miss the failures that matter most, because the dangerous ones are changes rather than absences — and a fresh eye reading a record for the first time has nothing to compare it to.

Keep three things, in a file, dated.

The raw records, as returned. The literal output of the SPF, DMARC and DKIM lookups, plus the recursive lookup count you calculated. Next quarter the record may be byte-identical and the count higher, because a vendor expanded its own include chain. That is the failure with no symptom, and only a stored number catches it.

One complete raw message source. Headers and all, from a message that actually arrived at a mailbox on a different provider. It contains the Authentication-Results your receiver wrote, the Return-Path your platform used, the List-Unsubscribe pair, the tracking hostname, and the Received chain. Six of the twelve items are checkable from that one artefact, and it captures the state of your sending platform rather than the state of your DNS — which is the half that changes without anyone telling you.

The date you last rotated a DKIM key, and the selector you rotated to. Key rotation is the maintenance task with the longest gap between doing it and needing it, and the artefact that proves you did is a selector name and a date.

The two things worth re-checking weekly rather than quarterly

Most of this list is stable. Two parts are not.

The first is the spam rate, where it is visible to you at all, because it is the only published number you are scored against and because it moves with what you sent last week rather than with what you configured last quarter.

The second is whichever throttle is currently binding your volume. It changes on its own: a mailbox advances through a ramp, a campaign's sending window shifts, someone raises a daily limit without touching the hourly one. A number that was correct on Monday describes a different system by Friday, and the gap between what you configured and what actually left the building is the cheapest diagnostic in outbound.

The order to run these in when you have one afternoon

Sequence matters because the later items are unmeasurable until the earlier ones are true.

Start with items 1 to 4, because a domain that fails alignment is generating clean history that receivers discard on every message. Then item 12, because without MX you cannot see the evidence the next steps produce. Then item 6, since a missing header converts departures into complaints and complaints are the one number you are scored on. Then item 11, which is a single edit. Then item 9, because you now have somewhere for bounces to arrive and a reason to read them. Items 8 and 10 are ongoing measurements rather than tasks, and item 5 is either already true or not yours to change.

You can score a setup against most of this in a browser with the deliverability self-audit checker, and connect a mailbox to have the DNS side re-checked on a schedule through the email channel's built-in domain monitoring.

What this checklist does not cover, and what Autocloz does not do

The whole list governs whether your message is permitted to be considered. It says nothing about whether it deserves a reply. A perfectly authenticated, well-paced campaign to a badly chosen list still fails — it just fails as silence rather than as a spam-folder problem, which is harder to diagnose and easier to blame on deliverability.

Autocloz monitors authentication records and re-checks stale ones on a background sweep, injects the RFC 8058 headers on SMTP sends, classifies bounces, and pauses campaigns whose bounce rate crosses a threshold with a sufficient sample behind it. Its placement seed tests report three verdicts and no others: inbox, spam, missing. A Promotions result is structurally unavailable, since the probes are collected over IMAP and Gmail's category tabs are not IMAP folders, so a message sitting in Promotions is read as inbox. And the tests fire when an operator asks for one, not on a schedule.

It does not sell contact data or bundle a lead database, so list provenance is yours. It cannot see inside any receiver's classifier, and neither can any tool that says it can. If you are comparing what a checklist like this costs to run in-house against a dedicated sending platform, the feature-by-feature comparison with Instantly is the honest version of that question.