SPF, DKIM, DMARC: Auditing Your Email Authentication Stack

If your domain sends email — transactional, marketing, or just the occasional contact form reply — SPF, DKIM, and DMARC decide whether those messages land in the inbox, the spam folder, or get rejected outright. Gmail and Yahoo now require all three for bulk senders, and Microsoft is tightening the screws too. The problem is that most domains have something configured, but rarely have it configured correctly.

This walkthrough shows you exactly how to inspect each record, what valid output looks like, and how to confirm authentication is passing end-to-end on real messages.

What each record actually does

Before checking anything, be clear on what you're verifying:

• SPF (Sender Policy Framework) — A DNS TXT record listing which IP addresses and hosts are permitted to send mail using your domain in the envelope-from address.
• DKIM (DomainKeys Identified Mail) — A public key published in DNS that receivers use to verify a cryptographic signature added to outgoing messages.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) — A policy that tells receivers what to do when SPF or DKIM fail, and where to send aggregate reports.

DMARC only passes when at least one of SPF or DKIM passes and aligns with the visible From: domain. Alignment is where most setups quietly break.

Checking your SPF record

Pull the raw record

From any terminal:

dig +short TXT yourdomain.com

You're looking for something like:

"v=spf1 include:_spf.google.com include:mailgun.org ~all"

What to verify

1. Exactly one SPF record exists. Multiple v=spf1 records on the same domain cause a permerror and SPF will fail entirely.
2. The DNS lookup count is under 10. Every include:, a, mx, and redirect counts. Nested includes count too. Over 10 and SPF returns permerror.
3. The qualifier is appropriate. ~all (softfail) is reasonable while testing; -all (hardfail) is the production target. +all is dangerous — it authorises the entire internet.
4. Every sending service is included. Forgotten ones: your help desk, CRM, invoicing tool, newsletter platform, monitoring alerts.

Checking your DKIM record

DKIM is published under a selector — a label chosen by the sending service. You need to know the selector to query it. Common ones:

• Google Workspace: google
• Microsoft 365: selector1 and selector2
• Mailgun: k1 or mta
• SendGrid: s1 and s2
• Mailchimp: k1

Query the selector record:

dig +short TXT google._domainkey.yourdomain.com

A healthy response contains v=DKIM1; k=rsa; p= followed by a long base64 public key. Things to verify:

• The key isn't truncated (a sign of misconfigured DNS provider character limits).
• You're using 2048-bit keys where the provider supports it.
• Every selector your sending platforms use is published — multi-vendor setups frequently miss one.

Don't trust the DNS — trust the signature

A DKIM record can exist in DNS but messages can still fail signing if the provider isn't actually configured to sign. Send a test message to yourself and inspect the headers. Look for:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com

If you see dkim=none, the message wasn't signed. If you see dkim=fail, the signature is broken — often from a misaligned selector or DNS propagation lag.

Checking your DMARC record

DMARC always lives at _dmarc.yourdomain.com:

dig +short TXT _dmarc.yourdomain.com

A solid production record looks like:

"v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1; adkim=s; aspf=s; pct=100"

Audit checklist

• Policy (p=) — none is monitor-only, quarantine sends to spam, reject blocks outright. If you're still at p=none months after setup, you're not actually enforcing anything.
• Reporting address (rua=) — Without this, you have no visibility into who's sending as your domain.
• Alignment mode — adkim=s and aspf=s mean strict alignment (subdomain must match exactly). Default is relaxed, which is fine for most setups but worth being explicit.
• Subdomain policy (sp=) — Omit this and subdomains inherit the main policy. Set it explicitly if you want different behaviour.

Verifying end-to-end with real headers

DNS records tell you what should happen. Email headers tell you what actually happened. Send a message from each of your sending platforms to an inbox you control, then view the full source and locate the Authentication-Results header.

What you want to see:

spf=pass smtp.mailfrom=yourdomain.com
dkim=pass header.i=@yourdomain.com
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Parsing raw email headers by eye is tedious — newlines, folded headers, and base64 chunks make it easy to miss the relevant lines. The AXOX Hub Email Header Analyzer extracts the authentication results, hop-by-hop delivery path, and originating IP into a readable view, so you can confirm each sending source is passing alignment without grep-ing through 200 lines of headers.

Common failures and what they mean

SPF passes but DMARC fails

Usually an alignment problem. Your envelope-from is something like bounces.sendgrid.net but your visible From: is yourdomain.com. Fix it by configuring a custom return-path / bounce domain at your ESP.

DKIM passes but DMARC fails

The DKIM signing domain (d= tag in the signature) doesn't match the From: domain. Switch the ESP to sign with your domain rather than its own.

Intermittent SPF failures

You've exceeded the 10 lookup limit, or one of your include: targets is itself broken. Flatten where possible, or drop unused providers.

DMARC reports stop arriving

The rua mailbox is full, blocking inbound, or the receiving domain is different from the DMARC domain and you haven't authorised it with an _report._dmarc record.

An audit routine that catches problems early

1. List every service that sends mail using your domain — including the ones marketing set up last quarter without telling anyone.
2. Query SPF, every DKIM selector, and DMARC via dig or your DNS provider's interface.
3. Send a test from each platform to an inbox you control.
4. Inspect headers and confirm dmarc=pass with correct alignment for every source.
5. Review weekly DMARC aggregate reports for unexpected sources — shadow IT, spoofing attempts, or forgotten platforms.
6. Repeat after any DNS, ESP, or vendor change.

Run a fresh check against a real message right now: paste the raw headers into the AXOX Hub Email Header Analyzer and confirm SPF, DKIM, and DMARC are all reporting pass with proper alignment — before a deliverability issue forces you to find out the hard way.