DMARC alignment explained: why SPF/DKIM can pass and DMARC still fail

If you have ever stared at a DMARC report where SPF says pass and DMARC still says fail, you have met alignment. It is the part of DMARC most setup wizards skip, and the reason “we already have SPF” does not clear Gmail 550 5.7.26.

For the broader comparison of what each protocol checks, see SPF vs DKIM vs DMARC.

Two different “from” addresses

Every email has at least two identities:

1. Envelope-from (RFC5321 / Return-Path). Used for bounces. This is what SPF evaluates.
2. Header From (RFC5322). The address people see in their client. This is what DMARC aligns against.

Those can be different on purpose. A marketing platform often sends with an envelope on its own domain while putting [email protected] in the From header. SPF can pass for the platform domain and still fail DMARC for your brand.

DKIM has a similar split: a valid signature whose d= domain is the platform’s domain is a DKIM pass that still fails DMARC alignment for your From domain.

What “aligned” means

DMARC asks: did SPF or DKIM produce a pass whose authenticated domain aligns with the From header?

1. Relaxed alignment (default, aspf=r / adkim=r). The authenticated domain and the From domain must share the same organizational domain (for example mail.yourbrand.com and yourbrand.com). Exact equality is not required.
2. Strict alignment (aspf=s / adkim=s). The domains must be identical. A subdomain does not count.

Only an aligned pass satisfies DMARC. Unaligned passes are useful for debugging and useless for the policy decision.

Identifier alignment in practice

Check	Authenticated identity	Aligns to From when…
SPF	Envelope-from domain	Envelope domain matches From domain (relaxed: same org domain)
DKIM	Signature d= domain	d= matches From domain (relaxed: same org domain)

DMARC needs at least one aligned pass. Two unaligned passes still fail DMARC.

How this shows up in real reports

What you see	Likely meaning	First fix to try
SPF pass, DKIM fail, DMARC fail	Envelope domain authorized, but not aligned to From; no usable DKIM for your domain	Enable DKIM signing for your domain at the ESP; confirm SPF domain vs From
SPF fail, DKIM pass, DMARC pass	Common after forwarding: SPF broke, aligned DKIM saved DMARC	Keep DKIM healthy; do not “fix SPF” for forwarders
SPF pass, DKIM pass, DMARC fail	Both checks authenticated the wrong domain relative to From	Custom DKIM d=yourdomain and/or aligned bounce domain
Both fail, DMARC fail	Unauthorized sender, or a new tool never added to SPF/DKIM	Identify source; authorize or enforce

Aggregate reports encode alignment in result fields (exact XML shapes vary by reporter). Tools that only show “SPF pass” without alignment will mislead you. Prefer views that separate pass from aligned pass. How to read DMARC reports covers which fields to prioritize.

Why ESPs create this confusion

Third-party senders optimize for deliverability of their platform. Out of the box they often:

1. Send with an envelope on a domain they control (SPF easy for them).
2. Sign DKIM with their domain (signature verifies, d= is not you).
3. Put your address in the visible From header (branding).

From the ESP dashboard, “SPF and DKIM are configured” can be true for their domains. From DMARC’s point of view for your brand, nothing aligned yet.

The fix is almost always in the ESP’s “custom domain / authenticates as you” settings: DNS CNAMEs or TXT records that publish your DKIM selectors, and sometimes a custom return-path that brings SPF under your organizational domain.

How to fix alignment failures

1. List every system that sends as your From domain. Primary mail, ESP, CRM, helpdesk, billing, forms, calendaring, scanners.
2. For each ESP, enable DKIM signing for your domain (custom d=), not the ESP’s shared domain alone. Add the ESP’s include to your SPF if they send with your envelope domain.
3. Watch DNS carefully. DKIM hostnames should resolve; avoid proxying DKIM CNAMEs unless documented safe.
4. Recheck with the free DMARC checker (and SPF / DKIM checkers if a piece looks missing).
5. Read aggregate reports for a few days at p=none before moving to quarantine or reject. Alignment mistakes under enforcement become customer-facing bounces.

What not to do

• Do not add random SPF includes for domains that are not your senders.
• Do not jump to p=reject to “force” alignment. Enforcement without aligned legitimate mail breaks delivery.
• Do not disable SPF or DKIM on a working primary mail system to make an ESP look better. Fix the ESP.

Alignment and enforcement

Under p=none, alignment failures are mostly invisible to recipients. Reports still show them. Under p=quarantine or p=reject, receivers are asked to treat unaligned failures as suspicious or refuse them.

That is why alignment work belongs before policy tightening. Email Watch classifies sources in your rua stream in the report UI so an unaligned ESP is not mistaken for an attacker (and the reverse). Receivers still apply whatever DMARC policy you publish. Email Watch does not block, quarantine, or override mailbox providers.

Quick checklist

• Every From domain you care about has a DMARC record
• Every sending tool has DKIM with d= on that domain (or a parent that relaxed alignment accepts)
• SPF covers tools that use your envelope domain, without exceeding 10 lookups
• Reports show aligned passes for your real volume before you leave p=none
• Parked or non-sending domains have an intentional policy (often reject) so they are not soft targets

When report volume outgrows spreadsheets, start a trial and point rua= at Email Watch (complete external destination authorization if the rua domain is not yours).