DMARC Alignment Explained: SPF, DKIM, and the From: Header

The Question Alignment Actually Answers

SPF answers one question: is this sending IP authorized for the domain in the SMTP envelope? DKIM answers a different one: does this cryptographic signature verify, and which domain does it belong to? Neither of those, on its own, answers the question that actually matters to a person looking at their inbox: does the domain that just got authenticated match the domain shown in the From: field they're looking at? That's the specific gap alignment closes, and it's the mechanism that makes DMARC meaningfully different from "just check SPF and DKIM."

A message can have a perfectly valid SPF pass and a perfectly valid DKIM signature and still fail DMARC entirely, if both of those passes point to a domain other than the one in the From: header. This is not a bug or an edge case — it's the exact scenario alignment is designed to catch, because it's precisely how a lot of domain spoofing actually works: legitimate infrastructure, real authentication, wrong displayed identity.

Relaxed vs Strict Alignment

Relaxed mode is the default for good reason: real sending infrastructure very commonly uses subdomains — bounce handling on bounce.example.com, transactional mail on mail.example.com, marketing platforms configured under mkt.example.com — and none of that should have to break DMARC just because it isn't the bare root domain. Strict mode exists for organizations with tightly controlled, centralized sending infrastructure where that subdomain flexibility isn't needed and the extra precision is worth the compatibility cost.

Worked Example: SPF Alignment

A message arrives with envelope sender bounce@mail.example.com and From: header billing@example.com. SPF is checked against the envelope domain, mail.example.com, and passes — that server is authorized. Now alignment is checked: does mail.example.com align with example.com?

• Under relaxed alignment (aspf=r): Yes — mail.example.com is a subdomain of example.com, so it aligns. SPF contributes a DMARC pass.
• Under strict alignment (aspf=s): No — the domains aren't an exact match. SPF does not contribute a DMARC pass, even though the raw SPF check itself succeeded.

Worked Example: DKIM Alignment

A message is DKIM-signed with d=thirdpartyplatform.com — the signing domain belongs to a marketing platform, not the customer. The From: header shows news@example.com. The DKIM signature itself verifies correctly; the question is whether thirdpartyplatform.com aligns with example.com.

• It does not — under either relaxed or strict mode — because thirdpartyplatform.com isn't a subdomain of example.com at all; it's an entirely unrelated domain. This is exactly the scenario that trips up organizations using marketing or transactional platforms without properly configuring custom DKIM signing (often via a CNAME the platform provides) so the signature carries the customer's own domain instead.

Why Third-Party Senders Are the Most Common Failure Source

How to Fix an Alignment Failure

For SPF: configure the sending platform to use a custom "return path" or bounce domain under your own domain (something like bounce.example.com) rather than the platform's own, and include the platform's sending infrastructure in your SPF record under that subdomain. For DKIM: configure custom DKIM signing, usually via a CNAME record the platform provides, so outgoing mail is signed with a selector under your own domain rather than the platform's. Both changes are typically documented step-by-step by major email platforms specifically because DMARC alignment failures are such a common support request.

Alignment and the Organizational Domain, Precisely Defined

The term "organizational domain" gets used loosely, but it has a specific technical meaning worth pinning down: it's the registrable root domain, determined using the Public Suffix List rather than simple dot-counting. For a domain like example.com, that's straightforward — the organizational domain is example.com itself. For domains under certain public suffixes like example.co.uk, the organizational domain is example.co.uk, not co.uk, because co.uk itself is a public suffix rather than a registrable domain. This distinction matters specifically for relaxed alignment calculations, since relaxed mode checks whether two domains share the same organizational domain — getting the organizational domain determination wrong (treating co.uk as the shared root, for instance) would produce incorrect alignment results entirely.

Testing Alignment Before It Matters

Rather than discovering an alignment problem only after enforcement is live and mail starts failing, it's straightforward to test alignment proactively. Send a test message through each sending platform to an account at a major provider like Gmail, then inspect the message's authentication headers directly — most major webmail clients expose a "show original" or equivalent view that reveals the raw SPF and DKIM results alongside their alignment status. This lets a domain owner confirm alignment platform by platform, in a controlled way, well before relying on aggregate report data (which takes at least a day to arrive) or before enforcement makes an alignment gap operationally costly.

A Quick Reference for Common Alignment Scenarios

That last row is worth calling out specifically, since it illustrates exactly why DMARC's "only one needs to align" logic matters in practice: forwarding is common, breaks SPF almost by definition, and DMARC still works correctly as long as DKIM was configured to survive the forward — which it usually is, since DKIM signs message content rather than depending on the sending IP the way SPF does.

Alignment Failures Are Not Always Symmetrical

It's worth noting that alignment can behave asymmetrically across a domain's different sending purposes — transactional mail (password resets, receipts) frequently aligns cleanly because it's typically sent through carefully configured infrastructure with alignment already considered, while marketing mail sent through a separately configured platform can fail alignment entirely, even on the same domain, the same week. Treating "is my domain aligned" as a single yes/no question misses this — the more useful framing checks alignment per sending purpose or platform, since a domain can simultaneously be well-aligned for one use case and completely unaligned for another.

Alignment in the Context of Multi-Brand Organizations

Organizations operating multiple distinct brands from different domains face a specific alignment wrinkle: mail sent "on behalf of" one brand through infrastructure technically owned by a different, related domain will fail alignment unless deliberately configured otherwise, even though both domains belong to the same parent organization. There's no special DMARC exemption for related-company relationships — alignment is evaluated purely on domain names, with no awareness of corporate ownership structure. Each brand domain sending mail needs its own properly aligned SPF and DKIM configuration, independent of any shared infrastructure or corporate relationship with other domains in the portfolio.

The Relationship Between Alignment Mode and Migration Risk

Domains in the middle of an email platform migration face elevated alignment risk specifically, since two different sets of sending infrastructure — the old platform and the new one — may be active simultaneously for a transition period, each potentially aligned differently. Deliberately keeping alignment relaxed (rather than strict) during an active migration reduces the chance of an unexpected alignment failure specifically caused by the temporary complexity of running dual infrastructure, with a move to stricter alignment reserved for after the migration is fully complete and stable.

Alignment Testing Tools Beyond Manual Header Inspection

Beyond manually inspecting message headers, several dedicated online tools and email deliverability testing services exist specifically to send a test message and report back detailed SPF/DKIM/DMARC alignment results in a structured format, without requiring access to a live mailbox at a major provider. These are particularly useful for testing a new sending platform's configuration before it goes live in production, catching alignment problems in a sandboxed way rather than discovering them through real aggregate report data days later.

Related Reading in This Series

For the conceptual overview of DMARC and how alignment fits into the bigger picture, start with What Is DMARC?. For the full adkim/aspf tag syntax, see DMARC Record Explained. For how alignment failures show up in the reports you receive, read DMARC Aggregate Reports. To check your own domain's current alignment settings, open DMARC Lookup.