Try the DMARC Lookup

DMARC Alignment: Why SPF and DKIM Can "Pass" While DMARC Still Fails

"SPF passes" and "DKIM passes" don't mean DMARC passes β€” DMARC additionally requires alignment between the visible From domain and the domain that actually passed SPF or DKIM. Here's the distinction between envelope sender and visible From, relaxed vs strict alignment, and why DMARC passes if EITHER SPF or DKIM is aligned β€” the key to debugging most DMARC failures with third-party senders.

By sadiqbd Β· June 16, 2026

Share:
DMARC Alignment: Why SPF and DKIM Can "Pass" While DMARC Still Fails

DMARC doesn't actually check whether SPF and DKIM "pass" in the way most people assume β€” it checks whether they pass and are aligned with the visible From address, and that distinction explains most DMARC confusion

A domain can have perfectly valid SPF and DKIM configurations, with both "passing" in a technical sense β€” and still fail DMARC, because DMARC adds an additional requirement on top of SPF/DKIM passing: alignment. Understanding alignment is the key to understanding why DMARC sometimes behaves in ways that seem to contradict what SPF and DKIM checkers show in isolation.


The two domains involved in every email

To understand alignment, it's necessary to distinguish between two different "domains" associated with an email message:

The visible "From" domain (RFC5322.From): this is the domain in the From header that email clients display to the recipient β€” e.g., if an email shows as from newsletter@example.com, the visible From domain is example.com. This is what DMARC policy is published for, and what alignment is checked against.

The envelope sender domain (RFC5321.MailFrom, sometimes called the "Return-Path"): this is a separate piece of information used during the SMTP transaction itself, which may or may not be the same as the visible From domain β€” it's used for bounce handling and is what SPF actually checks.

For DKIM, the relevant domain is the d= value in the DKIM-Signature header β€” the domain that did the signing, which again may or may not match the visible From domain.


SPF alignment

SPF, in isolation, checks: "is the sending IP authorised by the SPF record of the envelope sender domain?" This can pass even if the envelope sender domain is completely different from the visible From domain.

DMARC's SPF alignment check adds: "...and does that envelope sender domain match (or, in relaxed mode, share an organisational domain with) the visible From domain?"

Example of SPF passing but DMARC SPF alignment failing:

  • Visible From: notifications@example.com
  • Envelope sender: bounce.thirdpartyservice.com
  • If bounce.thirdpartyservice.com's SPF record authorises the sending IP, SPF passes
  • But bounce.thirdpartyservice.com and example.com are different domains (not aligned)
  • DMARC's SPF alignment check fails β€” even though "SPF passed"

This is an extremely common scenario with third-party email services (marketing platforms, transactional email services) that send "on behalf of" a domain β€” the envelope sender is often the third-party service's own domain, not the customer's domain, unless specifically configured otherwise (often via "custom return path" or similar configuration options that third-party services provide specifically to enable SPF alignment).


DKIM alignment

DKIM, in isolation, checks: "does the cryptographic signature verify against the public key published by the d= domain in the signature?" This can pass for any d= domain that has a valid signature, regardless of the visible From domain.

DMARC's DKIM alignment check adds: "...and does that d= domain match (or share an organisational domain with, in relaxed mode) the visible From domain?"

Example of DKIM passing but DMARC DKIM alignment failing:

  • Visible From: notifications@example.com
  • DKIM signature d= value: thirdpartyservice.com
  • If the signature verifies against thirdpartyservice.com's published key, DKIM passes
  • But thirdpartyservice.com and example.com are different domains (not aligned)
  • DMARC's DKIM alignment check fails β€” even though "DKIM passed"

This occurs when a third-party service signs emails with their own domain's DKIM key (their default configuration) rather than being configured to sign with a key for the customer's domain (often called "custom DKIM" or "branded DKIM" by third-party services, requiring the customer to publish a DKIM record under their own domain that delegates to the service, as covered in the DKIM key rotation article).


Relaxed vs strict alignment

DMARC allows specifying alignment mode separately for SPF (aspf tag) and DKIM (adkim tag), each of which can be r (relaxed, the default) or s (strict):

Relaxed alignment (r): the domains are considered aligned if they share the same "organisational domain" β€” e.g., mail.example.com and example.com would be considered aligned under relaxed mode, because they share the organisational domain example.com (this involves checking against public suffix lists to correctly determine organisational domain boundaries, since e.g. example.co.uk has a different effective structure than example.com).

Strict alignment (s): the domains must match exactly β€” mail.example.com and example.com would NOT be considered aligned under strict mode, despite being related.

Most DMARC records use relaxed alignment (the default) β€” strict alignment is less commonly deployed, as it requires exact domain matches that many legitimate sending configurations (especially involving subdomains for different purposes) wouldn't satisfy.


DMARC passes if EITHER SPF or DKIM is aligned (and passing)

A critical point: DMARC passes if at least one of SPF-with-alignment OR DKIM-with-alignment succeeds β€” it's not a requirement that both must pass with alignment.

This is part of why DKIM's relative robustness to forwarding (covered in the previous article) matters for DMARC outcomes: if forwarding breaks SPF alignment (a common forwarding effect, as discussed) but the DKIM signature remains valid and aligned (because forwarding, if it doesn't modify content, doesn't break DKIM), DMARC can still pass based on DKIM alone.

Conversely, a message could have a broken/failing DKIM signature for some reason, but if SPF passes with alignment, DMARC can still pass based on SPF alone.


Reading "Why did DMARC fail?" from this lens

When investigating a DMARC report (or a specific message) showing a DMARC failure, the alignment framework gives a structured set of questions:

  1. Did SPF pass (in isolation)? If yes β€” was the envelope sender domain aligned with the visible From domain?
  2. Did DKIM pass (in isolation)? If yes β€” was the d= signing domain aligned with the visible From domain?
  3. If both alignment checks failed (or both underlying SPF/DKIM checks failed), DMARC fails β€” and the policy (p=none/quarantine/reject) determines what happens to the message.

A common pattern in DMARC reports for organisations using multiple third-party sending services: SPF passes but isn't aligned (because the third-party's own envelope domain is used) AND DKIM passes but isn't aligned (because the third-party's own DKIM domain is used, not a custom/branded DKIM setup) β€” resulting in DMARC failure for mail that is, in a real sense, "legitimate" (sent with the domain owner's authorisation via a service they've engaged), but not configured in a way that satisfies DMARC's alignment requirements.

The fix in this common pattern is typically: configure the third-party service's "custom return path" / "branded link" feature (addressing SPF alignment) AND configure "custom DKIM" / "domain signing" with the third-party service, publishing the appropriate CNAME or TXT records under your domain (addressing DKIM alignment) β€” these are the configuration steps that move a legitimate-but-unaligned setup into DMARC-aligned territory.


How to use the DMARC Lookup tool on sadiqbd.com

  1. Check your DMARC record's alignment mode settings (aspf and adkim tags, if present β€” both default to relaxed r if not specified)
  2. Use alongside SPF and DKIM checkers β€” understanding that "SPF passes" and "DKIM passes" in isolation don't guarantee DMARC alignment for any specific sending source
  3. Cross-reference with DMARC aggregate reports (covered in a previous article) β€” reports show alignment results specifically, which is the information needed to identify unaligned-but-otherwise-valid sending sources that need custom SPF/DKIM configuration with third-party services

Frequently Asked Questions

Why would anyone use strict alignment if relaxed is more forgiving? Strict alignment can be a deliberate choice for domains with very specific security requirements, where even subdomain-level sending should be tightly controlled and explicitly accounted for, rather than automatically considered "aligned" via the organisational domain relationship. This is a less common configuration and generally only relevant for specific organisational security policies rather than typical deployments.

If DMARC passes via DKIM alignment alone (with SPF unaligned), is that "less secure" than passing both? DMARC's design explicitly allows passing via either mechanism specifically because requiring both would be overly restrictive given how common legitimate "send on behalf of" scenarios with unaligned SPF are. Passing via DKIM alignment alone is a fully valid DMARC pass, not a "partial" or "lesser" pass β€” DMARC's specification defines this as sufficient by design.

Is the DMARC Lookup tool free? Yes β€” completely free, no sign-up required.

Try the DMARC Lookup tool free at sadiqbd.com β€” check your domain's DMARC policy and alignment configuration.

Share:
Try the related tool:
Open DMARC Lookup

More DMARC Lookup articles