SPF passed. DKIM passed. And the message still failed DMARC and landed in quarantine. If you've seen that combination in an aggregate report, the missing piece is almost always alignment, the extra condition DMARC layers on top of SPF and DKIM that neither protocol enforces on its own.
What alignment compares
DMARC doesn't just check whether SPF or DKIM passed, it checks whether the domain that passed matches the domain in the message's visible From: header, the one your recipient sees.
- SPF authenticates the
Return-Path(the 5321.MailFrom envelope sender), not the visible From address. A message can pass SPF forbounce.example.comwhile claiming to be from[email protected], and whether that pass counts toward DMARC depends entirely on alignment, covered below. - DKIM authenticates the domain in the signature's
d=tag, again not necessarily the visible From address.
Alignment is the rule for how closely those domains have to match. DMARC gives you two modes, set independently for SPF and DKIM.
Relaxed mode (the default)
_dmarc.example.com TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:[email protected]"
Relaxed mode (r) considers two domains aligned if they share the same organizational domain, the registrable root, regardless of subdomain. mail.example.com aligns with example.com. billing.example.com aligns with example.com. This is the default for both adkim and aspf if you don't set the tags at all, and it's what most legitimate mail needs: it's common for a bounce-handling or transactional subdomain to differ from your primary sending domain without anything being wrong.
Strict mode
_dmarc.example.com TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:[email protected]"
Strict mode (s) requires an exact match. If your visible From address is [email protected], the SPF-authenticated domain or DKIM d= domain has to be exactly example.com, not bounce.example.com, not mail.example.com. Any subdomain difference fails alignment, even though SPF or DKIM passed on their own and the mail is perfectly legitimate.
Where this breaks mail
Most transactional and marketing platforms let you delegate a subdomain for SPF, a custom Return-Path like bounce.example.com pointed at their infrastructure, without automatically signing DKIM as your domain too. DKIM only signs as d=example.com if you've also added the platform's DKIM CNAME records; skip that step and it signs as the platform's own domain instead, something like d=esp.example.net, which never aligns with [email protected] under any mode. Under relaxed SPF alignment none of that matters: bounce.example.com still aligns with example.com, so DMARC passes on the SPF leg alone. Switch aspf to strict and that pass disappears, since bounce.example.com no longer counts as the same domain as example.com, and DKIM was never aligned to begin with. Mail that was authenticating cleanly starts failing, with nothing in your sending setup having changed.
That's the trade-off in one sentence: relaxed mode tolerates the subdomain structure real sending platforms use, strict mode assumes you control the exact domain on every authentication path.
When strict mode is worth it
Almost nobody needs strict on both tags. It's worth considering when:
- You've mapped every legitimate sending source and confirmed each one signs DKIM with your exact domain, not a subdomain.
- You're in a high-target environment (finance, healthcare, anything phishing actors specifically spoof) where a lookalike sender using a similar subdomain is a real threat, not a theoretical one.
- You're tightening
adkim=sspecifically, the safer of the two, since DKIM signing is under your control in a way the SPF envelope domain often isn't.
aspf=s is the one that catches people out most, because the SPF envelope domain is frequently controlled by whatever platform is sending on your behalf, not by you. Tighten it before confirming every source's actual Return-Path domain, and you'll fail mail that was authenticating correctly under the looser setting.
Checking your own alignment
Every DMARC aggregate report already tells you the SPF and DKIM domains for each sending source, you just have to look at which domain is reported, not just the pass or fail result. MyDMARC's report view labels each record as Aligned, Unaligned, or Mixed based on the actual alignment result rather than the raw SPF or DKIM verdict, so a record showing DKIM passing but still reading "Not aligned" is telling you exactly this: the signature was valid, it just didn't match the visible From domain closely enough to align. If you're not sure what your current record's adkim and aspf tags evaluate to, MyDMARC's DMARC checker parses them out of your live record and flags anything invalid.
If you're setting this up today: leave both tags at relaxed, since that's the default and what most legitimate sending survives. Move to adkim=s once your reports show every source signing DKIM as your own domain. Leave aspf=s alone unless you've confirmed every SPF-authenticated domain in your reports is already yours, not a platform's.
Like any tag in your DMARC record, this only protects you as long as the record stays the way you set it. OneDollarDNS will alert you if adkim, aspf, or the record itself ever changes without you making the change.