DMARC alignment: what relaxed vs strict (aspf, adkim) actually changes

Alignment is a separate question from “did SPF or DKIM pass”

SPF and DKIM each answer their own narrow question — is this connecting server authorized, is this signature valid — without checking anything about the domain a recipient actually sees in their inbox. RFC 7489 §3.1 adds the piece neither one covers on its own: alignment, which checks whether the domain that SPF or DKIM actually authenticated matches the domain shown in the message’s visible From: header. Without alignment, an attacker could pass SPF cleanly for their own, completely unrelated domain while still showing your domain in From: — a technically “authenticated” message that’s still a spoof of your brand. The aspf and adkim tags in a DMARC record each independently control how strict that match has to be.

Relaxed alignment: matching at the organizational domain

Relaxed alignment, the default for both tags, matches at what RFC 7489 §3.1 calls the Organizational Domain — broadly, the registrable domain (example.com, not a specific subdomain of it). Under relaxed alignment, mail.example.com and example.com are the same organizational domain, so a message authenticated against either one aligns with a From: address at the other. This is deliberately forgiving of a very common real-world pattern: an organization sending transactional mail from notifications.example.com, marketing mail from mail.example.com, and everything authenticating under the same base domain — relaxed alignment treats all of that as one organization’s traffic, which it is.

Strict alignment: an exact match, no subdomain exception

Strict alignment removes that subdomain tolerance entirely. Under aspf=s or adkim=s, the authenticated domain must be exactly the same string as the domain in From: — not a parent, not a subdomain, not a sibling under the same organizational domain. A DKIM signature with d=example.com does not strictly align with a message showing From: [email protected], even though both domains are unambiguously controlled by the same organization and relaxed alignment would pass that same pair without hesitation.

A worked example

A company signs all outgoing mail with one DKIM key, published once at example.com (d=example.com), and uses that same signature across several sending subdomains:

From: address	d= domain	Relaxed adkim	Strict adkim
[email protected]	example.com	Pass (exact match)	Pass (exact match)
[email protected]	example.com	Pass (shared organizational domain)	Fail (not an exact match)
[email protected]	example.com	Pass (shared organizational domain)	Fail (not an exact match)

Flipping adkim from relaxed to strict in this setup doesn’t tighten protection against the spoofing DMARC is meant to stop — the organizational domain was already shared in every row. It breaks DKIM alignment for every subdomain that doesn’t exactly match the signing domain, which is exactly the kind of silent, self-inflicted mail failure that makes an unaudited move to strict alignment risky.

SPF and DKIM alignment are independent, and only one needs to pass

Two details are easy to miss when reading a DMARC record’s tags in isolation. First, aspf and adkim are set independently — tightening one doesn’t tighten the other, which matters because SPF and DKIM typically authenticate different domains for the same message (SPF checks the Return-Path/HELO domain RFC 7208 defines, DKIM checks whatever domain the signature’s d= tag names, defined in RFC 6376). Second, DMARC itself only requires one of the two to pass and align, not both — RFC 7489 §3.1 treats a message as DMARC-authenticated if SPF or DKIM independently passes with alignment. That’s why a forwarded message, which typically breaks SPF by changing the connecting server, can still pass DMARC cleanly on an aligned DKIM signature that survives the forward intact.

Checking your own alignment setting

Run AdminKit’s DMARC check against your domain to see your record’s current aspf and adkim values read in plain language — see how to read a DMARC check result for every other tag in the same record, and SPF, DKIM and DMARC explained for how the three records work together from scratch. If you’re already enforcing a policy and want to confirm alignment is actually passing for every legitimate sending source before considering strict, reading DMARC aggregate reports and rolling out to p=reject safely covers how to read that evidence from real mail traffic rather than guessing.

Two other configuration details worth checking while you’re reviewing DNS and TLS fundamentals: whether your zone’s apex is set up correctly in ALIAS, ANAME and CNAME flattening at the apex explained, and what a wildcard certificate does and doesn’t cover in wildcard vs SAN certificates explained.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.