Email Deliverability Score
Check any domain's Email Deliverability Score (0 to 100) from SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT and BIMI, with a ranked fix list. Free, in your browser.
Updated 2026-10-20
Using a custom selector? Enter it to include your key. Leave it empty to try the selectors common providers use.
Your query is sent only to the resolver shown; this site keeps no logs. Copy link to this result
What is the DNSVerdict Email Deliverability Score?
DNSVerdict's Email Deliverability Score is a free 0–100 rating of a domain's public email-authentication DNS: mail routing 10, SPF 25, DMARC 25, DKIM 15, MTA-STS and TLS-RPT 10, BIMI 5, record hygiene 10. It follows RFC 7208, RFC 9989 and RFC 6376. A missing or broken SPF record caps it at 69 and a missing DMARC record at 59. Checks run in your browser over DNS-over-HTTPS; nothing is logged.
How is the score calculated?
| Check | Max points | Full marks when | Standard |
|---|---|---|---|
| Mail routing (MX) | 10 | every MX host resolves to an address (a null MX on a domain that sends no mail also scores 10) | RFC 5321 §5.1, RFC 7505 |
| SPF | 25 | one record (8), no permerror (10), at most 8 DNS lookups (2) and a terminal -all (5; ~all earns 3, ?all 1) | RFC 7208 §3.2, §4.6.4, §5 |
| DMARC | 25 | record found by the tree walk (5), p=reject (10; quarantine 7, none 2), valid syntax (3), rua= (3), sp not weaker than p (2), external report addresses authorised (2) | RFC 9989 §4.7, §4.10, §11.6 |
| DKIM | 15 | a key at a known selector, or at the selector you enter: RSA 2048 bits or more, or Ed25519 (15); RSA 1024 earns 11; below 1024 is not valid | RFC 6376 §3.6.1, RFC 8301 §3.2 |
| MTA-STS and TLS-RPT | 10 | a valid MTA-STS TXT record (5) and a valid TLS-RPT TXT record (5) | RFC 8461 §3.1, RFC 8460 §3 |
| BIMI | 5 | a valid BIMI record with an https logo URL, and DMARC at p=quarantine or p=reject | IETF BIMI draft; BIMI Group implementation guide |
| Record hygiene | 10 | MX targets are not aliases (5) and no policy name holds a record that does not belong there (5) | RFC 2181 §10.3 |
Bands: 90 to 100 is A (well configured), 75 to 89 is B (good, with clear gaps), 60 to 74 is C (works, but receivers may reject or junk your mail), 40 to 59 is D (spoofing and delivery risk) and 0 to 39 is F (not protected).
Caps: a Sender with a missing or broken SPF record is capped at 69, any domain with no DMARC record is capped at 59, and a Sender whose SPF authorises a provider with documented DKIM selectors, but has no DKIM key, is capped at 74. A cap is shown only when it lowers the score.
Band A is reachable without BIMI: a Sender with every other check at full marks scores 95.
SPF ~all earns 3 of 5 points and -all earns 5. Both are valid, but ~all only asks receivers to mark mail that fails SPF, while -all asks them to reject it, so -all is worth more once every legitimate sender is listed.
Methodology v1, 2026-10-20.
The score is a 0 to 100 reading of how well a domain's public DNS is set up for email: 90 or more means the records are complete and strict, while below 60 means receivers may junk or reject your mail, or let others spoof your domain.
It adds up seven checks: mail routing, SPF, DMARC, DKIM, MTA-STS and TLS-RPT, BIMI and record hygiene, with the weights in the table above. Every point lost shows up in the fix list, with a link to the guide that explains the repair.
The tool first decides what kind of domain it is. A Sender uses all seven checks. A Receive-only domain has MX records but no DKIM key and no sending service in SPF, so DKIM and BIMI are removed and the score is rescaled.
A Non-mail domain publishes a null MX (RFC 7505) or no MX, plus an SPF record of exactly -all, so only routing, SPF, DMARC and hygiene count. A check that does not apply to a domain never lowers its score.
SPF is judged under RFC 7208: exactly one v=spf1 record (§3.2), at most 10 terms that cost a DNS lookup and at most 2 void lookups (§4.6.4), no +all, and a terminal -all or ~all. Macros that depend on the message, such as the sending IP address, are evaluated per message by receivers (§7), so they count as one lookup but are never queried, and they are not an error.
DMARC follows RFC 9989: the record is found by the tree walk (§4.10), p=reject earns the most and p=none the least, rua= reporting counts, a subdomain policy weaker than p= costs points, and report addresses at other domains need the authorisation record described in §11.6.
DKIM follows RFC 6376 §3.6.1 and RFC 8301 §3.2: an RSA key below 1024 bits is not valid, 1024 bits is weak, and 2048 bits or Ed25519 earns full marks. DNS cannot list selectors, so DNSVerdict tries the ones common providers use. You can enter your own selector. Not found means not detected, and the report says so.
MTA-STS (RFC 8461 §3.1) and TLS-RPT (RFC 8460 §3) protect mail coming in to you, so they count for receive-only domains too. Only the TXT records are checked: the policy file that holds the mode lives on a web host that browsers cannot read, so verify it manually.
BIMI is an IETF draft rather than an RFC. It counts only for senders with an enforced DMARC policy, which the BIMI Group implementation guide requires. A record at the wrong name, such as an SPF record at _mta-sts or a DMARC record at the domain apex, earns nothing and costs hygiene points.
On top of the points there are caps. Google and Yahoo require SPF and a published DMARC policy from bulk senders, so a missing or broken SPF record caps the score at 69 and a missing DMARC record at 59, however good the rest looks.
If a resolver fails during any check, the score is shown as incomplete, naming the lookup that failed, instead of guessing that a record is missing. All queries go from your browser to the DNS-over-HTTPS resolver named in the result, and the shareable link holds only the domain after the # sign.
If it fails
- Marked incomplete: a resolver or nameserver failed on at least one lookup. Run it again, or compare with the DNS lookup tool.
- SPF problems: fix too many lookups, fix SPF syntax errors or set up SPF.
- DMARC missing or on p=none: set up DMARC, then move to quarantine or reject.
- DKIM not detected: set up DKIM, or find your selector with the email header analyzer and enter it in the selector field. For short keys see DKIM key length.
- Transport and branding: set up MTA-STS, set up TLS-RPT and, once DMARC is enforced, set up BIMI.
- MX trouble or a domain that sends no mail: set up MX or publish a null MX.
FAQ
What is a good email deliverability score?
On DNSVerdict, aim for 90 or more (band A), which a sender can reach without BIMI. From 75 to 89 the basics work but gaps remain, usually DMARC on p=none or missing MTA-STS. Below 60 receivers may junk or reject your mail, or let others spoof your domain. Enforcing DMARC under RFC 9989 is the biggest single step.
Does a high score guarantee inbox delivery?
No. DNSVerdict reads only public DNS records, such as SPF under RFC 7208. Inbox placement also depends on sending reputation, content, complaint rate, list quality, alignment and one-click unsubscribe, none of which can be checked from DNS. A high score removes technical reasons for rejection; it does not promise delivery.
Why does DNSVerdict say DKIM was not detected when I use DKIM?
DNS cannot list the selectors under _domainkey (RFC 6376 §3.1), so DNSVerdict tries the selectors common providers use. A custom selector, such as one chosen in Google Workspace, will not be found. Read the s= tag in the DKIM-Signature header of a sent message, then enter it in the selector field and run the check again.
Why is my domain called Receive-only or Non-mail?
DNSVerdict calls a domain Receive-only when it has MX records but no DKIM key and no sending service in SPF, so DKIM and BIMI are skipped. Non-mail means a null MX (RFC 7505) or no MX, plus an SPF record of exactly -all. If you do send mail, publish DKIM or add your provider to SPF.
Why is my score different from MXToolbox or EasyDMARC?
Each checker weights things differently. DNSVerdict publishes its weights in the methodology table, checks only public DNS, gives BIMI just 5 points, and treats DKIM at an unknown selector as not detected rather than missing. Its SPF scoring follows RFC 7208, so the numbers will not match another tool's.