SPF & DMARC Checker — Verify Sender Authentication

What SPF and DMARC actually control

SPF declares which servers may send for a domain; DMARC tells receivers what to do when authentication fails. Together they decide how much of your mail reaches inboxes versus spam — and whether attackers can spoof your domain convincingly. Missing records are among the cheapest deliverability wins available: both are plain DNS records you can publish in minutes.

This checker reads each domain's SPF record and its DMARC policy at _dmarc over DNS-over-HTTPS, only after you click run, sending domain names only.

Reading the results

Pass means the record exists and parses. Missing means the lookup completed and found nothing — a concrete to-do for whoever owns the domain's DNS. Unknown means DNS was unreachable; retry rather than concluding anything.

• SPF pass + DMARC pass → authentication baseline covered
• Missing SPF → spoofing is easy; publish a record
• Missing DMARC → receivers get no failure instruction; publish p=none first, then enforce

Rollout order that doesn't break legitimate mail

Publish SPF first: enumerate every legitimate sender (your mail platform, CRM, helpdesk, transactional service) before writing the record, and end it with a soft fail while you monitor. Then publish DMARC at p=none with a reporting mailbox — receivers start sending aggregate reports without quarantining anything, and those reports reveal the forwarders, legacy systems and shadow IT you forgot to include in SPF.

Only after the reports show a clean pass rate do you tighten DMARC toward quarantine and eventually reject, and only then do you harden SPF's ending. Teams that jump straight to p=reject routinely silence their own invoicing system or support desk for days; the monitor-first sequence costs two weeks and saves that outage. Re-run this checker after each DNS change — propagation takes minutes to hours — and keep the passing output as the artifact for compliance reviews.

• SPF with soft fail → DMARC p=none with reports → quarantine → reject
• Inventory every sender before writing SPF, not after
• Re-check after each change; DNS propagation is not instant

What the checker can't see (and how to check it)

Alignment is the blind spot: SPF and DMARC pass individually yet mail still fails DMARC when the header-from domain doesn't align with the envelope sender or DKIM domain — the classic symptom when a CRM sends 'from' your domain through its own infrastructure. If your records pass here but delivery still suffers, inspect raw headers of a received message for authentication-results lines naming the failing mechanism.

Forwarding is the second blind spot: mailing lists and auto-forwarders break SPF by design (the forwarder's IP was never in your record), which is exactly the failure DMARC alignment plus DKIM survival is meant to absorb. The checker reports record presence, not forwarding survivability — monitor DMARC aggregate reports for the forwarder population rather than expecting a green check here to guarantee inboxing.

Why DKIM isn't auto-checked

DKIM records live under a per-domain selector such as default._domainkey, and selectors can't be discovered reliably — guessing them would burn DNS queries and still miss. To check yours, query TXT at SELECTOR._domainkey.YOURDOMAIN with any DNS lookup tool, replacing SELECTOR with the value your mail provider gave you.

Keep reading