DMARC troubleshooting: read Authentication-Results headers and fix alignment failures

dmarctutorialspfdkimarc

When DMARC fails, the DNS record is often blamed first.

In practice, the fastest path to the real cause is usually the message header, specifically the Authentication-Results line. That one line tells you what the receiver believed about SPF, DKIM, and DMARC at evaluation time.

If this still feels a bit abstract, that is normal. Header troubleshooting looks noisy at first, then suddenly becomes very systematic.

Start with the right mental model

DMARC does not care whether SPF or DKIM passed in isolation.

DMARC cares whether at least one of them passed and aligned with the visible From domain.

  • Visible From domain: From: alerts@example.com -> domain is example.com
  • SPF identity domain: usually the envelope sender / Return-Path domain
  • DKIM identity domain: d= value in the DKIM signature

If alignment still needs a quick refresher, this helps: DMARC alignment: From vs Return-Path (strict vs relaxed).

Where to find full headers

Provider-specific views are better than copy/pasting from mobile apps because they preserve the full auth context.

Once headers are open, search for:

  • Authentication-Results:
  • From:
  • Return-Path:
  • DKIM-Signature:

A real troubleshooting example

Suppose the message claims to be from example.com:

From: Billing Team <billing@example.com>
Return-Path: bounce-4321@mail.example.net
DKIM-Signature: v=1; a=rsa-sha256; d=mail.example.net; s=sel2026; ...
Authentication-Results: mx.google.com;
    spf=pass smtp.mailfrom=mail.example.net;
    dkim=pass header.d=mail.example.net;
    dmarc=fail (p=quarantine) header.from=example.com

This is the classic "everything passed except DMARC" pattern.

Why it fails:

  • SPF passed for mail.example.net, not aligned to example.com
  • DKIM passed for mail.example.net, also not aligned to example.com
  • So DMARC has no aligned pass to use

The common failure patterns (and the usual fix)

1) SPF pass, DMARC fail

Typical sign:

  • spf=pass
  • dmarc=fail
  • smtp.mailfrom domain differs from header.from

Typical fix:

  • Configure custom bounce/return-path so SPF uses a domain under example.com, or
  • Ensure DKIM signs with aligned d=example.com or a subdomain of it (under relaxed alignment)

2) DKIM pass, DMARC fail

Typical sign:

  • dkim=pass
  • header.d does not match (or align with) header.from

Typical fix:

  • Update signer config so DKIM uses a selector and d= under your From domain namespace

If this shows up often across tools, Your Google Workspace DKIM setup may be broken (and you may not know it) is a useful diagnostic companion.

3) Intermittent DMARC fail by source

Typical sign:

  • Same From domain
  • Some messages pass, others fail
  • Different sending systems or routes in headers

Typical fix:

  • Inventory all senders from DMARC aggregate reports, then standardize auth settings across each sender

Use this walkthrough for that part: DMARC reporting 101: how to read aggregate XML reports and take action.

A quick triage flow that works in production

When incident tickets are piling up, avoid deep theory first. Use this order:

  1. Confirm header.from domain.
  2. Check dmarc=pass/fail in Authentication-Results.
  3. If fail, compare smtp.mailfrom and header.d against header.from.
  4. Identify whether SPF alignment, DKIM alignment, or both are missing.
  5. Fix sender config, then send a fresh test and re-read headers.

That loop catches most real issues in minutes, not days.

ARC, forwarding, and why headers can look contradictory

You may see forwarded messages where original auth looked good but current SPF fails. That is expected because forwarding often changes the SMTP path.

In those cases, DKIM survival and ARC context become important, and the header may include extra ARC fields that explain why the receiver still made a trust decision.

No need to solve all ARC details on day one. First get comfortable reading base auth outcomes and alignment.

Keep these two habits

  • Always troubleshoot with real headers from the receiving mailbox provider, not just sender-side logs.
  • Keep a sender ownership map (which platform sends which stream) so auth fixes go to the right team quickly.

For operational scale, pair header analysis with aggregate telemetry from DMARC aggregate reports (RUA) explained: how to read the XML and take action.

Once this becomes routine, DMARC stops feeling like random pass/fail events and starts looking like what it really is: identity alignment with clear, repeatable diagnostics.

Previous Post