Skip to content
Email Delivery Platform
Talk to engineering

/ Free Tools — Domain Health Scanner

Eight checks. One score.

Enter a domain and we run eight live DNS checks — SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, DNSSEC and MX — then return a 0–100 health score, a letter grade, your mail provider, and a copy-paste fix for every gap. Runs in your browser, nothing sent.

Request infrastructure review What it checks

Eight DNS checks over DNS-over-HTTPS, in parallel. A 0–100 score, your mail provider, and copy-paste fixes. Nothing is sent or stored.

/ What this checks

A domain health scan reads the eight DNS records that together decide whether your email is trusted and whether your domain can be impersonated: SPF, DKIM, and DMARC are the authentication core; MTA-STS and TLS-RPT secure and report on transport; BIMI displays your verified logo; DNSSEC signs your DNS answers; and MX confirms the domain receives mail and reveals who runs it. Read in isolation they tell you eight separate things; read together they give you a single 0–100 posture score — because deliverability and domain security are decided by the combination, not by any one record.

This scanner runs all eight in parallel, grades them into a score and a letter, identifies your mail provider from the MX records, counts your SPF lookups against the ten-lookup limit, and hands you a copy-paste DNS fix for every gap it finds. You see what's wrong, what to fix first, and the exact record to publish. Each result links to the dedicated checker for that protocol when you want to go deeper.

  • 8 checks

    SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, DNSSEC and MX — read live from DNS and graded into one number, because a gap in any one is a gap overall.

  • 0–100 score

    A weighted grade that follows real impact: DMARC enforcement and the authentication core carry the most, the hardening layers add on top. One number, one letter.

  • Provider + lookups

    It names your mail provider from the MX records and counts your SPF DNS lookups against the ten-lookup cap that silently breaks authentication.

  • Copy-paste fixes

    Every gap comes with the exact DNS record to publish, generated locally in your browser. Nothing is sent to us, no email is dispatched, your domain isn't logged.

/ The eight checks

What does each of the eight checks actually do?

The eight records this scan reads aren't competing options — they're a stack, each handling a problem the others don't. Understanding what each one does is how you read the score and decide what to fix first.

SPF publishes the servers allowed to send as your domain, and it's the easiest layer to break at scale: every sending tool you add pushes the record toward the ten-lookup limit that silently fails it, which is why the scan counts your lookups rather than just confirming the record exists. DKIM attaches a cryptographic signature to each message, proving it genuinely came from you and survived unaltered — and unlike SPF it survives forwarding, which makes it the more durable half of authentication. DMARC ties the two together: it tells receivers what to do when a message fails both, and it's the layer that turns authentication from advisory into enforced. These three carry the most weight in the score.

MTA-STS tells sending servers to require encrypted, authenticated TLS when delivering to your domain, closing a downgrade-attack gap the authentication layers don't touch, and TLS-RPT reports back when that encryption fails, so a downgrade attempt in progress becomes visible instead of silent. BIMI sits on an enforced DMARC policy and puts your verified logo beside your messages in supporting inboxes — a recognition signal that correlates with higher opens, though it does nothing until DMARC is at quarantine or reject.

DNSSEC cryptographically signs your DNS answers so an attacker can't poison the very lookups the other seven checks depend on — it protects the foundation the whole stack stands on. And the MX check confirms your domain can receive mail at all and identifies the platform running it, which matters because your SPF and DKIM have to match that provider — a mismatch between where your MX points and what your SPF authorizes is one of the quietest causes of authentication failure. Eight records, four surfaces: authentication, transport, brand, and DNS itself. 

# Where each record lives in your DNS
MX        MX  at   yourdomain.com            10 mail.provider.com
SPF       TXT at   yourdomain.com            v=spf1 ... -all
DKIM      TXT at   selector._domainkey...    v=DKIM1; k=rsa; p=...
DMARC     TXT at   _dmarc.yourdomain.com     v=DMARC1; p=reject; rua=...
MTA-STS   TXT at   _mta-sts.yourdomain.com   v=STSv1; id=...
TLS-RPT   TXT at   _smtp._tls.yourdomain.com v=TLSRPTv1; rua=mailto:...
BIMI      TXT at   default._bimi...          v=BIMI1; l=logo.svg; a=vmc.pem
DNSSEC    DNSKEY at yourdomain.com            (zone-signing keys present)

/ How the score works

Why one score instead of eight separate answers?

Eight green checkmarks don't mean much if one of the eight is the one that matters, and eight raw results leave you to work out which gap is urgent and which is cosmetic. The score does that weighting for you. It isn't an average — it follows the real cost of each gap to your deliverability and your exposure to impersonation.

DMARC carries the largest single block, because an enforced policy is the one record that actually stops a spoofer, and a domain without it is impersonable no matter how clean everything else looks. DKIM and SPF come next, as the authentication the DMARC policy checks against. A working, provider-identified MX adds a solid slice, since a domain that can't receive mail or points nowhere recognizable is a problem in itself. The remaining four — MTA-STS, TLS-RPT, BIMI, and DNSSEC — each add a smaller amount, because they harden and extend a posture that the core has already established.

That weighting produces a letter grade that maps to action. An A means the core is enforced and most of the hardening is in place — keep it there. A B or C usually means the authentication is working but DMARC is stuck at monitoring, or a hardening layer is missing, which is exactly where a little effort moves the number most. A D or F means a core gap: no DMARC, broken SPF, or a domain that can't authenticate at all, and those are the ones to fix today. The grade is a starting point, not a certificate — it reflects the moment you scanned, and posture drifts as you add sending sources.

/ What to fix first

In what order should you fix what the scan finds?

A scan that flags several gaps can be paralyzing, but the order is fixed, because the layers depend on each other. Start with SPF and DKIM: get both publishing correctly and authenticating your real mail, because they're what DMARC checks against. A DMARC policy enforcing against broken SPF and DKIM will reject your own legitimate mail, so the foundation has to be solid before you tighten the policy above it. If the scan flagged your SPF for too many lookups, fix that here too — a record over the ten-lookup cap fails the same as no record at all.

Then move DMARC from monitoring to enforcement. Most domains that have DMARC at all are stuck at p=none, which is the right place to begin and the wrong place to stay — it collects reports without protecting anything. Once your reports confirm every legitimate source is aligned, advance to quarantine and then reject. This one step closes the spoofing gap, lifts the largest block in your score, and unlocks BIMI, which is why it returns more protection per unit of effort than anything else once the foundation is in place. It's also the step domains stall on longest, because moving off p=none feels risky — but with the reports confirming your sources, the exposure of staying spoofable is the larger risk, and a careful ramp through quarantine first removes most of it.

A scan is a single moment in time, and that's worth keeping in mind. Authentication posture drifts: a new tool adds an unaligned source, a DNS change drops a record, a key rotation leaves an old selector behind. A domain that scored an A last quarter can quietly slip without anyone touching it on purpose, which is why a one-time fix and continuous operation are different things — and why the score is a starting point rather than a guarantee.

Only then do the hardening and brand layers earn attention. Add MTA-STS and TLS-RPT together so encrypted delivery is both required and monitored. Turn on DNSSEC at your registrar to protect the DNS the whole stack relies on. Set up BIMI last, once DMARC is enforced and you have a properly formatted logo — and for the verified checkmark in Gmail and Apple Mail, a Verified Mark Certificate. They're worth doing, but they're the finish, not the foundation. The score orders its findings this way so you spend effort where it moves the number most, and getting a domain cleanly to an A, then keeping it there as you add sending sources, is the ongoing work we operate so it doesn't drift back into the red.

/ Scanner FAQ

What does the domain health scan check?
Eight things, in one pass, all read live from DNS. Three are the authentication core: SPF (which servers may send as you), DKIM (the cryptographic signature proving a message is genuine), and DMARC (the policy that ties them together and tells receivers what to do with failures). Two harden transport: MTA-STS (which requires encrypted delivery to your domain) and TLS-RPT (which reports when that encryption fails). One is brand: BIMI (your verified logo in supporting inboxes). One protects DNS itself: DNSSEC (cryptographic signing of your DNS answers). And the scan reads your MX records to confirm the domain can receive mail and to identify who runs it. Together they are your posture; the score grades the combination rather than any single record.
How is the 0–100 score calculated?
Each check contributes a weighted share, and the weights follow real-world impact rather than treating every record as equal. The authentication core carries the most: DMARC is worth the single largest block because an enforced policy is what actually stops spoofing, followed by DKIM and SPF. A healthy, provider-identified MX adds a slice. The hardening and brand layers — MTA-STS, TLS-RPT, BIMI, and DNSSEC — each add a smaller amount on top. A domain authenticating cleanly with DMARC enforced lands in the A/B range even before the extras; a domain missing DMARC or with SPF broken drops fast, because those are the gaps that cost you inbox placement and expose you to impersonation.
How does the scanner detect my mail provider?
It reads your MX records and matches the hostnames against the fingerprints of the major platforms — Google Workspace, Microsoft 365, Proofpoint, Mimecast, Zoho, Amazon SES/WorkMail, Proton, and others. This tells you at a glance who is handling your inbound mail, which matters because your SPF and DKIM setup has to match that provider. A mismatch between the provider your MX points to and the sources your SPF authorizes is one of the most common quiet causes of authentication failures, and seeing both in one place makes it obvious.
Why does the SPF check count DNS lookups?
Because SPF silently fails when it needs more than ten DNS lookups to evaluate — a limit called the ten-lookup cap. Every include, a, mx, ptr, and exists mechanism costs a lookup, and includes chain into more includes, so a record that looks short can blow the limit once it's expanded. When that happens SPF returns PermError and receivers treat your mail as unauthenticated. The scanner expands your record the way a receiving server does, counts the real total, and warns you before you hit the cap — a check most quick lookups skip entirely.
Why does DKIM sometimes show as not found when I have it?
DKIM lives at a selector you can't guess — an arbitrary label your provider chose. The scan probes the common provider selectors, which catches most Google Workspace, Microsoft 365, and ESP setups and even names the provider when it matches, but it can't find a custom or random selector. Amazon SES, for example, uses long random tokens. A not-found result means no common selector matched, not necessarily that DKIM is absent. When that happens, use the dedicated DKIM checker with the exact selector from a sent message's DKIM-Signature header.
Does the scanner send or store anything?
No. Every one of the eight checks runs in your browser as a read-only DNS-over-HTTPS query — the same lookup a receiving mail server performs. Nothing is sent to our servers, no email is dispatched, and your domain is never logged. The copy-paste fixes are generated locally from standard record templates. You can scan any domain you're responsible for without it touching our infrastructure.

You can see the gaps now. We close them and keep them closed.

A score is a snapshot. Getting every check green and holding it there as you add sending sources, rotate keys, and tighten policies is continuous work — and it's exactly what we operate. Scan your domain, then bring us the report.

Book infrastructure review

Related capabilities