Status

—

About this tool

What gets checked

Four core email-authentication records, in parallel:

MX records — Mail exchangers for the domain. Without these, the domain can't receive mail. Multiple MXes (with different priorities) provide redundancy.
SPF (Sender Policy Framework) — TXT record listing IPs/hostnames authorized to send mail as the domain. Lives at the apex (e.g. example.com). Must end with ~all or -all to be effective.
DMARC (Domain-based Message Authentication) — Policy record at _dmarc.example.com. Tells receivers what to do when SPF/DKIM fail. The strongest setting is p=reject; p=none is monitor-only.
DKIM (DomainKeys Identified Mail) — Public-key signing record at {selector}._domainkey.example.com. Selectors aren't discoverable from DNS — the tool tries 19 common ones (Google, Microsoft, Mailchimp, Mandrill, Proton, etc.). Provide a custom selector if you know yours.

What the severities mean

OK (green) — record exists and follows best practices.
Warning (yellow) — record works but has issues that could affect deliverability or security (e.g., DMARC p=none, single MX, soft-fail SPF).
Error (red) — record missing, broken, or actively harmful (e.g., no DMARC, multiple SPF records, +all).

Common DKIM selectors auto-checked

If you don't provide a selector, the tool queries: default, google, mail, s1, s2, selector1, selector2, k1, k2, dkim, email, mandrill, mailchimp, protonmail1-3, mxvault, sm, mta. If your domain uses a different selector (rotating selectors, custom names like 20240101, etc.), enter it manually.

Going further: who registered this domain?

If you're investigating a domain whose mail config you don't recognize — a customer's vendor, a phishing sender, an old domain you found in DNS — pair this tool with the WHOIS Lookup. It tells you which registrar the domain was bought through, when it was registered, and when it expires. A domain registered three days ago with no SPF and no DMARC is almost always a phishing operation; a 15-year-old domain at a reputable registrar with broken SPF is just an admin who needs to fix their config.

Why this beats running the lookups individually

You could run dig MX example.com, dig TXT example.com, dig TXT _dmarc.example.com, dig TXT default._domainkey.example.com separately. But:

You'd have to know the relationship between SPF/DMARC/DKIM by heart
You'd have to remember which selectors to try for DKIM
You'd have to interpret each record manually (does ~all mean strict? Is p=quarantine good?)
You wouldn't catch issues like multiple SPF records, SPF DNS-lookup limits, or DMARC pct= percentages

This tool does all of that in 1-2 seconds and explains what each finding means.

Privacy note

Domain lookups happen server-side via Cloudflare DNS-over-HTTPS. We don't log queries. Anyone who can run dig can already see this data — it's all public DNS records.

Why email deliverability keeps getting harder

Email started as an open, permissive system. Anyone could send mail claiming to be anyone. Over the decades, as spam and phishing became the dominant use of that permissiveness, receivers layered on increasingly complex authentication mechanisms to distinguish legitimate senders from bad ones. The result today is a stack of interlocking systems (SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, ARC) that all have to be configured correctly for reliable delivery to major mailbox providers.

This is what makes email deliverability a genuine ongoing chore for legitimate senders. Small businesses regularly find that their perfectly legitimate outgoing mail is landing in Gmail's spam folder or getting rejected outright by Outlook, and the reason is almost always a missing or misconfigured authentication record on their sending domain. The tool on this page checks the important ones in one shot.

What each check actually tells you

MX records

The MX (Mail Exchange) records tell the world where to send incoming mail for the domain. Missing MX means the domain can't receive mail. Wrong MX means mail goes to the wrong place. Multiple MX records with priorities are common (primary at 10, backup at 20) so mail keeps flowing if the primary is down.

The tool flags missing MX, MX records that don't resolve to any IP (which effectively means no mail server is listening), and MX records that point at CNAMEs (technically allowed by DNS but forbidden for MX by RFC 5321 and rejected by strict senders).

SPF (Sender Policy Framework)

SPF publishes a list of IPs authorized to send mail for the domain. Receivers check the sending IP against this list. If the IP is in the list, SPF passes. If not, SPF fails (with severity depending on the policy).

Common SPF issues the tool flags:

No SPF record: means the domain hasn't published a policy. Receivers treat this as "no opinion" which is worse than pass but not necessarily a rejection.
SPF record but no ~all or -all suffix: means the policy doesn't say what to do about unlisted IPs. Should end with ~all (soft-fail) or -all (hard-fail).
SPF record with +all: allows any IP to send for the domain. Effectively no protection.
SPF record exceeding 10 DNS lookups: the SPF specification limits the number of DNS lookups triggered by SPF resolution (including includes and redirects). Records that exceed this cause SPF resolution to fail entirely, no matter how well the record is otherwise written. Chaining many include: directives is the common way to blow past the limit.
SPF record with multiple TXT records for _spf: some DNS servers publish multiple SPF-like records for the same domain, which causes ambiguity. Only one should exist.

DKIM (DomainKeys Identified Mail)

DKIM cryptographically signs specific headers and the body of outgoing mail. Receivers verify the signature against a public key published in the sender's DNS. Signed mail that verifies correctly is strong evidence of legitimacy and hasn't been modified in transit.

The tool checks that:

DKIM public keys are published: for each active selector. Selectors are per-configuration, so a domain might have multiple (one for the primary mail provider, one for a bulk mail service like Mailchimp, one for a transactional service like SendGrid).
Keys are RSA 2048-bit or better: shorter keys are being deprecated. 1024-bit keys still work for most receivers but are considered legacy.
Keys aren't test/dead: the tool warns about keys marked t=y (test mode) or that appear to be revoked (empty p= tag).

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together with policy. It says "for mail from this domain, require that SPF or DKIM pass with the From: header aligned, and here's what to do with failures." DMARC records also let the domain owner receive aggregate reports about mail claiming to be from their domain.

The tool checks:

DMARC record exists: at _dmarc.example.com. Missing means the domain has no policy at all.
Policy is more than p=none: p=none is monitoring only. Serious DMARC deployments move to p=quarantine or p=reject once they're confident in their sender inventory.
rua/ruf reporting addresses are set: these enable receivers to send aggregate and failure reports back to the domain owner. Without them, the domain misses valuable feedback about mail from their domain.
Alignment mode is appropriate: aspf=r and adkim=r (relaxed alignment) are more permissive; aspf=s and adkim=s (strict) require exact domain match.

How I use this in real troubleshooting

New customer whose mail lands in Gmail spam

First step, always, is running their domain through this tool. Nine times out of ten one of the records is missing or wrong. SPF is often incomplete because they've added mail services (bulk mail platforms, CRM tools) without updating the SPF record. DKIM is often not published for the mail services they've added. DMARC often doesn't exist.

Fixing the records rarely produces immediate delivery improvement — Gmail and other providers have reputation systems that take time to update — but it removes the technical objections and lets the reputation start recovering.

Customer just migrated their DNS

DNS migrations sometimes lose records that weren't in the migration list. SPF is a common casualty because it's just a TXT record and easy to overlook. DKIM might have been added directly to the DNS zone rather than through the mail provider's management interface, so migrating to a new DNS provider without re-copying DKIM breaks it.

Running the health check right after a migration catches these problems before customer complaints come in.

Domain was compromised and someone was sending spam from it

If a domain got compromised and used to send spam, the domain's reputation is damaged. Recovery requires fixing the compromise, then making sure SPF/DKIM/DMARC are properly configured to prevent future forged mail, then waiting for reputation to rebuild. The tool confirms the fix is complete before starting the wait.

Adding a new mail service

Every time a customer adds a new mail service (bulk newsletter, CRM, transactional email, marketing automation, invoicing platform), that service becomes a new set of IPs sending on behalf of the domain. SPF has to be updated to include them. DKIM keys for the new service need to be published. Running the check after adding the service confirms everything is wired up.

What good configuration looks like

SPF

A well-written SPF record is one line, includes all the mail services in use, and ends with ~all or -all. Example: v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ~all. This says "Google Workspace, SendGrid, and Mailchimp are authorized to send mail for us; anyone else is not, with soft-fail policy."

DKIM

Each mail service publishes its own selector under the domain. Google Workspace publishes at google._domainkey.example.com. SendGrid publishes multiple selectors under s1._domainkey.example.com and s2._domainkey.example.com. Each should exist and have a valid public key.

DMARC

A production DMARC record includes p=quarantine or p=reject, both rua and ruf addresses for reporting, and appropriate alignment mode. Example: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=r; aspf=r; pct=100.

Common misconceptions

"My SPF passes, why does my mail go to spam?"

SPF passing is necessary but not sufficient. Reputation (based on volume, complaint rate, list quality, engagement metrics), content characteristics, sending pattern consistency, and DKIM/DMARC all matter alongside SPF. A domain with clean SPF/DKIM/DMARC but a spammy content pattern or bad list quality will still land in junk.

"I don't send mail, so I don't need SPF"

Domains that don't send mail should publish an SPF record that says exactly that: v=spf1 -all. This tells receivers "we do not send mail from this domain," which helps them reject forged mail claiming to be from you. Not publishing SPF at all means receivers don't know the difference between "no mail expected" and "sender didn't bother with SPF."

"DKIM signatures make mail unforgeable"

DKIM proves the mail was signed by someone with access to the private key. If the private key is compromised, forged mail signs correctly. DKIM is one layer of defense, not a complete solution.

"DMARC p=reject will lose legitimate mail"

Only if you have legitimate senders that haven't been configured for SPF/DKIM alignment. This is why the recommended DMARC deployment is: start at p=none with reporting, review the reports to identify all legitimate senders, fix any that aren't aligning, then progress to p=quarantine, then to p=reject. This is often a multi-month process for a domain with many mail services.

Related tools

If you're troubleshooting a specific message rather than a domain's general configuration, the Email Header Analyzer parses individual message headers and shows the authentication results for that specific delivery. For checking whether the sending IP is on any known blacklists (which affects deliverability independent of authentication configuration), the DNSBL Blacklist Check queries six major lists.

For understanding infrastructure around the domain more broadly, the Domain Infrastructure Lookup shows all DNS records including who owns the IP addresses each record points at.

Privacy

The health check runs DNS queries for the specified domain from our Cloudflare Worker. The queries hit public DNS resolvers and read publicly-published TXT and MX records. Nothing beyond the domain name is transmitted, and no persistent record of the query is kept beyond standard analytics.