DMARC Alignment Explained: SPF, DKIM, Relaxed vs Strict

A message can pass SPF, pass DKIM, and still fail DMARC. This surprises almost everyone the first time they see it in a report. The missing piece is alignment: DMARC does not just ask whether SPF or DKIM passed, it asks whether the domain that passed is the same domain the recipient sees in the From header. If those domains do not line up, the pass does not count. This guide explains identifier alignment, the difference between relaxed and strict modes set by the aspf and adkim tags, and how to fix the misalignment that silently fails legitimate mail.

Why a pass is not enough

DMARC exists to protect one specific thing: the domain a human reads in the From field, known in the specs as the RFC5322.From domain. SPF and DKIM each authenticate a domain, but neither of them authenticates the From header on its own. SPF checks the envelope sender (the RFC5321.MailFrom, also called the Return-Path), and DKIM checks whatever domain the signer put in the d= tag. Either of those can be a completely different domain from the one in the From header. Alignment is the rule that ties the authenticated domain back to the visible From domain, and without it an attacker could pass SPF on a domain they control while spoofing yours in the From line.

The two alignment checks

DMARC passes if at least one of SPF or DKIM both passes and aligns. They are evaluated independently, and you only need one to succeed.

So a message is DMARC-compliant when SPF passes and its MailFrom domain aligns with From, OR when a DKIM signature validates and its d= domain aligns with From. Fail both and DMARC fails, regardless of how many underlying checks succeeded.

Relaxed versus strict

Alignment comes in two modes, and you choose them per mechanism with the aspf tag for SPF and the adkim tag for DKIM. The default for both is relaxed.

• Relaxed (r): the two domains align if they share the same organizational domain, that is the registrable domain just below the public suffix. A subdomain matches the parent. This is the default when the tag is absent.
• Strict (s): the two domains must match exactly, label for label. A subdomain does not match the parent.

Under relaxed alignment, mail.example.com and example.com are considered aligned because both roll up to the organizational domain example.com. Under strict, they are not, because the strings differ. The example below sets strict alignment on both mechanisms.

$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com"

Leave out adkim and aspf entirely and you get relaxed on both, which is what most domains should use.

A worked example

Say your From header is newsletter@example.com. Your marketing platform sends the mail, and its envelope sender is bounces@m.sendingplatform.net, while it signs with DKIM using d=example.com through a delegated selector.

SPF passes but does not align, because the envelope domain belongs to the platform, not you. DKIM passes and aligns, because the signing domain is yours. DMARC passes on the strength of DKIM alone. This is the single most common real-world pattern: aligned DKIM carries DMARC while SPF rides on the platform's own domain and contributes nothing to alignment.

How to read alignment in a DMARC report

Aggregate reports show, per source, the SPF and DKIM results alongside the domains involved, so you can see exactly why DMARC did or did not pass. The relevant fragment of the XML looks like this.

<row>
  <source_ip>203.0.113.10</source_ip>
  <policy_evaluated>
    <dkim>pass</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.com</header_from>
</identifiers>
<auth_results>
  <spf><domain>m.sendingplatform.net</domain><result>pass</result></spf>
  <dkim><domain>example.com</domain><result>pass</result></dkim>
</auth_results>

Here the policy_evaluated block reports the aligned results: DKIM aligned and passed, SPF did not align so it reads as fail for DMARC purposes. The auth_results block shows the raw per-mechanism results and their domains, which is where you confirm why alignment did or did not hold.

Common causes of misalignment

• SPF authenticates the platform, not you. If a sender only passes SPF on its own bounce domain and does not sign with an aligned DKIM key, DMARC fails. Fix it by enabling DKIM signing with a key published under your domain.
• Third-party DKIM signs with its own domain. A signature with d=mailer.vendor.com never aligns with example.com. Use the vendor's custom or branded DKIM setup so d= is your domain.
• Strict mode on a subdomain sender. If you send from info@example.com but sign as d=mail.example.com, strict alignment fails while relaxed would pass. Either align the domains exactly or use relaxed.
• Forwarding. Forwarding often breaks SPF alignment outright and can break DKIM if the body is altered, which is a separate problem solved by SRS and ARC.

Which mode should you use

Relaxed is the right default for almost everyone. It tolerates the normal practice of sending from subdomains while still stopping cross-organization spoofing, because an attacker on a wholly different registrable domain will never align under relaxed either. Reach for strict only when you deliberately want to pin authentication to an exact hostname, for example a high-value transactional domain where you control every sender and want no subdomain to inherit the pass. For most organizations, strict alignment creates failures faster than it adds protection.

Verify alignment before you enforce

Alignment problems hide until you move DMARC to quarantine or reject, at which point misaligned legitimate mail starts getting filtered. Confirm your published DMARC and DKIM records are live everywhere by running your domain through the Valla DNS propagation checker, so a stale resolver copy is not masking the real record. Then pair this with our guides on SPF qualifiers and the DMARC policy ramp to tighten enforcement only after every legitimate source authenticates with alignment.