Email Health
Combined SPF + DKIM + DMARC grade with per-record diagnostics.
No result yet
Enter the inputs above and press Run. Results appear here in a moment.
Monitor this 24/7 — get alerts on the first failure.
Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.
What is Email Health?
Email health is the combined assessment of the three records every modern mail provider uses to decide whether your mail is legitimate: SPF (which servers are allowed to send for your domain), DKIM (cryptographic signature on outgoing mail), and DMARC (what receivers should do when SPF/DKIM fail). All three working = good deliverability. One missing = you'll see soft fails. All three missing = your mail lands in spam at most large providers.
This tool checks all three at once for any domain, parses each record, validates syntax, recursively expands SPF includes ("do you actually include only what you intend?"), and reports the policy each receiver will apply. It's the diagnostic that turns "why does my mail end up in spam" into a specific fix list.
How it works
All three records are TXT lookups in DNS, just at different names:
- 1SPF: query TXT at the apex — Look up
TXT example.com. Find the record starting withv=spf1. Parse mechanisms (ip4:,ip6:,a:,mx:,include:,~all,-all). Recursively expandinclude:references and followredirect=chains. - 2DKIM: query TXT at the selector — Look up
TXT <selector>._domainkey.example.com. The selector is announced by the sender in the mail header (DKIM-Signature: ... s=<selector>). We can probe common selectors automatically (google,selector1,selector2,default, etc.) or you can specify one explicitly. - 3DMARC: query TXT at _dmarc — Look up
TXT _dmarc.example.com. Find the record starting withv=DMARC1. Parse tags:p=(policy: none/quarantine/reject),rua=(aggregate report URI),ruf=(forensic report URI),sp=(subdomain policy),pct=(percentage of mail to apply policy to). - 4Aggregate into a grade — Each record's presence + validity contributes to an overall grade. Missing DMARC entirely = high risk. SPF without DMARC enforcement = receivers may still soft-fail. DKIM without DMARC = receivers may discount the signature. All three with
p=reject= strong posture.
When you'd use it
Pre-launch deliverability check
Before sending marketing or transactional email at scale from a new domain, run a full email-health check. Anything missing = fix before sending. Skipping this is the most common cause of "first campaign went straight to spam."
Onboarding a new ESP
Adding Mailchimp/SendGrid/Resend/Postmark — they all give you SPF includes and DKIM selectors to add. Run this tool to confirm both records are correct and that DMARC will still pass after the change.
Investigating a deliverability drop
Open rates fell off a cliff. Run an email-health check on your sending domain. Common discoveries: SPF record exceeded 10 DNS lookups (silently fails — fix the includes), DKIM selector returns NXDOMAIN (selector removed at the ESP), DMARC moved from p=none to p=quarantine without warning.
Defending against email spoofing
Phishing campaign impersonating your domain. Check DMARC — if p=none, receivers aren't blocking spoofed mail. Move to p=quarantine then p=reject after analysing aggregate reports for legitimate-but-misaligned senders.
Subdomain policy verification
DMARC sp= tag controls subdomain policy. If unset, subdomain policy inherits from parent. Verify that mail-sending subdomains (e.g. marketing.example.com) have explicit DMARC policies appropriate for their use.
Reading the result
SPF — Sender Policy Framework
Lists the authorised senders. v=spf1 ip4:1.2.3.4 include:_spf.google.com ~all means: IP 1.2.3.4 is allowed, anything Google's SPF allows is allowed, everything else is softfail (~all) — would-be senders not in the list trigger a soft fail at the receiver. -all is the strict version (hard fail). +all is a misconfiguration that authorises everyone.
DKIM — DomainKeys Identified Mail
Cryptographic signature added to outgoing mail by the sending server. The public key is published in DNS at <selector>._domainkey.<domain>. Receiver fetches the public key, validates the signature, confirms the mail wasn't tampered with in transit AND was sent by someone who controls the private key. Strong signal of authenticity.
DMARC — Domain-based Message Authentication, Reporting, and Conformance
Tells receivers what to do when SPF or DKIM fail and how to send you aggregate reports about it. p=none = monitor only, don't reject anything (audit mode). p=quarantine = send failing mail to spam. p=reject = bounce failing mail entirely. rua=mailto:[email protected] = receivers send daily aggregate XML reports here.
Why all three together is strong
SPF alone passes for forwarded mail (which legitimately changes the sender IP). DKIM alone survives forwarding but fails if the mail is modified. DMARC requires either SPF or DKIM to pass AND to align with the From: header — that combination is what makes spoofing hard.
Common pitfalls
SPF record exceeds 10 DNS lookups
RFC 7208 says SPF MUST have at most 10 DNS lookups (each include:, a:, mx: counts). Exceed it and receivers MUST treat it as a permanent error — your SPF fails. Fix: flatten includes (replace include:_spf.google.com with the literal IP ranges) or move to a SPF flattening service.
Multiple SPF records on the same domain
Only one TXT starting with v=spf1 is allowed. If you have two (common when adding a new ESP without removing the old one), receivers MUST treat it as a permanent error. Consolidate into one record.
DKIM selector returns no record
Either: (1) the selector you're querying isn't the one the sender is using — check the actual DKIM-Signature header in a received message to confirm; (2) the ESP rotated selectors and the old one was removed from DNS; (3) the selector was never added (deployment mistake when onboarding the ESP).
DMARC at `p=none` indefinitely
p=none is the audit mode — receivers report what would happen but don't act on it. Many teams set p=none and never move past it. That means receivers can still accept spoofed mail. Use the aggregate reports to identify legitimate senders, fix their SPF/DKIM, then move to p=quarantine and eventually p=reject.
Run Email Health on every change, not just once.
Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.
Start freeFrequently asked questions
Which of SPF, DKIM, DMARC matters most?
p=reject.Will configuring DMARC p=reject break legitimate mail?
p=none, analyse aggregate reports for 2-4 weeks, identify any legitimate-but-failing senders, fix them (add to SPF or get them DKIM-signing), then move to p=quarantine, then p=reject after another period of clean reports.Why is my SPF showing include:_spf.google.com resolved as a long list?
ip4: ranges — that's normal. The expansion is what receivers do at evaluation time; we just show you the final picture.What does ~all vs -all actually mean?
~all = soft fail. Mail from unauthorised senders is suspicious but not rejected outright. -all = hard fail. Receivers should reject mail from unauthorised senders. With DMARC p=reject in place, the two are nearly equivalent — DMARC enforces regardless. Without DMARC, -all is stricter.What's a DKIM selector and why does each ESP use a different one?
DKIM-Signature header of each outgoing message.How long does it take for SPF/DKIM/DMARC changes to take effect?
Should I have SPF or DMARC at the subdomain level?
sp= tag (or inheritance default). For domains that send no mail from any subdomain, an explicit DMARC sp=reject is a defense against spoofed subdomain mail.Where do I receive DMARC aggregate reports?
rua=mailto: tag. Receivers will send daily XML reports there. Parse them with a tool like Postmark's DMARC service, dmarcian, or self-hosted (opendmarc includes a parser). Raw XML is dense; tooling makes it tractable.