Email authentication
Email authentication report
See SPF, DKIM, DMARC and MX for one domain together, with the fixes in the order to do them.
Free, no accountLive check
Result
The verdict appears here once you press Run the report.
What this is
This email authentication report runs the SPF, DKIM, DMARC and MX checks for one domain together, and orders the fixes the way they actually need doing: mail routing first, then the two records DMARC depends on, then DMARC itself.
The four records that decide whether a domain's mail gets delivered answer different questions: MX says where mail goes, SPF says which servers may send it, DKIM proves a message was not altered in transit, and DMARC says what to do when SPF or DKIM disagrees with the message. Checking one without the others misses how they depend on each other - a perfect DMARC record enforces nothing useful on top of a broken SPF record.
Fixing them in the wrong order wastes a cycle: tightening DMARC before SPF and DKIM are both solid just means more mail gets rejected, not more mail authenticated. Mail routing, SPF and DKIM are worth settling before DMARC is moved past "none".
How to read the result
The table at the top is the whole domain at a glance - four rows, four plain words each. "Fixes, in the order to do them" underneath turns every problem found into a numbered list, already sorted the way this page argues they should be tackled.
Each finding keeps the same explanation its own tool would give, with the check it came from named in front of it, so the full detail - the RFC it cites, the exact fix - is right there rather than requiring a second visit to that tool's own page.
Common mistakes
What goes wrong most often, and how to tell.
- Fixing DMARC first because it feels like the important oneDMARC does nothing on its own - it acts on the result SPF and DKIM already produced. A domain with a strict DMARC policy and a broken SPF record just rejects more of its own mail, not more forged mail.
- Treating four green checks as four unrelated passesThey are not independent: DKIM alignment checks the signing domain against the DMARC domain, and SPF alignment checks the return-path domain the same way. A change to one - a new sending platform, a new subdomain - can quietly break an alignment that used to hold.
- Running each check once and assuming it stays trueA provider can change its own SPF include chain, rotate a DKIM key, or add a sender without telling every customer first. None of these four records are "set once" - they are worth re-checking whenever a sending platform changes.
Questions
What people ask about this tool.
- MX first, since nothing else matters if mail has nowhere to be delivered. Then SPF and DKIM, since DMARC's alignment checks depend on both of them already working. DMARC last, moved from monitoring to enforcement only once the first three are solid.
- This report has no selector field, so it only tries the common selectors a mail provider is likely to use. If your domain uses a selector that is not on that list, check it directly with the DKIM checker instead.
- Yes - these checks read what is published, not what happens to a given message. A DKIM key can be correct and still not match a message signed by a server that was never added to the SPF record, which is exactly the alignment problem DMARC exists to catch.
- No more than running all four tools one after another would - it calls the same checks, just in one pass instead of four, and shows every lookup each one made underneath the result.
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.