A deliverability checklist that is actually in order

Most deliverability advice is a list of everything that exists. That is not useful at 9am when somebody says their invoice never arrived. This is the same list in the order the answer is usually found, which is roughly the opposite of the order it is usually written.

1. Reverse DNS

The single most common answer, and the least interesting. Your IP must resolve back to a hostname, and that hostname must resolve forward to the same IP. Not “a hostname” — your mail hostname.

dig +short -x YOUR.IP.ADD.RESS
dig +short mail.example.com

If those do not agree, stop reading and fix it. Many receivers reject or heavily penalise mail from an IP with no PTR before they look at anything else.

2. SPF, and specifically whether it is hard fail

Check the record exists, check it includes the IP actually sending, and check you have not published two of them — two SPF records is a permanent error, not a merged policy.

The subtle version: if you send through a relay, your SPF must include it. A -all policy with a relay you forgot is mail that fails authentication from a sender you authorised yourself.

3. DKIM, and whether the selector matches

The signature carries d= and s=. Look up <selector>._domainkey.<domain> and check the published key matches the one signing. The failure mode people miss is a rotated key whose old selector was deleted too early: mail still in transit, signed with the old selector, now unverifiable.

4. DMARC — but read the reports rather than the record

Everyone checks that the record exists. Almost nobody reads the aggregate reports, which is where the answer usually is: they tell you exactly who is sending as you and what passed. If you have never opened one, you have been guessing.

They arrive as gzipped XML in a mailbox nobody opens, which is why nobody reads them. Anything that parses them is worth more than another blog post about the record syntax — ours ingests them and shows them as a dashboard.

5. Blocklists

Check the IP on the majors. If you are newly listed, find out why before requesting delisting — delisting without fixing the cause gets you relisted and makes the next one harder.

6. TLS

MTA-STS says “always use TLS with me”, and TLS-RPT is how you find out when someone could not. Publish both. The reports are the only way to learn that a receiver has been failing to connect securely, which otherwise looks exactly like nothing happening.

7. Content and volume — last, not first

Only after all of the above. A new IP sending a hundred messages on its first day looks like exactly what it looks like. Warm up: low volume to engaged recipients, growing over weeks. And check the obvious content problems — link shorteners, mismatched display names, a single image and no text.

The order matters

Nine times in ten the answer is in the first four, and they are all DNS. That is why the useful product feature is not “a spam score” but generating those records, verifying they are published, and telling you when one changes underneath you — which is what the deliverability tooling exists to do. The product ships a run-book that walks the same list in the same order and in more detail; it is in the documentation once you have an install to run it against.