What is DMARC Alignment & Why Mail Fails It

24 June 2026 · DMARC Engine · 7 min read

DMARC alignment is the rule that connects an SPF or DKIM pass back to the domain your recipients actually see in the From: address. A message only passes DMARC when at least one of those two checks both passes and is aligned with the visible From domain. This is the single most common reason a message that "passes SPF" or "is DKIM-signed" still ends up with a DMARC verdict of fail, and it is why a perfectly legitimate newsletter or invoicing tool can be quarantined once you move to enforcement.

This article explains alignment in plain terms, walks through a worked example, shows you how to verify it from a real report, and lists the problems that trip people up most often.

The short answer

DMARC (RFC 7489) does not trust SPF and DKIM on their own. SPF and DKIM each validate a domain, but not necessarily the same domain your reader sees. Alignment is the test that the authenticated domain matches the header From domain (the d= of the DKIM signature for DKIM, or the SPF-authenticated MAIL FROM / Return-Path domain for SPF).

So a message fails DMARC when both of these are true:

SPF either fails, or passes but the SPF-checked domain does not align with the From domain.
DKIM either fails (or is absent), or passes but the signing d= domain does not align with the From domain.

If even one of the two is a passing-and-aligned result, DMARC passes. You do not need both.

The two identifiers, and why they drift apart

Every email actually carries more than one "domain". DMARC only cares about one of them being the anchor: the header From, the From: shown to the human. The authentication checks look at different fields entirely.

SPF alignment

SPF (RFC 7208) authenticates the MAIL FROM address, the envelope sender, also called the Return-Path or bounce address. This is invisible to your recipient and is frequently set by your sending platform, not by you.

A classic example: you send from you@yourdomain.com, but your marketing platform sets the Return-Path to bounces@mail.sendingplatform.com. SPF checks sendingplatform.com, finds a valid record, and returns pass. But the SPF-authenticated domain is sendingplatform.com, while your From domain is yourdomain.com. They do not align, so SPF contributes nothing to DMARC.

DKIM alignment

DKIM (RFC 6376) signs the message with a key, and the signature header carries a d= tag naming the signing domain. DKIM alignment compares that d= domain to the header From domain.

If your platform signs with d=sendingplatform.com rather than d=yourdomain.com, the signature verifies perfectly (DKIM pass) but again it is the wrong domain, so it is not aligned.

This is the crux: SPF can pass and DKIM can pass, and DMARC can still fail, because both were authenticating a service provider's domain, not yours.

Relaxed vs strict alignment

DMARC offers two alignment modes, set independently for SPF and DKIM in your DMARC record via the aspf and adkim tags. The default for both is relaxed.

Relaxed (r, the default): the Organizational Domain must match. mail.yourdomain.com aligns with yourdomain.com, and so does yourdomain.com itself. Subdomains of your registered domain are treated as the same organisation.
Strict (s): the domains must match exactly. mail.yourdomain.com would not align with yourdomain.com under strict; only an exact string match counts.

A record requesting strict on both looks like this:

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:reports@yourdomain.com

Most organisations should leave both at relaxed. Strict alignment is occasionally used to lock down a specific subdomain policy, but it breaks far more legitimate mail than it secures and is rarely worth it. The "Organizational Domain" is derived from the Public Suffix List, which is why yourdomain.co.uk resolves correctly rather than treating co.uk as the org domain.

A worked example

Suppose you send invoices through a billing tool. A recipient's mail server sees:

From: billing@yourdomain.com: this is the DMARC anchor.
Return-Path: bounce@billtool-mail.com: SPF checks billtool-mail.com.
DKIM signature: d=billtool-mail.com: DKIM checks billtool-mail.com.

Now evaluate:

SPF result: pass (the billing tool's SPF record is valid). Aligned? No. billtool-mail.com ≠ yourdomain.com under relaxed.
DKIM result: pass (signature verifies). Aligned? No. d=billtool-mail.com ≠ yourdomain.com.
DMARC: because neither check is both pass and aligned, the result is fail.

At p=none you would only see this in your reports. At p=quarantine or p=reject, those invoices start landing in spam or bouncing. The fix is to make at least one identifier align.

How to fix alignment failures

You almost always fix DMARC alignment by establishing DKIM alignment with each sending service, because DKIM survives forwarding and mailing lists in a way SPF does not. Work through this sequence for each platform that sends as your domain.

Identify every sender. Read your DMARC aggregate (RUA) reports to list which sources are failing alignment and on which identifier. See how to read a DMARC aggregate report.
Enable custom-domain DKIM in the platform. Most services let you sign with your own domain instead of theirs. They give you CNAME or TXT selector records (for example s1._domainkey.yourdomain.com) to publish. Once live, the signature carries d=yourdomain.com and DKIM aligns. Our walkthrough is setting up DKIM for your domain.
Align SPF where you can (and where it helps). Some platforms support a custom Return-Path / bounce subdomain such as bounce.yourdomain.com, delegated to them. That makes the SPF-checked domain a subdomain of yours, which aligns under relaxed. This is optional if DKIM already aligns, but it adds resilience.
Mind the SPF 10-lookup limit. Each include: in your SPF record costs DNS lookups; exceed ten and SPF returns permerror, which counts as an SPF failure. If you are near the limit, flatten your record. Our SPF checker shows your lookup count.
Re-test, then ramp the policy. Confirm alignment in fresh reports before tightening from p=none to quarantine to reject. See the enforcement journey and is it safe to move to p=reject.

How to verify alignment

You do not need to guess. Verify it two ways.

From the raw headers

Open a delivered message and view its source. Find the Authentication-Results header added by the receiver. A passing, aligned DKIM result reads something like:

Authentication-Results: mx.google.com;
  dkim=pass header.d=yourdomain.com;
  spf=pass smtp.mailfrom=bounce.yourdomain.com;
  dmarc=pass (p=REJECT) header.from=yourdomain.com

The key comparison is header.d= (DKIM) and smtp.mailfrom= (SPF) against header.from=. When the org domains match, you are aligned, and dmarc=pass follows.

From aggregate reports

In each RUA record, look at the <policy_evaluated> block versus <auth_results>. A row can show dkim=pass under auth_results but dkim=fail under policy_evaluated; that gap is an alignment failure, not a signature failure. Run a quick health check anytime with the DMARC checker, and see how to check DMARC is working.

Common problems and gotchas

"SPF passes, so why does DMARC fail?" Because SPF authenticated the platform's Return-Path domain, not your From domain. Fix DKIM alignment instead of chasing SPF.
Mailing lists and forwarders break SPF. When a list relays your mail, SPF authenticates the list's domain, so SPF alignment is lost. Aligned DKIM usually survives, which is why DKIM is the more reliable identifier to fix.
Strict mode set by accident. If you published aspf=s or adkim=s without reason, subdomain and mail. senders will fail. Revert to relaxed unless you have a specific need.
Subdomain confusion. Mail from news.yourdomain.com with a DMARC anchor of news.yourdomain.com still aligns to a policy on yourdomain.com under relaxed and the org-domain rules, but check whether a subdomain DMARC record or sp= tag is overriding what you expect.
Display-name spoofing is not an alignment problem. Alignment governs the domain in the From address, not the friendly display name. A look-alike display name with a legitimate aligned domain still passes DMARC; defending against that needs other controls.

Next steps

Alignment is the bridge between "my mail is signed" and "my mail is trusted". Pull your aggregate reports, map every sender, and for each one make sure DKIM signs with d=yourdomain.com (and align SPF where the platform allows). Keep aspf and adkim at relaxed unless you have a concrete reason not to, and only ramp toward p=reject once reports show every legitimate source passing aligned.

If you would rather not chase this across a dozen vendors by hand, hosted DMARC from DMARC Engine surfaces each unaligned source in your reports, tells you exactly which identifier to fix, and guides you safely to enforcement to p=reject with no email outage.

What is DMARC alignment and why does my mail fail it?