Can I verify authentication using only DNS lookups?

No. DNS proves records are published, but only a sent message proves the platform used the right envelope domain, signed with DKIM, and achieved DMARC alignment.

Why should I test every sending platform?

Each platform has its own mail path and authentication settings. Employee mail can pass while a CRM or website sends unauthenticated messages from the same visible domain.

What result matters most?

For visible-domain protection, DMARC pass is the key outcome. For resilience and provider requirements, aim for both SPF and DKIM to pass and align.

How often should I rerun the checks?

After every sender or DNS change, and regularly thereafter. Continuous monitoring is preferable because third-party dependencies can change without edits to your own zone.

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 July 14, 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 through the inbox test from each path in your inventory. Do not forward an old message; forwarding changes the route and may alter content. Trigger the exact production flow: send a campaign test from the marketing tool, a ticket reply from support, and a transactional event from the application.

SPF should pass for the envelope sender used by that platform.
DKIM should pass with a d= domain you recognize.
DMARC should pass, which means at least one passing identity aligns with the visible From domain.
The message should travel over TLS and show 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.com

A simplified healthy result: both methods pass and relate to the visible From domain.

Paste 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.