grimDMARC
|
Log in

Alignment vs Authentication: Why SPF and DKIM Passing Isn't Enough

Here's a scenario that confuses a lot of people troubleshooting DMARC for the first time: SPF passes. DKIM passes. And DMARC still fails. This isn't a bug or an edge case — it's DMARC working exactly as designed, and understanding why requires separating two ideas that get treated as one: authentication and alignment.

What you will learn:

  • The difference between "did SPF/DKIM pass" and "did they align"
  • What organizational domain means and why it's the anchor for alignment
  • Relaxed vs strict alignment, and what changes between them
  • A worked example of authentication passing while alignment fails

Authentication answers a narrower question than you'd think

SPF authentication asks: was this message sent from a server authorized by some domain's SPF record? DKIM authentication asks: was this message signed with a valid private key belonging to some domain? Neither one, on its own, asks whether that domain is the one the recipient actually sees in their inbox.

That's the gap. An attacker can register example-billing.com, configure a perfectly valid SPF record and DKIM key for it, and send mail that authenticates cleanly — while forging the visible From header to display billing@example.com. SPF and DKIM both pass, evaluated against example-billing.com. But the domain the recipient sees is example.com, and nothing about SPF or DKIM authentication alone checks whether those two match.

That check is alignment, and it's specifically DMARC's job — not SPF's, and not DKIM's.

Side-by-side diagram contrasting authentication, which asks whether SPF or DKIM passed for some domain, against alignment, which separately asks whether that authenticating domain matches the visible From address the recipient sees


What alignment actually checks

DMARC alignment compares the domain that authenticated (from SPF or DKIM) against the visible From domain — the one shown to the recipient. There are two independent alignment checks, one per mechanism:

SPF alignment compares the domain used in the SPF check (technically the envelope sender / MAIL FROM domain) against the visible From domain.

DKIM alignment compares the d= domain in a valid DKIM signature (see Every DKIM Attribute Explained for exactly where this tag lives) against the visible From domain.

DMARC passes if at least one of these two alignments succeeds — you don't need both SPF and DKIM to align, just one. This is deliberate: it's what lets DMARC survive situations like forwarding, where SPF alignment routinely breaks but DKIM alignment often survives intact.


The organizational domain

Alignment isn't always an exact string match — that's where the concept of the organizational domain comes in. The organizational domain is the registrable root of a domain: example.com is the organizational domain for mail.example.com, newsletter.example.com, and example.com itself alike.

Under relaxed alignment (the default, and the far more common setting), a domain aligns with the From address if they share the same organizational domain — even if the exact subdomains differ. mail.example.com sending mail with a From address of noreply@example.com aligns under relaxed mode, because both resolve to the same organizational domain, example.com.

Determining exactly where an organizational domain boundary sits — example.com vs example.co.uk vs a registry-operated domain like .github.io — used to rely on the Public Suffix List. Under the 2026 DMARCbis update, this is now handled by a DNS-native mechanism called DNS Tree Walk, covered in more detail in What is DMARC?. For nearly every ordinary business domain, this distinction is invisible — it matters mainly for domains that sit near unusual public-suffix boundaries.


Relaxed vs strict alignment

DMARC's adkim= and aspf= tags control how strictly each alignment check is applied — see Every DMARC Tag Explained for the full tag reference.

Relaxed alignment (r, the default) — Any subdomain sharing the same organizational domain aligns. mail.example.com aligns with example.com. This is what nearly every production DMARC record uses, because real organizations routinely send legitimate mail from multiple subdomains of the same root domain, and strict mode would break that.

Strict alignment (s) — The signing/sending domain must match the visible From domain exactly, with no subdomain variation permitted. mail.example.com does not align with example.com under strict mode, even though they're clearly related.

_dmarc.example.com TXT "v=DMARC1; p=reject; adkim=r; aspf=r"

Strict alignment is a meaningfully tighter security posture, but it requires knowing with certainty that mail is only ever sent from the exact domain in the From address — never a subdomain of it. Get this wrong and you'll quarantine or reject legitimate mail the moment a marketing platform or notification service sends from a subdomain you didn't account for.


A worked example

Take a message with these results:

  • SPF: passes, evaluated against bounce.example-vendor.com (the envelope sender used by a third-party email platform sending on the domain's behalf)
  • DKIM: passes, signed with d=example-vendor.com
  • Visible From address: billing@example.com

Both SPF and DKIM authenticated successfully. But under relaxed alignment, neither bounce.example-vendor.com nor example-vendor.com shares an organizational domain with example.com — they're simply different companies' domains. Alignment fails for both. DMARC fails overall, and depending on policy, the message is quarantined or rejected — correctly, since this exact pattern is what a spoofed vendor-impersonation attack looks like.

Now compare that to a legitimate setup: the same vendor sends mail, but properly configured to send as example.com — using a subdomain like mail.example.com in its SPF envelope, and signing DKIM with d=example.com (or a subdomain of it) rather than its own domain. Now both authentications align, and DMARC passes. This is exactly what proper vendor onboarding for a sending platform looks like — see Reading DMARC Aggregate Reports for how you'd actually spot a misaligned-but-authenticated vendor in your own reports.

Flow diagram comparing two outcomes for the same third-party vendor: sending unconfigured mail that authenticates against its own domain and fails DMARC alignment, versus sending mail properly configured to authenticate as the customer's domain and pass DMARC


Why this design exists

It would be simpler for DMARC to just check "did SPF or DKIM pass," full stop. The reason it doesn't is that authentication alone answers the wrong question for spoofing prevention. A spoofer doesn't need to break your SPF or DKIM — they just need their own, entirely valid SPF and DKIM, paired with a forged From header that borrows your domain's reputation. Alignment is what closes that gap: it's not enough to authenticate as someone, you have to authenticate as the domain the recipient actually sees.

This is also why DMARC reports distinguish between raw SPF/DKIM results and DMARC's own pass/fail outcome — see Reading DMARC Aggregate Reports for exactly where that distinction shows up in the XML.


Frequently asked questions

Can SPF pass but DMARC still fail?

Yes — this is normal and expected whenever the domain that passed SPF doesn't share an organizational domain with the visible From address. It happens most often with third-party senders that haven't been configured to send as your domain specifically, rather than just sending mail that happens to mention your brand.

Is relaxed alignment less secure than strict?

Marginally, in theory — strict alignment closes a narrower attack surface involving subdomain spoofing within your own organizational domain. In practice, relaxed alignment is what almost every production domain runs, because most organizations legitimately send mail from multiple subdomains and strict mode creates false positives without a correspondingly large security benefit for most threat models.

Do I need both SPF and DKIM to align, or just one?

Just one. DMARC passes if either SPF alignment or DKIM alignment succeeds. This is intentional — it's what allows DMARC to keep working when SPF breaks under forwarding, as long as DKIM alignment still holds.

What's the organizational domain of a subdomain like mail.example.co.uk?

example.co.uk — the organizational domain is the registrable root, which accounts for multi-part public suffixes like .co.uk, not just the last two labels. This is exactly the calculation DNS Tree Walk (or, historically, the Public Suffix List) performs under the hood.


Checking your own alignment

Alignment failures are one of the more common causes of a "why is this legitimate sender failing DMARC" question during rollout. grimDMARC's free DMARC Analyzer shows your current alignment settings, and reviewing your aggregate reports (see Reading DMARC Aggregate Reports) is the fastest way to spot a sender that's authenticating successfully but failing to align.

If you're earlier in the process and still working through SPF or DKIM basics first, Every SPF Mechanism Explained and Every DKIM Attribute Explained cover those in full detail.


About this guide

This guide was written by the team building grimDMARC — a managed DMARC and SPF platform for MSPs and their customers. If you have questions about DMARC alignment or feedback on this guide, reach us at hello@grimdmarc.com.


Last updated: August 2026 Reading time: 9 minutes Reviewed by: grimDMARC team