Build1 publisher3 min readPublished
Two authentication passes on unrelated domains still fail DMARC alignment
A dev.to walkthrough traces a newsletter whose SPF and DKIM both pass for example.net while the visible From reads editorial.example. The evidence that settles it sits in the receiver's Authentication-Results header.
The Engineer · Build desk
What happened
- DMARC passes when either an aligned SPF result or an aligned DKIM result passes, and the dev.to post states plainly that the pass does not guarantee inbox placement.
- At least one path has to both authenticate and align with the visible From domain, so two authentication passes on unrelated domains still fail alignment.
- The debugging procedure begins with a message delivered to a mailbox you control and reads the receiver's Authentication-Results field, repeated per receiving system.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A DMARC pass is evidence in a spam-placement investigation, so authentication and inbox placement have to be tracked as separate work items with separate owners.
- cost The cheap fix, another SPF mechanism, does not change the alignment comparison; the sender has to move a return-path or signing domain it controls, plus a publish-and-test cycle on every real sending path.
- exposure During a zone move the receiver evaluates the published answer, so an operator reading a management screen can be confidently wrong about what every mailbox provider just saw.
- decision Tightening to strict alignment becomes a decision about which subdomain sending paths get retired first, because they pass today only under the relaxed default.
Alignment is a comparison between two domains, and the receiver is the one performing it. SPF supplies the domain from its authenticated identifier, which shows up in received diagnostics as the envelope-from or return-path domain [3]. DKIM supplies the domain in the signature's d= tag [4]. DMARC compares one of those against the domain in the RFC5322 From header, the address a reader normally sees [2].
Take the newsletter case in the dev.to post. Visible From is editorial.example. The bounce domain is bounce.mailer.example.net, and a valid DKIM signature carries d=mailer.example.net, so both mechanisms pass for example.net while neither identifier aligns with editorial.example [6]. Adding another unrelated SPF mechanism does not change that comparison; the post's repair is to move at least one authenticated path onto a domain organizationally related to the visible From and under the sender's control, then publish the record and test it [7].
Relaxed alignment compares organizational domains and is the default under RFC 7489, while strict requires an exact domain match and is selected with the aspf and adkim tags [8]. A subdomain path that passes today can therefore fail the day someone publishes the tighter policy [9].
The order of work is headers first, DNS second: headers establish what happened to this message, and DNS explains why [18]. For one sending path the DNS side is three authoritative lookups, at _dmarc under the From domain, at the selector beneath _domainkey under the signing domain, and at the relevant SPF domain [13]. During a migration the post asks for more than one recursive resolver, so the reconciliation is at least six answers per path, each compared against the versioned intent in the repository [1].
A management UI showing the record you meant to publish is describing your intent back to you. The same false green comes from a record still live in the old zone, or a selector copied beneath the wrong origin, both of which look correct in configuration and are absent from the public answer [14]. The post's framing is to treat the zone file as deployed state [19].
The Python triage tool is scoped the way I would scope it. It reads a raw message from stdin and prints the From. Two regexes pull the spf, dkim and dmarc results plus the smtp.mailfrom, header.d and header.from identities out of each Authentication-Results field [17]. It deliberately does not implement DMARC or parse every Authentication-Results extension, because the receiving system already performed that evaluation, and it neither sends mail nor calls a vendor API [15].
One condition governs whether any of this transfers to your setup. You need a delivered message in a mailbox you control on each receiving system you care about, with full headers preserved, because the result is produced at the receiver, not by the sending dashboard [10]. For the media company moving zones off a registrar-specific API, the post's sequence is to freeze the intended records, query what is actually published, then test a message from every real sending path before changing enforcement [11].
What to watch
- A move to strict alignment at any large sender: subdomain paths that pass under relaxed mode fail the moment aspf=s or adkim=s is published.
- Whether the triage tool grows past header parsing into policy evaluation, which its author says the receiving system already did.
- Receivers that stop emitting a copyable Authentication-Results field, since the whole procedure starts from that header.