Passes Auth, Fails DMARC: The Alignment Trap

A message can pass SPF, pass DKIM, and still fail DMARC because DMARC does not check whether authentication passed. It checks whether the domain that authenticated is the same domain the reader sees in the From header. That second check is identifier alignment, and it is where most "but my SPF and DKIM are green" tickets actually die.

RFC 7489 builds DMARC on top of SPF and DKIM but adds a requirement neither of them has. SPF authenticates an envelope domain; DKIM authenticates whatever domain signed the message. Neither cares about the visible From:. DMARC ties the result back to the From: domain, so authentication that succeeds on a different domain gives you a clean SPF/DKIM pass and a DMARC fail.

The Three Identifiers

There are three domains in play, and conflating them is the whole bug:

• RFC5321.MailFrom: the envelope sender, the domain in the SMTP MAIL FROM command. This is what SPF authenticates.
• d= in the DKIM-Signature header: the domain that signed the message. This is what DKIM authenticates.
• RFC5322.From: the From: header the recipient reads. This is what DMARC evaluates.

RFC 7489 is explicit about why the header From is the anchor: "The domain in the RFC5322.From field is extracted as the domain to be evaluated by DMARC." DMARC then asks whether either authenticated identifier aligns with that header domain.

What Pass Actually Requires

RFC 7489: "A message satisfies the DMARC checks if at least one of the supported authentication mechanisms (1) produces a 'pass' result, and (2) produces that result based on an identifier that is in alignment."

Both conditions, on at least one mechanism. A pass that is not in alignment does not count. SPF can pass on bounces.vendor.net while the From: says [email protected]; that is a real SPF pass and a DMARC fail, because vendor.net is not aligned with example.com.

Relaxed vs Strict Alignment

DMARC has two alignment modes per mechanism, set by the aspf and adkim tags. Both default to relaxed. RFC 7489: "default is 'r'."

For DKIM:

• Relaxed: "the Organizational Domains of both the DKIM-authenticated signing domain and that of the RFC5322.From domain must be equal."
• Strict: "only an exact match between both of the Fully Qualified Domain Names (FQDNs) is considered to produce Identifier Alignment."

For SPF:

• Relaxed: "the SPF-authenticated domain and RFC5322.From domain must have the same Organizational Domain."
• Strict: "only an exact DNS domain match is considered to produce Identifier Alignment."

The Organizational Domain is derived using the Public Suffix List: take the domain, find the longest matching public suffix, and prepend one more label. So mail.example.com and bounces.example.com share the Organizational Domain example.com and align in relaxed mode, but fail strict, which demands the FQDNs match exactly.

The Classic Alignment Failures

A From: of [email protected] sent through an ESP, with this envelope:

MAIL FROM: <[email protected]>
From: [email protected]
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...

spf=pass     ([email protected])
dkim=pass    (d=example.com)
dmarc=pass   (SPF not aligned: esp-vendor.net != example.com; DKIM aligned)

SPF passes but does not align because the bounce domain belongs to the vendor. DMARC still passes here, but only because DKIM was signed with d=example.com and that aligns. Pull the DKIM signature and the same message becomes:

spf=pass
dkim=none
dmarc=fail   (only authenticated identifier, esp-vendor.net via SPF, does not align)

Authentication still passed. DMARC failed. This is the exact shape of "we set up SPF, why are we failing DMARC": the ESP signs with its own d= or does not sign at all, the bounce domain is the vendor's, and nothing aligns to example.com.

The mirror case is subdomain strictness. A retailer publishes aspf=s and sends from From: [email protected] with MAIL FROM: <[email protected]>. Relaxed would align on the shared Organizational Domain; strict rejects it because example.com is not an exact match for shop.example.com. The policy chose strict, so a legitimate stream fails.

How To Read It In A Report

Aggregate DMARC XML gives you the four facts you need per source:

<record>
  <row><source_ip>203.0.113.9</source_ip><count>418</count>
    <policy_evaluated><disposition>none</disposition>
      <dkim>fail</dkim><spf>pass</spf></policy_evaluated></row>
  <identifiers><header_from>example.com</header_from></identifiers>
  <auth_results>
    <spf><domain>esp-vendor.net</domain><result>pass</result></spf>
  </auth_results>
</record>

Read it as: SPF authentication passed on esp-vendor.net, but the alignment column (policy_evaluated/spf) shows the result after the alignment check against header_from. When auth_results says pass and policy_evaluated says fail, you are looking at an alignment failure, not an authentication failure. The fix is to align an identifier with the header domain: have the ESP sign DKIM with a key delegated under your domain, or set a custom return-path subdomain so SPF authenticates a domain that shares your Organizational Domain.

The Reliable Fix Is DKIM Alignment

SPF alignment depends on the bounce domain, which many vendors control. DKIM alignment depends only on the signing domain, and you can delegate a DKIM selector under your own domain to nearly any reputable ESP. Aligning DKIM survives forwarding too, since SPF breaks the moment a message is relayed. For a stream you do not fully control, getting d= to match your Organizational Domain is the durable answer.

If you are preparing for an email-infrastructure interview, practice saying the distinction cleanly out loud: SPF and DKIM authenticate; DMARC checks that the authenticated domain aligns with the visible From. The candidates who can trace a single message from MAIL FROM through d= to header_from and explain exactly where alignment broke are the ones who clearly know the protocol rather than the dashboard.