Not just “record found”.
The checker walks include and redirect paths, estimates DNS-querying mechanisms against SPF's 10-lookup limit and flags dangerous or fragile policy patterns.
Free tool · Email Domain Health Checker
Know if your email domain is ready to send.
Run a live check of the authentication behind your sending domain. Find broken SPF, weak DMARC, unverified DKIM and the gaps that still need a real-message check before you scale sending.
Published setupLive DNS evidence
Reality checkVerify one real message locally
No inbox-placement claimConfiguration is not inbox placement
Run the check
Check the DNS.
Then check a real message.
We read public DNS records live. You can then paste the headers from one sent message to confirm what passed without uploading the raw header.
Live domain reportdomain.com
Prioritising the evidence.
The live DNS checks are complete. The final review will not add facts that were not found.
Preparing the review…
Close the authentication gaps first.
What the domain actually publishes.
Are you inside the 10-lookup budget?
Which sender requirements can we prove?
Unknown means the domain alone cannot prove it. That is different from a failure.
| Provider | Requirement | Status | What the evidence says |
|---|
Useful, but not the same as authentication.
Do not break what is working.
What to verify before you scale.
Check one message you actually sent.
Copy the raw headers from a delivered message. The browser reads the topmost Authentication-Results field and unsubscribe headers locally. The raw header is never sent to the server.
Private by design: only pass/fail/unknown authentication results and unsubscribe-header structure can be sent for the written review. Addresses, message IDs, unsubscribe URLs and the raw header stay here. Important: header results are mailbox evidence, not an independent cryptographic re-check.
SPF on real messageNot checked
DKIM on real messageNot checked
DMARC / alignmentNot checked
One-click unsubscribeNot checked
What makes this different
DNS first.
One real message second.
Most domain checkers stop at published records. This one keeps the distinction between “configured in DNS” and “a message actually passed authentication” visible all the way through the report, and it follows the current RFC 9989 DMARC discovery model.
Unknown is not missing.
Selectors are not globally discoverable. We use your selector when supplied, otherwise probe only common candidates and keep an honest “unverified” state when we cannot prove publication.
Policy and reporting.
See whether DMARC exists locally or is inherited through the current RFC 9989 DNS tree walk, the effective policy, test mode, alignment and aggregate reporting.
Did the message pass?
Paste one sent-message header locally to read the topmost Authentication-Results field and inspect RFC 8058 unsubscribe header structure without uploading the raw message metadata.
Requirements by sender type.
Google and Yahoo requirement rows clearly separate proven, failed, message-level and not-checkable signals. Gmail history, spam rates, PTR, outbound TLS and body-level unsubscribe requirements are never fabricated from DNS.
Useful extras stay in context.
MTA-STS, TLS reporting and BIMI are surfaced separately so optional hardening does not get confused with the core SPF/DKIM/DMARC foundation.
Beyond the DNS
Authentication clean. Outreach still manual?
ZappFlow builds the lead-generation, enrichment, personalised outreach, follow-up and booking systems around the sending infrastructure.
Need the workflow built?
Show us what happens now.
We can work from the process you already have rather than forcing another tool into it.
Start a project →Questions
What this report can
and cannot tell you.
Email authentication is factual. Deliverability is broader. The checker is deliberately strict about that boundary.
Does a 100 score mean my emails will land in the inbox?
No. The score describes the published authentication configuration that this tool can verify. Inbox placement also depends on sender reputation, complaint rates, content, recipient behaviour and mailbox-provider decisions.
Why can DKIM say “unverified” when I know it is enabled?
A DKIM selector is part of the DNS name and there is no universal way to list every selector in use. Enter the selector if you know it, or paste a real message header to see whether that message actually passed DKIM.
What does the 10-lookup SPF check mean?
SPF evaluation has a limit on DNS-querying mechanisms. The tool follows published include and redirect paths and estimates the lookup burden so nested providers do not hide an over-budget policy.
Are the Google and Yahoo rows guarantees of compliance?
No. They map the evidence this tool can see against the providers' published sender requirements. Some items such as complaint rate, actual sending IP reverse DNS and historical bulk-sender status cannot be proven from a domain alone. Google's guidance and Yahoo's guidance remain authoritative.
Do you upload the raw email headers?
No. Raw headers are parsed in the browser. The review can receive only a tiny summary such as SPF pass, DKIM pass, DMARC pass and whether one-click unsubscribe headers were present.