DMARC Alignment Explained: SPF and DKIM Identifier Alignment
VigilDog Team · October 22, 2026 · 6 min read
You set up SPF. You set up DKIM. Both pass in the headers. And DMARC still reports failures. This is the single most confusing thing about email authentication, and the answer is almost always the same word: alignment. DMARC doesn't just ask whether SPF or DKIM passed, it asks whether the domain they passed for matches the domain your recipients actually see.
What DMARC alignment actually checks
SPF and DKIM each authenticate a domain. The problem is that neither of them, by default, cares about the domain in the visible From: header, the one your recipient reads. SPF authenticates the envelope sender (the Return-Path, technically RFC5321.MailFrom). DKIM authenticates whatever domain is named in the signature's d= tag. Either of those can pass while being a completely different domain from the one in From:.
DMARC alignment is the check that closes that gap. It compares the From: header domain against the domain that SPF or DKIM authenticated, and it only counts a pass if they line up. This is what stops an attacker from sending mail that passes SPF for their own throwaway domain while forging your brand in the From: line.
DMARC needs only one aligned pass to succeed. If DKIM aligns and passes, you're done, SPF can fail. If SPF aligns and passes, you're done, DKIM can fail. This OR relationship is why DKIM alignment is worth prioritizing: it survives forwarding, where SPF usually breaks.
SPF alignment: envelope vs header
SPF validates the domain in the envelope Return-Path, not the From: header. Open any message and you'll often find the Return-Path points somewhere you didn't expect, especially if you send through an email service provider. A newsletter that says From: news@yourbrand.com might carry a Return-Path of bounces@mail123.sendgrid.net. SPF can pass perfectly for that SendGrid domain and still be unaligned with yourbrand.com, so it contributes nothing to DMARC.
The fix is a custom Return-Path (often called a custom bounce domain or custom MAIL FROM) on a subdomain of your own domain, something like bounce.yourbrand.com, configured at your ESP. Once the envelope domain shares your organizational domain, SPF aligns.
DKIM alignment: the d= tag is what matters
DKIM alignment compares the From: domain against the d= value inside the DKIM-Signature header. Many providers sign outgoing mail with their own domain by default (d=sendgrid.net, d=amazonses.com), which authenticates the message but does not align with your From: domain.
The remedy is provider-branded or custom DKIM: you publish CNAME records that delegate a DKIM selector to your ESP, and the ESP then signs with d=yourbrand.com. After that, DKIM both passes and aligns, and because DKIM survives most forwarding, this is the most durable path to a green DMARC result. If you're still untangling which record is which, our guide to fixing SPF, DKIM and DMARC walks through each one.
Relaxed vs strict alignment
DMARC supports two alignment modes, set by the aspf (for SPF) and adkim (for DKIM) tags in your DMARC record. Relaxed is the default and applies when you omit them. Strict has to be requested explicitly.
Relaxed alignment matches on the organizational domain, so mail.yourbrand.com aligns with yourbrand.com. Strict alignment requires an exact match, the authenticated domain must be yourbrand.com to the letter, and a subdomain won't count. Almost everyone should stay on relaxed. Strict only makes sense when you have a specific reason to lock alignment to an exact hostname and you fully control every sending source.
- aspf=r / adkim=r, relaxed (default): organizational-domain match, subdomains align
- aspf=s / adkim=s, strict: exact hostname match required
- Omitting the tags means relaxed, you don't need to set them for normal use
Why alignment breaks in the real world
The usual culprits are predictable once you know to look for them. A third-party sender (CRM, help desk, invoicing tool, marketing platform) sends on your behalf with its own Return-Path and its own DKIM d=, so neither identifier aligns. Automatic forwarding rewrites the envelope and breaks SPF, leaving DKIM as your only aligned pass. And a strict-mode record combined with subdomain sending fails alignment even though everything looks correct at a glance.
The way to see this clearly is DMARC aggregate (rua) reports. They tell you, per sending source, whether SPF and DKIM passed and, critically, whether each was aligned. A source showing spf=pass but with a disposition of fail is the textbook signature of an alignment problem, not an authentication problem.
Verify alignment, then keep watching it
Start by running one of your own messages through our DMARC checker to read the policy and see what alignment your record requests. Then send test mail through every real sending source and inspect the Authentication-Results header: you want to see dmarc=pass, and you want to confirm which identifier carried it. Fix the unaligned sources one at a time, custom Return-Path for SPF, delegated DKIM for the d= domain, before you ever consider tightening your policy to quarantine or reject.
Alignment isn't a one-time setup. A new tool added by your marketing team, an ESP that changes signing defaults, or a DNS record that gets edited can silently unalign a source and start bouncing legitimate mail into spam. This is exactly the kind of drift VigilDog's email deliverability monitoring is built to catch, it watches your SPF, DKIM and DMARC posture continuously and alerts you when an aligned source stops aligning, long before a client notices their campaign went missing.
