Email Auth Checker - SPF, DKIM & DMARC

Q: What's the difference between SPF, DKIM, and DMARC?

Three layered DNS-based mechanisms. SPF (RFC 7208 Kitterman, 2014) is a TXT record listing which IP addresses or hosts are authorised to send email from your domain — receiving servers compare the connecting IP to the list. DKIM (RFC 6376 Crocker, Hansen & Kucherawy, 2011) attaches a cryptographic signature to outgoing messages using a private key; receivers fetch the matching public key from your DNS (selector-based) and verify the signature. DMARC (RFC 7489 Kucherawy & Zwicky, 2015) adds the alignment policy: it specifies what receivers should do (none, quarantine, reject) when SPF and/or DKIM fail to align with the From header — and where to send aggregate (rua) or forensic (ruf) reports. Used together, SPF authorises the sender, DKIM signs the content, and DMARC ties them to the visible From identity.

Q: What is alignment in DMARC and why does SPF alone fail?

Alignment means the domain that passes SPF or DKIM must match the visible From header domain. SPF authenticates the Return-Path (envelope sender), not the From header — so an attacker can pass SPF using a third-party sender they legitimately control while spoofing your From. DMARC closes that gap by requiring SPF or DKIM to align: same domain (strict alignment) or same organisational domain (relaxed, the default). For example, an email from `from@example.com` with Return-Path `bounces@example.com` aligns SPF; with Return-Path `service@mailer.com`, SPF passes but doesn't align. DKIM alignment compares the d= signing domain to the From domain. At least one — SPF or DKIM — must pass AND align for DMARC to pass. Hence SPF alone is insufficient to prevent spoofing.

Q: What does ARC do and why was it added?

ARC (Authenticated Received Chain, RFC 8617 Andersen, Long, Blank & Kucherawy, July 2019) preserves authentication evidence across forwarding hops. The problem: legitimate forwarders (mailing lists, alumni forwarders, Microsoft 365 tenant relays) often modify the message — adding subject prefixes, footer text, or rewriting Subject — which breaks DKIM signatures. SPF also breaks because the forwarder is not the original authorised sender. Without ARC, mail from a forwarded list to a Gmail user routinely fails DMARC and lands in spam, even though the original sender was legitimate. ARC adds three headers — ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal — that capture the receiving server's authentication assessment at each hop. The final receiver can trust the chain back to the original verified sender, allowing the message through despite later modifications.

Q: What changed for bulk senders in February 2024?

Google and Yahoo introduced stricter requirements for bulk senders effective 1 February 2024 (announced October 2023). Senders shipping ≥5,000 messages per day to Gmail or Yahoo accounts must: (1) publish a DMARC record (initial requirement p=none monitoring; June 2024 minimum compliance threshold); (2) authenticate with both SPF and DKIM, with at least one aligned to the From header; (3) maintain valid forward and reverse DNS (PTR records) for sending IPs; (4) transmit over TLS-encrypted connections; (5) include a one-click List-Unsubscribe (RFC 8058 mailto: + HTTP POST) for marketing mail; (6) keep Postmaster Tools spam rate below 0.10% (avoiding the 0.30% blocklist threshold). Failure to meet these triggers temporary delivery delays, eventually rejection. The shift reflects a multi-year industry move from 'authentication is best practice' to 'authentication is required for inbox placement at major mailbox providers'.

Q: Why does my legitimate email still land in spam?

Even properly authenticated mail can hit spam for content or reputation reasons. Common causes: (1) DMARC alignment passes but DKIM signature is on a tracking-redirector domain, not the visible brand; (2) sending IP has poor reputation history (acquired from a previous tenant); (3) the From domain is new (<30 days) and lacks engagement history; (4) URL or attachment patterns match phishing heuristics (URL shorteners, .zip/.exe attachments); (5) the mail body contains spam-trigger keywords paired with marketing-style HTML; (6) the recipient marked previous mail from your domain as spam, training their personal filter. Authentication is necessary but not sufficient — content quality, list hygiene, IP warming, and engagement metrics all factor in.

Email Auth Checker — SPF, DKIM, DMARC, ARC + 2024 Bulk Sender Rules

Email authentication uses DNS-based mechanisms to verify that messages claiming to come from your domain were actually authorised to do so. The three pillars are SPF (RFC 7208 Kitterman, 2014), DKIM (RFC 6376 Crocker, Hansen & Kucherawy, 2011), and DMARC (RFC 7489 Kucherawy & Zwicky, 2015). SPF lists authorised sending IPs; DKIM cryptographically signs outgoing messages; DMARC requires SPF or DKIM to align with the visible From header and tells receivers (none/quarantine/reject) what to do when alignment fails. ARC (RFC 8617 Andersen, Long, Blank & Kucherawy, July 2019) preserves authentication evidence across legitimate forwarders that would otherwise break SPF/DKIM. As of 1 February 2024, Google and Yahoo enforce stricter requirements for bulk senders (≥5,000 messages/day): DMARC published, SPF and DKIM aligned, valid PTR records, TLS, one-click List-Unsubscribe (RFC 8058), spam rate <0.10%. This tool queries the public DNS for all three records and parses them — same data any receiving mail server uses to score your domain.

How to check email authentication

Enter a domain (not an email address — only example.com).
The tool looks up SPF, DKIM, and DMARC DNS records via Cloudflare DoH and parses them.
Review each record and the 'how your domain authenticates email' summary, including the alignment policy and reporting endpoints.
Fix any weak settings — a missing DMARC record or SPF with '+all' leaves your domain wide open to spoofing; not meeting the 2024 Google/Yahoo bulk sender rules will degrade delivery to those mailboxes.

Common use cases

Auditing a new domain's SPF, DKIM, and DMARC before sending marketing email from it (especially relevant under 2024 Google/Yahoo enforcement for ≥5,000 msg/day senders).
Debugging why legitimate email from a domain is landing in spam — alignment, IP reputation, content patterns all factor in.
Checking a vendor's email authentication before relying on their transactional mail (DMARC p=reject + DKIM aligned = strong signal).
Hardening DMARC from p=none to p=quarantine after a few weeks of rua= reporting confirms no legitimate sources break.

Frequently asked questions

What's the difference between SPF, DKIM, and DMARC?

Three DNS layers. SPF (RFC 7208) lists authorised sending IPs. DKIM (RFC 6376) signs outgoing mail with your private key. DMARC (RFC 7489) requires SPF or DKIM to ALIGN with the From header — and tells receivers what to do (none/quarantine/reject) when alignment fails.

What is alignment in DMARC and why does SPF alone fail?

SPF authenticates Return-Path (envelope), not the visible From. An attacker can pass SPF via a third-party domain while spoofing your From. DMARC requires SPF or DKIM to ALIGN with From — same domain (strict) or same organisational domain (relaxed). At least one must pass AND align.

What does ARC do and why was it added?

ARC (RFC 8617, July 2019) preserves authentication across forwarders that modify messages — mailing lists, M365 relays. Three headers (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) capture each hop's verdict. Receivers can trust the chain back to the original verified sender.

What changed for bulk senders in February 2024?

Google + Yahoo enforce stricter rules for senders ≥5,000 msg/day to their accounts: DMARC published, SPF + DKIM aligned, valid PTR records, TLS connections, one-click List-Unsubscribe (RFC 8058), spam rate <0.10%. Effective 1 Feb 2024.

Why does my legitimate email still land in spam?

Authentication is necessary but not sufficient. IP reputation, sender domain age, content patterns (URL shorteners, suspicious attachments), recipient engagement history, and previous spam markings all factor in alongside SPF/DKIM/DMARC pass.

How SPF, DKIM, DMARC layer together — and why ARC matters for forwarders

When an inbound mail server receives a message, it checks: (1) Is the connecting IP authorised by the sender's SPF record? (2) Does the DKIM signature verify against the public key fetched from the d= domain in the signature header? (3) Does the DMARC policy require alignment of SPF or DKIM with the visible From header — and what should the receiver do (none/quarantine/reject) when alignment fails? Without DMARC, a passing SPF on a third-party Return-Path doesn't prove the From header is legitimate; this gap is what makes SPF alone insufficient against display-name spoofing. The reporting layer matters too: the rua= aggregate URI in the DMARC record receives daily XML reports from major mailbox providers showing which IPs sent on behalf of your domain and their authentication results — invaluable for catching unauthorised senders or misconfigured services. The 2024 Google/Yahoo bulk sender enforcement raised the bar: senders ≥5,000 msg/day to those providers must publish DMARC and align SPF/DKIM or face delivery degradation. The trend is clear: authentication has moved from 'recommended' to 'required for inbox placement' at the providers handling most of the world's email volume. Forwarders complicate the picture; ARC's three headers (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) preserve the upstream verdict so legitimate mail through mailing lists or alumni relays still passes DMARC at the final destination.

SPF record detection and validation per RFC 7208 (qualifiers, ~10 lookup limit)
DKIM selector discovery (9 common selectors) per RFC 6376
DMARC policy analysis per RFC 7489 (none / quarantine / reject + alignment + reporting URIs)
ARC chain detection per RFC 8617 (forwarder-aware)
2024 Google/Yahoo bulk sender requirements check (≥5,000 msg/day compliance)
Cloudflare DNS-over-HTTPS lookup with full record text display

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (6)

Kitterman, S. (2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. RFC 7208, IETF.
Crocker, D., Hansen, T., & Kucherawy, M. (Eds.) (2011). DomainKeys Identified Mail (DKIM) Signatures. RFC 6376, IETF.
Kucherawy, M., & Zwicky, E. (Eds.) (2015). Domain-based Message Authentication, Reporting, and Conformance (DMARC). RFC 7489, IETF.
Andersen, K., Long, B. (Ed.), Blank, S. (Ed.), & Kucherawy, M. (Ed.) (2019). The Authenticated Received Chain (ARC) Protocol. RFC 8617, IETF (July 2019).
Levine, J. (2017). Signaling One-Click Functionality for List Email Headers. RFC 8058, IETF.
Google + Yahoo Postmaster (2024). Bulk Sender Requirements (≥5,000 messages/day). Effective 1 February 2024 — DMARC + aligned SPF/DKIM + valid PTR + TLS + one-click unsubscribe + spam rate <0.10% (support.google.com/mail/answer/81126).

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.

Related guides

Email Authentication — SPF, DKIM, and DMARC Explained ProperlyHow SPF, DKIM and DMARC actually work together to authenticate email, with the gotchas that break deliverability in production.

By Marco B. · Last verified June 2026 — runs in your browser