How to check SPF, DKIM, and DMARC for your domain
A complete email-authentication check has two halves: inspect the public DNS configuration, then inspect a message that actually left each sending platform. DNS can show a perfect SPF record and DKIM key even when the sender never uses them. A message can show authentication passes that belong to the provider rather than align with your visible From domain.
Updated August 16, 2026
Step 1 — inventory every sending path
List employee mail plus every service that sends as your domain: CRM, newsletter platform, helpdesk, invoicing, ecommerce, authentication emails, website forms, monitoring, and internal servers. Record the visible From domain, envelope/return-path domain, and expected DKIM signing domain for each.
Step 2 — check the DNS records
| Check | Healthy result | Common failure |
|---|---|---|
| SPF | One valid record, all senders included, fewer than 11 DNS lookups | Multiple records, missing include, PermError |
| DKIM | Every active selector resolves to a valid public key | Wrong host, missing key, signing not enabled |
| DMARC | One valid record at _dmarc, reporting configured, intentional policy | Record at root, invalid syntax, duplicate record |
| MX | Expected inbound provider hosts in correct preference order | Old provider entries or reversed priorities |
Use the SPF checker, DKIM checker, DMARC checker, and MX lookup. Checkers should resolve nested dependencies rather than merely display the first TXT value.
Step 3 — send a real message from every platform
Send each production flow to the email deliverability check to verify DKIM and alignment and review selected message-level signals. Also deliver that flow to a mailbox and inspect its raw headers with the header analyzer for the receiving provider's live SPF, DMARC, TLS, and routing results. Do not forward an old message; forwarding changes the route and may alter content.
- The scorecard should show a verified DKIM signature aligned with the visible From domain.
- The mailbox's Authentication-Results should show SPF passing for the expected envelope sender.
- DMARC should pass through at least one aligned authentication method.
- The received headers should show TLS and the expected sending infrastructure.
Step 4 — read Authentication-Results and alignment
Authentication-Results: mx.example;
spf=pass smtp.mailfrom=bounces.example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comPaste raw headers into the header analyzer instead of relying on a mail client's green checkmark. Compare smtp.mailfrom, DKIM's header.d, and DMARC's header.from. If SPF and DKIM pass but DMARC fails, you have an alignment problem, not a missing-record problem.
Step 5 — monitor after the snapshot
A clean audit is a point-in-time result. DNS changes, provider key rotations, new SaaS tools, and SPF include expansion can break it later. DMARC aggregate reports reveal sources you missed and show how real traffic authenticates across receivers.
Save the inventory, retest after every platform change, and monitor DNS plus DMARC reports continuously. HealthCheck Email performs daily record checks, tracks the grade over time, labels sending sources, and alerts you when a working setup changes.
Sources and further reading
- RFC 7208 — Sender Policy Framework (SPF) — The definitive SPF syntax, evaluation, and processing-limit specification.
- RFC 6376 — DomainKeys Identified Mail (DKIM) — The definitive DKIM signing, selector, key, and verification specification.
- RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — The DMARC policy, alignment, reporting, and record-format specification.