What an email deliverability score measures, and what it cannot

A single number for something as complicated as email deliverability sounds like a gimmick, and in one sense it is. No score can tell you whether your next message lands in the inbox. What it can do, usefully, is summarise the part of your setup that is checkable from the outside, so you can see at a glance what is missing and compare before and after.

This post explains what the Email Deliverability Score measures, how the points are given, and what is outside its reach.

What gets checked

The score is out of 100, built from six checks. DMARC counts the most, because it is the record that tells receiving servers what to do when a message fails authentication.

These weights are a judgement about what matters, not an industry standard, so treat the total as a guide.

How each part is scored

DMARC (30). A policy of p=reject earns the full 30, p=quarantine earns 25, and p=none earns 12, because none only monitors and does not tell receivers to act. No record earns nothing. The reasoning for the weight is that SPF and DKIM only produce results, and DMARC is what makes a receiver use them. See SPF, DKIM and DMARC explained for how the three fit together.

SPF (20). A record ending in -all earns 20, ~all earns 16, and a record with no enforcing ending earns 6. A record ending in +all earns nothing, because it authorises every server on the internet to send as you. A missing record earns nothing. Both -all and ~all are widely used, and the difference is whether failures are rejected or only marked, with -all stricter. If you hit lookup problems, SPF permerror: too many DNS lookups is the usual cause.

DKIM (20). A key found earns 20. The check looks for DKIM at the selectors that are most common, such as google, default, selector1, selector2, k1 and s1, because a selector is chosen by your email provider and the DNS gives no way to list them. If none of those is found, the check earns 8 of 20 rather than nothing, and says that your selector may be a custom one. A domain that signs with an unusual selector can look worse than it is, which is the main way this score understates a good setup. The Email Health tool lets you enter a selector directly.

MX (15). If a domain publishes no mail servers it cannot receive mail, which earns nothing. Any MX records earn the full 15.

Blocklists (10). The first two IPv4 addresses of your mail servers are checked against several public DNS blocklists. Zero listings earns 10. A listing earns nothing. Some lists refuse queries from public resolvers, so a result of unknown is reported as unknown and earns half, rather than being counted as clean. If you are listed, why is my IP blacklisted covers what to do.

BIMI (5). A BIMI record lets supporting mail clients show your logo next to your messages. It is the least important check and is optional, so it carries the least weight. It also depends on an enforcing DMARC policy, which is one more reason to get there. BIMI: getting your logo in the inbox explains the requirements.

The letter grade is a simple mapping: A is 90 or more, B is 80 or more, C is 70 or more, D is 55 or more, and below that is F.

A worked example

A well run large site scores a B, not an A. When checked on 4 November 2026, one scored 86 out of 100. Its MX, DKIM and blocklist checks earned full marks. SPF used ~all, which earns 16, DMARC was p=quarantine, which earns 25, and there was no BIMI record, which earns nothing. Each deduction there is a stricter setting that was available or an optional feature, not a fault.

That is the main lesson of reading a score. A number below 100 is not a list of mistakes. Read each line, because the explanation tells you whether a deduction matters for you.

What a score cannot tell you

This is the more important half.

Inbox placement. Mailbox providers decide on a message by combining authentication with your sending reputation, how recipients have treated your past mail, the content, the links, and how you send. A perfect score on authentication does not guarantee the inbox, and a modest one does not guarantee spam.

Your sending reputation. The blocklist check covers public DNS lists for your mail servers. It does not see the private reputation systems that big providers keep.

Whether your mail is actually signed. The check confirms a DKIM key is published. It cannot confirm that every message your systems send is signed with it. A sender such as a marketing platform may send on your behalf without being set up.

Your volume and behaviour. Large senders face specific requirements. If you send in volume, read bulk sender requirements from Gmail and Yahoo.

Your content and list quality. None of this is visible from DNS.

Using a score sensibly

Do not chase 100. Going to p=reject too early is the way to lose legitimate mail, such as a service you forgot you had that sends as your domain. The right order is to publish p=none with reporting, read the reports, fix the senders that fail, tighten to quarantine, and only then reject. Rolling out a DMARC policy walks through it, and understanding DMARC aggregate reports explains reading them.

Fix the red before the amber. A missing DMARC record or an open +all SPF record matters far more than a missing BIMI record.

Use it for before and after. The most useful property of a number is that it moves. Check, change one thing, and check again.

Check domains you send from, not just the main one. Subdomains and separate sending domains have their own records.

A routine

Run the score on your domain. Start with anything marked as a failure, then the warnings. Check DKIM directly if it was not found. Publish what is missing in the safe order, and score again. For the full list of things that affect delivery beyond authentication, see the email deliverability checklist, and for the transport side of mail security, MTA-STS and TLS-RPT.