The five checks and what each one proves
Deliverability is not one setting. It is a stack, and receivers evaluate it in a fixed order during the SMTP conversation. This snapshot walks that same order.
- MX — where mail for your domain is delivered. We fetch every MX record and resolve each named host to an address. Records that point at hostnames with no A or AAAA record are the single most destructive misconfiguration in mail, because every delivery attempt fails before a connection is opened.
- SPF — which servers may send as your domain. We read the
v=spf1TXT record at the apex, then recursively follow everyinclude:andredirect=to count the DNS lookups a receiver would perform. Anything over ten is a PermError, and SPF then fails for every message you send. - DKIM — the cryptographic signature on your mail. DNS gives no way to enumerate selectors, so we probe roughly twenty published defaults (
default,google,selector1,selector2,k1,s1, and so on) and parse any key we find with a real ASN.1 parser to report its true size. - DMARC — what receivers should do when SPF and DKIM fail to align. We read
_dmarc.<domain>, parse every tag, and scorep=rejectabovep=quarantineabovep=none. - PTR — reverse DNS on the mail server address, plus a forward-confirmation round trip. Microsoft and Yahoo reject or throttle mail from addresses without matching rDNS.
How the score is calculated
Every point is tied to an observable query outcome. Nothing is estimated and there is no fudge factor, so two people checking the same domain a second apart get the same number.
Read the full explanation of email deliverability test results ↓Show less ↑
| Check | Max | Full marks require |
|---|---|---|
| MX | 25 | MX records exist and at least one host resolves, or a null MX ("0 .") is published (15 if MX records exist but no host resolves) |
| SPF | 25 | Exactly one record, ten or fewer lookups, ending in -all (22 for ~all, 12 for neutral, 5 for a PermError-class fault) |
| DKIM | 20 | At least one selector with a parseable key of 1024 bits or more (12 if every key found is weak or revoked) |
| DMARC | 25 | p=reject at pct=100 (20 for quarantine, 12 for p=none, 5 for malformed or partial) |
| PTR | 5 | PTR exists and forward-confirms to the same IP (3 if present but not confirmed) |
Grades follow the total: A at 90 or above, B at 80, C at 65, D at 50, F below that. The weighting reflects consequence rather than effort — a missing MX record stops mail entirely, while an unconfirmed PTR merely costs you reputation points, so they are worth 25 and 5 respectively.
Fixing the findings, in order
No MX records, or MX hosts that do not resolve
Nothing else matters until this is right. Add MX records pointing at hostnames that resolve to real addresses, with the primary at the lowest priority number. Never point an MX record at a CNAME — RFC 2181 §10.3 forbids it, and several large receivers refuse to follow it. Use the MX lookup to confirm the fix has propagated.
SPF PermError from too many lookups
This is the most common silent killer. Each include:, a, mx, exists:, ptr, and redirect= costs one lookup, and includes nest — a single include:_spf.google.com costs four on its own. Past ten, receivers stop evaluating and return PermError, which most treat as an outright SPF failure. Remove providers you no longer use, replace include: entries with the ip4: ranges they expand to where the provider publishes stable addresses, and re-check with the SPF checker. The PermError guide walks through a real flattening.
No DKIM key found
This finding is a warning rather than a failure for a reason: DNS cannot list the selectors under a domain, so we can only probe common names. If you use a custom selector we will not find it. Open a message you sent, read the s= tag from its DKIM-Signature header, and check that selector directly with the DKIM checker. If you genuinely have no DKIM, enable it in your sending platform — every major provider now offers it as a settings toggle plus one or two DNS records.
DMARC missing or stuck at p=none
Since February 2024 both Gmail and Yahoo require a DMARC record on any domain sending bulk mail, and p=none satisfies that requirement while providing no actual protection. The correct path is: publish p=none with a rua= address, read aggregate reports for two to four weeks until every legitimate source aligns, move to p=quarantine, then to p=reject. Build the record with the DMARC generator and read p=none vs quarantine vs reject before you move policy.
Missing or unconfirmed PTR
Reverse DNS is set by whoever owns the IP address — your hosting provider or cloud vendor — not in your own zone file. Ask them to point the PTR at a hostname you control, then publish a forward A record for that same hostname back to the IP so the pair confirms. Use the same name in your MTA's HELO/EHLO. The VPS PTR guide has the provider-by-provider steps.
Reproducing the whole snapshot with dig
Every value on this page comes from a query you can run yourself. Substitute your domain:
DOMAIN=example.com
# 1. MX — and confirm each host actually resolves
dig +short $DOMAIN MX
dig +short $(dig +short $DOMAIN MX | sort -n | head -1 | awk '{print $2}') A
# 2. SPF — the apex TXT record starting v=spf1
dig +short $DOMAIN TXT | grep -i 'v=spf1'
# 3. DKIM — you must know the selector; read it from a DKIM-Signature s= tag
dig +short selector1._domainkey.$DOMAIN TXT
# 4. DMARC
dig +short _dmarc.$DOMAIN TXT
# 5. PTR on the primary MX address, then forward-confirm it
MXIP=$(dig +short $(dig +short $DOMAIN MX | sort -n | head -1 | awk '{print $2}') A | head -1)
dig +short -x $MXIP
dig +short $(dig +short -x $MXIP | sed 's/\.$//') A # must return $MXIPThe last pair is the forward-confirmation check. If the final command does not print the address you started with, your PTR is not forward-confirmed and receivers running FCrDNS will treat it as a failure even though a PTR exists.
What this snapshot cannot see
Be clear about the boundary. This is a DNS and configuration audit. It cannot read Gmail's or Microsoft's private reputation score for your domain, it cannot tell you whether your last campaign hit the promotions tab, and it does not send a message through a seed list. Those things depend on volume, recipient engagement, complaint rate, and content — none of which is visible in DNS.
A grade of A here means your foundation is correct, which is a prerequisite for good placement rather than a guarantee of it. If everything scores well and mail still lands in spam, the problem is behavioural: check your IP against the blacklist checker, confirm your server is reachable with the SMTP connection test, and then read the Received headers of a message that was filtered to see exactly which authentication result the receiver recorded.