DMARC fails while SPF passes: understanding alignment

<policy_evaluated>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
…
<auth_results>
  <spf>
    <domain>bounces.esp-mail.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

Alignment, the requirement DMARC adds

DMARC closes precisely this gap, and the core idea behind DMARC comes down to exactly that: tying technical authentication to the address a human actually sees. The DMARC verdict is a pass if — and only if — at least one of the two mechanisms succeeds and the domain it validated aligns with the From: domain. For SPF, the compared domain is that of the MAIL FROM; for DKIM, it is the d= of the signature.

Alignment comes in two modes, set by two tags in the DMARC record. In relaxed mode (aspf=r, adkim=r — the defaults, rarely written out), sharing the same organizational domain is enough: bounce.example.com aligns with example.com. Since DMARCbis, that organizational domain is determined by the DNS Tree Walk — climbing the DNS tree — rather than by the old Public Suffix List. In strict mode (aspf=s, adkim=s), the match must be exact: bounce.example.com no longer aligns with example.com.

A typical record is therefore nothing exotic:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

The relaxed modes apply implicitly. And one capital point, very often missed: DMARC does not require both mechanisms to align. One is enough. An unaligned SPF combined with an aligned DKIM yields dmarc=pass — and that, as the fixes will show, is the key to most remediations.

Three typical cases behind the symptom

An unaligned spf=pass almost never happens by accident. Three configurations account for the bulk of what aggregate reports show.

Case 1: the sending platform passing SPF with its own domain. The great classic. An email platform — Mailchimp, Brevo, SendGrid, Mailjet — sends the example.com newsletter with, by default, an envelope set on the platform's own domain: MAIL FROM bounces.esp-mail.net. The platform manages its SPF, the IP is authorized, spf=pass — for esp-mail.net. The From: shows example.com: no alignment is possible, the two domains are strangers to one another. If, on top of that, the default DKIM signature carries d=esp-mail.net, the failure is total: everything is authenticated, yet nothing is authenticated in the right domain's name.

Case 2: forwarding that rewrites the envelope. A message perfectly aligned at departure is sent to an address that forwards — a former employee's alias, a university mailbox redirected to a personal account. The relaying server ends up emitting from an IP absent from the original sender's SPF; to avoid a rejection, many rewrite the envelope in their own name (the SRS mechanism). The outcome: spf=pass, but for the forwarder's domain — unaligned once again. The full mechanics are detailed in why forwarding breaks the check. The saving nuance: the DKIM signature travels with the message and survives as long as the content stays untouched — hence the weight of "one is enough."

Case 3: the misaligned subdomain. The organization sends with MAIL FROM on newsletter.example.com and From: on example.com. In relaxed mode, all is well: same organizational domain. But if the record enforces aspf=s, the pass turns unaligned overnight. A sneakier variant: a separate technical domain, example-mailing.com, chosen years ago "to isolate the sending traffic." That one will never align with example.com, not even in relaxed mode: these are two distinct organizational domains.

Spotting the unaligned pass in an aggregate report

There is no need to redo report theory here — working through the daily returns covers it field by field. For this specific symptom, a single reflex is enough: comparing the header_from domain with the domain attached to the SPF result. If the result is pass but the two domains differ — and do not share an organizational domain — the row describes an unaligned pass, counted as a failure on the DMARC side.

The reading pays off when done per source. A platform IP showing nothing but unaligned passes signals a default configuration that was never customized (case 1). Scattered, low-volume rows carrying SPF domains that belong to ISPs or universities betray forwarding (case 2). And a sudden flip of an entire flow from aligned to unaligned often accompanies an aspf tag change or a platform migration (case 3). The symptom is identical in all three; the remedy depends on the diagnosis.

The fixes: a custom return-path and aligned DKIM

The custom return-path domain. For the platform case, the fix has a name at every serious provider: custom return-path, bounce domain, envelope domain. The principle: creating a dedicated subdomain — bounce.example.com — pointed by CNAME at the platform's infrastructure. The envelope of the sendings becomes MAIL FROM bounce.example.com: the platform's SPF still clears the IP, but the pass now benefits a subdomain of example.com, aligned in relaxed mode. A few DNS records, zero change to message content.

The aligned DKIM signature. The most robust fix lies elsewhere: having messages signed with d=example.com, through the keys or CNAMEs the platform provides at domain setup. An aligned DKIM makes the DMARC verdict independent of the envelope's fate: it survives forwarding, depends on no SRS rewriting, and suffices on its own to produce dmarc=pass. Which is why the doctrine fits in one line: aligned DKIM first, aligned SPF as the safety belt — and both wherever the platform allows it, which is the norm today.

Strict mode remains the special case: before enforcing aspf=s or adkim=s, an inventory of the sending subdomains is indispensable, otherwise the mode-hardening itself manufactures unaligned passes. Relaxed mode, the default, covers the vast majority of real-world needs.

What alignment changes for p=reject

As long as the policy stays at p=none, an unaligned pass costs nothing: messages arrive, reports pile up, the symptom remains academic. At p=reject, that same row becomes refused mail. Every legitimate source still unaligned at hardening time turns into a deliverability incident — invoices that stop arriving, HR notifications silently rejected.

The graduation criterion is therefore simple to state: every legitimate source must produce at least one aligned pass, preferably via DKIM, before the policy hardens. Ordinary forwarding clears that bar thanks to DKIM; the stubborn case remains mailing lists, which modify the content — breaking DKIM — while also rewriting the envelope — knocking SPF out of alignment. For the transition itself, DMARCbis provides an explicit test mode (t=y), successor to the old pct tag removed from the standard, which announces a strict policy while signalling a trial phase to receivers.

In summary

spf=pass and dmarc=fail on the same row is neither a bug nor a contradiction: SPF validated the envelope's domain, and DMARC observes that this domain does not match the displayed From:. The pass exists, but it benefits the wrong domain. Three configurations produce most of the symptom — the platform left on its default envelope, the forwarder rewriting the MAIL FROM, the subdomain or sibling domain out of alignment — and two fixes deal with all of it: the custom return-path domain, which re-aligns SPF, and the DKIM signature under the domain's own d=, which keeps the verdict robust even through forwarding. A single aligned mechanism satisfies DMARC; having both is the safety margin that turns p=reject into a serene move.

The diagnosis requires opening no XML file at all: a free DMARC analysis of the domain highlights, source by source, the passes that fail to benefit the right domain and the real state of alignment. Creating an account then makes it possible to watch, report after report, each source climb into alignment — until the day the move to p=reject is no longer a leap of faith, but a formality.