DMARC alignment: From vs Return-Path (strict vs relaxed)

dmarcspfdkimtutorial

If you've ever stared at a DMARC report thinking "but SPF is passing... why is DMARC failing?", you've already met identifier alignment.

Alignment is one of those things that sounds like an academic detail until it bites you in production. Then it becomes the entire story.

In DMARC terms, what matters most is the domain your recipients actually see: the one in the email's From: header (that's the RFC 5322 From, often written as 5322.From). DMARC then asks a pretty pointed question:

"Can we prove this visible From: domain is connected to something authenticated about how the message was sent?"

That "something authenticated" is usually:

  • SPF (which authenticates the SMTP envelope sender domain - RFC 5321 MAIL FROM, aka 5321.MailFrom)
  • DKIM (which authenticates the domain in the DKIM signature's d= tag)

DMARC passes if either SPF or DKIM passes and is aligned to the visible From: domain.

If you want the high-level intro first, read What is DMARC?, then come back here. This post is the "okay, but what does alignment really mean?" layer.

The three domains that matter (and why the names are confusing)

When debugging DMARC failures, don't start with DNS. Start by writing down the three identities involved, because most failures are simply "these two domains don't match".

Here's a cheat sheet worth keeping handy:

What it isWhere you'll see itWhat it's used for
5322.From (the visible author domain)From: Jane <jane@example.com>DMARC policy lookup and alignment target
5321.MailFrom (the envelope sender domain)SMTP MAIL FROM:<bounce@bounces.example.com>; often shows up later as Return-Path:SPF authenticates this domain; DMARC uses it for SPF alignment
DKIM d= (the signing domain)DKIM-Signature: ...; d=example.com; s=...DKIM authenticates this domain; DMARC uses it for DKIM alignment

Two practical notes:

1) "Return-Path" is not the same thing as "From". Return-Path: is basically a stamped copy of the SMTP envelope sender as observed by the final receiver.

2) DMARC doesn't authenticate the local-part (the left side of the email address). It's about domains. alerts@ vs billing@ doesn't matter for DMARC; example.com vs example.net absolutely does.

If SPF/DKIM basics feel fuzzy, these two backgrounders help:

What "alignment" actually means

DMARC's definition is straightforward: the domain in 5322.From has to match (align with) a domain that passed SPF or DKIM.

The trick is that "match" can mean two different things depending on your DMARC record:

  • aspf= controls SPF alignment
  • adkim= controls DKIM alignment

Each can be either:

  • r = relaxed (default)
  • s = strict

This is where people get tripped up: relaxed vs strict is not "more secure vs less secure" in a simple sense. It's closer to "tolerant vs picky". And "picky" can break legitimate mail if you don't design your domains around it.

Relaxed alignment (the default)

Relaxed alignment compares organizational domains.

In plain English: mail.example.com and example.com are considered "the same family", so they align.

So with relaxed mode:

  • From: billing@example.com
  • DKIM d=mail.example.com

...can still be a DMARC pass via DKIM alignment.

This is why you'll see a lot of well-run setups using subdomains for different senders (marketing, notifications, bounces) without breaking DMARC.

Strict alignment

Strict alignment requires the domains to be an exact match.

So:

  • From: billing@example.com
  • DKIM d=mail.example.com

...does not align in strict mode.

Strict can be useful, but it's a commitment. The moment you start using subdomains (which is often a good operational pattern), strict becomes fragile.

The classic "SPF passes but DMARC fails" scenario

Let's make this concrete.

You send mail that looks like it's from your domain:

From: invoices@example.com

But your email platform uses its own bounce domain for the envelope sender (very common):

Return-Path: <bounces+abc123@provider-mail.example-sender.net>

SPF can pass (because the platform is authorized for example-sender.net) while DMARC still fails, because DMARC is trying to protect example.com.

No alignment, no DMARC pass.

If you want a real-world walkthrough of this type of failure, see Solved: Google Calendar invites failing DMARC checks. It's the same underlying problem: the visible domain and the authenticated domain aren't the same.

How you usually fix it

In practice, you fix this in one of two ways:

1) Make DKIM align

Configure the sender (your ESP, SaaS tool, etc.) to DKIM-sign with your domain (d=example.com or a subdomain of it). Many providers call this "custom DKIM", "domain authentication", or "bring your own domain".

2) Make SPF align

Configure a custom envelope sender / return-path domain under your domain, like:

MAIL FROM: <bounce@bounces.example.com>

Then publish SPF for bounces.example.com that authorizes your provider.

In practice, aligned DKIM is usually the better primary signal, because SPF is the one that tends to break under forwarding and list modifications. (This becomes painfully obvious once enough reports go by.)

If you're using Google Workspace, there's a related "looks fine until it doesn't" pattern in Your Google Workspace DKIM setup may be broken (and you may not know it).

Choosing adkim/aspf without breaking things

Defaulting both to relaxed is the normal, safe move:

v=DMARC1; p=...; adkim=r; aspf=r; ...

When does strict make sense?

  • You have one sending platform and you control it tightly.
  • You don't use subdomains in From: (or you're intentionally splitting mail streams by subdomain and enforcing that separation).
  • You've watched reports long enough to be confident you won't reject legitimate mail when you flip the switch.

Reassurance: strict alignment is not a required "best practice" to be "doing DMARC right". In most organizations, relaxed alignment plus good sender hygiene is the sustainable option.

A quick way to debug alignment from headers

When you have a failing sample message, look for these in the headers:

  • From: (your 5322.From domain)
  • Return-Path: (a good proxy for the 5321.MailFrom domain)
  • DKIM-Signature: ... d=... (the DKIM signing domain)
  • Authentication-Results: (many receivers summarize SPF/DKIM/DMARC results here)

Then ask:

  • Did SPF pass? If yes, for which domain (MailFrom)? Does it align to From?
  • Did DKIM pass? If yes, for which domain (d=)? Does it align to From?

This sounds obvious, but it's surprisingly easy to lose track of which domain you're "fixing" when you're deep in DNS changes.

The part people forget: DMARC passes if any aligned mechanism passes

Two handy consequences of that rule:

1) A message can have multiple DKIM signatures, and DMARC is happy if one of them both verifies and aligns.

2) You can deliberately design "fallback" paths: for example, aim for aligned DKIM as the primary signal, and keep aligned SPF as a safety net for cases where a signature gets broken by a downstream system.

(If you've been burned by signatures breaking due to rewriting, footers, or MIME transformations, you're not alone - that's a whole topic by itself.)

Where this usually shows up in DMARC reports

In aggregate reports, you'll commonly see patterns like:

  • SPF: pass, but spf_aligned: fail
  • DKIM: pass, but dkim_aligned: fail

Those are "your authentication works, but it's authenticating the wrong domain for DMARC."

That's (mis)alignment, in one sentence.

Previous Post