Email deliverability: the DNS-side checklist that keeps you inbox

Email deliverability — whether your mail lands in the inbox or the spam folder — is decided by a mix of reputation, content and authentication. The part you have the most direct control over, and the part that fails most quietly, is the DNS side: SPF, DKIM, DMARC, your MX records and reverse DNS (PTR). Get these right and you've cleared the table stakes every major mailbox provider now expects. Get them wrong and no amount of careful copywriting will keep you out of the junk folder. This is the DNS-side checklist.

Why mail lands in spam

Mailbox providers don't ask "is this spam?" so much as "can I trust who this is from?" Authentication is how you answer. The recurring DNS-side reasons legitimate mail gets filtered:

• Failed or absent authentication. No SPF, no DKIM, or a record that fails to validate. Modern providers increasingly treat unauthenticated bulk mail as suspect by default.
• No DMARC, or DMARC misalignment. SPF or DKIM may technically pass for a different domain than the one in the From field — no alignment, no DMARC pass, lower trust.
• Missing or mismatched PTR. The sending IP has no reverse-DNS record, or it doesn't match the forward record. A classic spam signal.
• A broken or stale record. A provider re-IP'd, an SPF include tipped past the 10-lookup limit, a DKIM selector got tidied away in a migration. The setup that worked last quarter silently stopped working.

Note the theme: most of these are not "you set it up wrong", they're "it drifted". That's why the checklist ends with monitoring rather than a one-off pass.

The DNS-side levers

SPF — who may send for you

One TXT record at the apex (and on each sending subdomain), listing your authorised senders. Keep it under the 10 DNS-lookup limit and end it with ~all. Two SPF records, or exceeding the lookup limit, both produce permerror — treated as a failure.

example.com.  TXT  "v=spf1 include:_spf.google.com include:mailjet.com ~all"

DKIM — proof the message is genuine

Cryptographic signing, with the public key published under a selector in DNS. Enable it on every platform that sends as you, use 2048-bit keys, and where the provider rotates keys for you, delegate via CNAME rather than pasting a static key.

DMARC — the policy and the feedback loop

A record at _dmarc that tells receivers what to do with mail that fails, and asks for reports. Start at p=none to gather data, fix unaligned sources, then move to p=quarantine and ideally p=reject. The complete SPF/DKIM/DMARC guide covers the rollout in detail.

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

MX — where your mail comes in

Your MX records point to the servers that receive mail for the domain. They don't authenticate outbound mail, but they signal a real, configured domain — and a domain with no MX records that nonetheless sends mail looks off. Some receivers reject mail from domains with no MX.

PTR — reverse DNS on your sending IPs

For self-hosted mail especially, the IP you send from should have a PTR record that resolves back to a hostname, and that hostname's A record should resolve back to the same IP (forward-confirmed reverse DNS). Mismatched or missing PTR is one of the oldest and most reliable spam signals. If you send through an ESP, the ESP owns this; if you run your own MTA, it's on you and your hosting provider.

The auditable checklist

Run through this and you've covered the DNS-side basics:

• SPF: exactly one record, under 10 lookups, ends ~all, on every sending domain.
• DKIM: signing on by default everywhere, 2048-bit, every selector resolving.
• DKIM delegation: CNAMEs intact where the provider rotates keys for you.
• DMARC: record present at _dmarc, rua= going to a monitored mailbox.
• DMARC policy: at p=quarantine or p=reject once reports are clean.
• Subdomains: sp=reject on parked/non-sending subdomains.
• MX: valid records pointing at your real inbound servers.
• PTR: sending IPs have forward-confirmed reverse DNS.
• Alignment: aggregate reports show no unaligned legitimate sources.
• Monitoring: all of the above is watched continuously, not checked once.

What this checklist deliberately does not cover: warm-up, list hygiene, content, engagement and IP/domain reputation. Those matter too — but they're outside DNS, and no DNS record fixes a bad sending reputation. What clean DNS does do is remove every excuse a filter has to distrust you on technical grounds.

Snapshot now, monitor continuously

For a fast first pass, run your domain through the free email auth audit — a one-off check of your SPF, DKIM and DMARC records. For the wider picture, see the email DNS security docs and the security docs.

Deliverability isn't a one-time fix, because the DNS underneath it drifts: providers re-IP, includes pile up, selectors vanish in migrations, a zone edit drops a record. The audit is a snapshot; DomainOps monitors your SPF, DKIM, DMARC, DNSSEC and CAA records continuously and alerts you the moment one breaks. It watches your posture — it does not send your email or manage your DNS zone — so a silent record failure doesn't quietly tank your inbox placement. When you're ready, start monitoring your domains.