DMARC alignment: why SPF pass or DKIM pass is not the whole test

Authentication pass and DMARC pass answer different questions

SPF and DKIM each authenticate a technical identity. DMARC adds a relationship test between an authenticated identity and the domain visible in the RFC5322.From header. That is why a message can show `spf=pass` and `dkim=pass` but still fail DMARC: both successful identities may belong to a vendor domain that does not align with the brand domain in From. When debugging, write down the actual domains next to each result. The word “pass” without the domain is incomplete evidence.

Trace the SPF identity used by the message

SPF evaluation is tied to SMTP identities, commonly the envelope sender / Return-Path or HELO context. Third-party services frequently use their own bounce domain unless custom return-path configuration is enabled. If SPF passes for `bounce.vendor.example` while the visible From is `example.com`, DMARC's SPF alignment may not be satisfied. This does not make the vendor's SPF record wrong; it means that raw SPF authorization and DMARC alignment are separate layers. Capture the Return-Path and Authentication-Results together so you can see both.

Trace the DKIM signing domain independently

For DKIM, the important identity is the `d=` value in the DKIM-Signature. A platform may sign with `d=vendor.example`, or it may offer custom DKIM so the signature uses your domain or an aligned subdomain. Again, cryptographic success only proves that the signature validates for the signing domain. DMARC then evaluates whether that domain aligns with the visible From domain. Inspecting `d=` and `s=` from a real message is more reliable than assuming the platform uses the domain shown in its account settings.

Understand relaxed versus strict alignment before changing subdomains

DMARC alignment can operate in relaxed or strict modes for SPF and DKIM. Under relaxed alignment, organizational-domain relationships can allow subdomains to align where strict mode would require a closer match. The exact evaluation should follow the current DMARC specification and public-suffix handling rather than a home-grown “ends with” string test. For small operators, the safe approach is to let receivers and standards-compliant tooling report alignment, then use those results to verify the intended domain architecture.

A worked vendor example

Suppose a message has `From: Maya <maya@example.com>`, `Return-Path: bounces@vendor-mail.example`, and a valid DKIM signature with `d=vendor-mail.example`. Both SPF and DKIM can pass for the vendor while neither authenticated domain aligns with `example.com`. DMARC can therefore fail. The remedy is not to add random vendor IPs to the brand's SPF record. Configure a supported custom bounce domain and/or custom DKIM signing domain so at least one authenticated path aligns, then retest with a fresh message.

Why one aligned method is enough for DMARC pass

DMARC does not require both SPF alignment and DKIM alignment to succeed on every message. A message can pass DMARC when at least one supported authentication mechanism both passes and aligns, subject to the current specification. Operationally, many senders still configure both SPF and DKIM because receivers expect strong authentication and because the methods fail for different reasons, especially when forwarding changes the path. Treat redundancy as resilience, not as permission to ignore the alignment details of the active route.

Build a header-first diagnostic habit

For every authentication incident, save the raw From, Return-Path, Authentication-Results, and DKIM-Signature. Mark the domains that passed and whether they align. If the result changed after a vendor or DNS migration, compare those exact fields against a known-good message from before the change. This header-first habit narrows the problem to the identity layer and avoids wasting time rewriting copy, changing send windows, or lowering volume when the receiver is explicitly reporting an authentication mismatch.

Map the three domains on one real message

An efficient alignment check uses one delivered message and writes down three domains: the visible RFC5322.From domain, the RFC5321.MailFrom domain used by SPF, and the d= domain from each passing DKIM signature. Under relaxed DMARC alignment, the authenticated SPF or DKIM domain can be a parent or child that shares the same Organizational Domain with the visible From domain. Under strict alignment, the domain names must match exactly. This is why “SPF passed” can coexist with “DMARC failed”: SPF may have authenticated a vendor bounce domain that is unrelated to the From domain. The same can happen with DKIM when a platform signs only with its own domain. Seeing the three identities together usually resolves the confusion faster than editing DNS based on the word pass alone.

Choose which method will carry alignment before a migration

When moving providers, decide explicitly whether DMARC will be satisfied primarily by aligned DKIM, aligned SPF, or both. DKIM is often the cleaner anchor because the provider can sign with a d= domain you control even when the envelope bounce domain remains provider-owned. If the design relies on SPF alignment instead, verify the actual MailFrom domain after cutover rather than assuming it follows the visible From address. A migration test should therefore capture Authentication-Results from the old path and the new path and compare each identity. This makes the cutover reversible: if the new signer is not aligned yet, keep the old path available while DNS and signing are corrected instead of discovering the dependency only after a DMARC enforcement failure.

Do not confuse Return-Path with the visible From address

The Return-Path typically reflects the SMTP envelope sender after delivery, while the From header is the author identity shown to the recipient. SPF authenticates the envelope domain; DMARC then asks whether that authenticated identity aligns with the From domain. A third-party sender can therefore show From: alex@example.com and Return-Path: bounce@vendor.example while passing SPF for vendor.example. If DKIM signs with d=example.com and passes, DMARC can still pass through aligned DKIM. This is why changing SPF alone may not fix an alignment failure, and why a provider-owned Return-Path is not automatically wrong. Read all three identities together before deciding which DNS record needs work.

Field checklist

• Record the domain attached to every SPF and DKIM result; never keep only the word PASS.
• Compare Return-Path / SPF identity with the visible From domain.
• Compare DKIM `d=` with the visible From domain.
• Use standards-compliant DMARC alignment logic rather than naive string matching.
• Configure supported custom return-path or DKIM domains when a vendor identity is misaligned.
• Retest from a real message and preserve headers as the known-good baseline.