Why mail authentication needs three records, not one
SPF, DKIM, and DMARC each solve a different piece of the "is this email really from who it claims" problem, and none of them work alone. These four tools cover checking all three together, building each record without memorizing syntax, and reading the actual delivery evidence when something still goes wrong.
📖 For a deeper walkthrough, see the guide: Why Is My Email Landing in Spam?
Mail Auth Check — the combined view
Mail Auth Check checks SPF, DKIM, and DMARC for a domain together and reports whether they're correctly configured and aligned with each other — not just whether each record individually exists.
When to use it: quick verification after setting up or changing any of the three records, diagnosing why a message passed SPF but still failed DMARC, or as a faster alternative to the full NODA Check when mail authentication is the only thing you care about right now.
Reading results: DMARC requires SPF or DKIM to be in "alignment" — the domain in the visible From header has to match, or be a subdomain of, the domain actually authenticated by SPF or DKIM. A record can individually pass and still fail alignment, which is the most common reason a DMARC report shows failures even though SPF and DKIM both look fine on their own.
SPF Builder — who's allowed to send
SPF Builder helps construct a valid SPF TXT record by selecting which servers and services are authorized to send mail for your domain, then generates the correct mechanism syntax.
When to use it: setting up SPF for the first time, adding a new sending service (marketing platform, CRM, transactional provider) to an existing record, or cleaning up a record that's grown unwieldy with duplicate mechanisms.
Reading results: watch the total DNS lookup count. SPF has a hard limit of 10 lookups, and exceeding it causes a permanent error that fails authentication for everyone — including legitimate senders. Each include: mechanism counts toward that limit, so consolidate where you can rather than stacking more includes.
DMARC Builder — policy and reporting
DMARC Builder helps construct a valid DMARC record — policy (none, quarantine, reject), aggregate and forensic reporting addresses, and alignment settings — without memorizing tag syntax.
When to use it: setting up DMARC for the first time, moving from a p=none monitoring policy to actual enforcement, or adding/changing reporting addresses to start receiving aggregate reports.
Reading results: always start with p=none and watch the aggregate reports for a few weeks before moving to enforcement. Jumping straight to p=reject on a domain with sending sources you haven't fully inventoried — marketing tools, CRM, internal scripts — can silently break mail from those sources with no warning.
Email Header Analyzer — the ground truth
Email Header Analyzer parses the raw headers from any email — the delivery path (each server hop), timing, and the SPF/DKIM/DMARC authentication results actually recorded by the receiving server.
When to use it: investigating why a legitimate email landed in spam, tracing which server in a chain introduced a delay, or confirming whether authentication actually passed rather than trusting what the sender claims.
Reading results: read the "Received" headers bottom-to-top — that's the real chronological path the message took. The Authentication-Results header, added by the receiving server, is the ground truth for pass/fail; it's independent of anything the sending system claims about itself.
How these fit together
Build SPF and DMARC first (DKIM is set up at the mail-sending service, not built here), verify all three with Mail Auth Check, and if something still looks wrong after a real message was sent, pull the actual headers with Email Header Analyzer — that's the only tool of the four that shows what a receiving server genuinely decided, rather than what your own records say they should decide.