DMARC alignment is the check that the domain authenticated by SPF or DKIM matches the domain in the visible From address. In relaxed mode (the default), the two only need to share the same organizational domain, so mail.example.com aligns with example.com. In strict mode, they must be identical. You set the mode separately for DKIM (adkim) and SPF (aspf) in your DMARC record, and for most senders relaxed is the right choice.

This article focuses on the two modes, how receivers decide what the “organizational domain” is, and when strict makes sense.

Why alignment exists

SPF and DKIM each authenticate some domain, but not necessarily the one your recipient sees:

SPF authenticates the envelope sender (Return-Path), such as bounces@em123.mailer.example.net.
DKIM authenticates the signing domain in d=, such as d=mailer.example.net.
The recipient sees From: Example Store <orders@example.com>.

Without alignment, a phisher could send from their own fully authenticated domain while putting your domain in the From line. DMARC’s alignment rule says an SPF or DKIM pass only counts if its domain matches the From domain. RFC 9989, the DMARC standard published in May 2026, defines both modes in section 3.2.10.

If you’re seeing DMARC failures even though SPF and DKIM show pass, the existing article on why alignment fails while everything passes walks through the common causes. This one is about choosing and understanding the modes.

Relaxed vs strict alignment

	Relaxed (`r`, default)	Strict (`s`)
Rule	Same organizational domain	Exact same domain
`example.com` vs `example.com`	Aligned	Aligned
`news.example.com` vs `example.com`	Aligned	Not aligned
`a.example.com` vs `b.example.com`	Aligned	Not aligned
`example.com` vs `example.net`	Not aligned	Not aligned
`example.com` vs `example.com.evil.example.net`	Not aligned	Not aligned

RFC 9989 Table 1 uses the same kind of example: foo.example.com and news.example.com align under relaxed mode because they share the organizational domain example.com. Domain comparison is case-insensitive.

The tags

v=DMARC1; p=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com

adkim=r or adkim=s sets DKIM alignment. Default r.
aspf=r or aspf=s sets SPF alignment. Default r.

If you leave them out, you get relaxed for both. You can mix them: adkim=s; aspf=r is valid.

How DKIM alignment works in practice

Receivers compare the d= tag of each valid DKIM signature to the From domain.

From: Example Store <orders@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
DKIM-Signature: v=1; a=rsa-sha256; d=mailer.example.net; s=k1; ...

The first signature aligns (strict and relaxed). The second passes DKIM but doesn’t align. DMARC only needs one aligned, passing signature, so this message passes.

If your platform signs as d=em.example.com instead, it aligns under relaxed but not strict.

How SPF alignment works in practice

Receivers compare the domain of the envelope sender (the Return-Path) to the From domain.

Return-Path: <bounce-8812@bounce.example.com>
From: Example Store <orders@example.com>

Under relaxed mode, bounce.example.com aligns with example.com. Under strict mode it doesn’t.

This is why custom bounce domains matter. With Amazon SES, for example, the default MAIL FROM is a subdomain of amazonses.com. SPF passes, but for SES’s domain, so it can’t align with yours. AWS’s documentation notes that to use SPF for DMARC, the From domain must match the custom MAIL FROM domain, and its MAIL FROM rules say the custom domain must be a subdomain of your verified domain. That works under relaxed alignment; it never works under strict, because the bounce subdomain can’t be identical to your From domain.

How receivers find the organizational domain

Relaxed alignment depends on knowing that news.example.com and example.com belong to the same organization, while example.co.uk and other.co.uk do not. That’s the “organizational domain.”

Old method: the Public Suffix List

Under RFC 7489, receivers used a Public Suffix List (PSL) of registry-controlled suffixes like .com, .co.uk, and .github.io, and treated the label just below the suffix as the organizational domain.

New method: the DNS tree walk

RFC 9989 replaces PSL reliance with a “DNS tree walk” (section 4.10). The receiver queries for DMARC records progressively up the domain’s labels, for example:

_dmarc.mail.news.example.com
_dmarc.news.example.com
_dmarc.example.com
…and so on toward the top of the tree, until the rules in section 4.10 say to stop

The new psd tag lets a public suffix operator mark its record with psd=y, and an organization can mark its own top-level record with psd=n to say “the organizational domain is here.” The walk is capped: domains with more than eight labels don’t trigger more than eight queries, and RFC 9989 section 5.1.8 warns that a record placed deeper than the limit may never be found.

What this means for you

If you publish your DMARC record at _dmarc.example.com, nothing changes. Relaxed alignment still treats anything.example.com as aligned with example.com.
If you run a platform where customers get subdomains of your domain (like customer1.example-app.com), consider whether those should be separate organizational domains. That’s what psd and the tree walk are for. Read section 4.10 before you rely on it.
Very deep hostnames (eight or more labels) should carry their own DMARC record.

Alignment by setup: worked examples

Here’s how common configurations come out under each mode, assuming the From address is orders@example.com:

Setup	DKIM `d=`	Return-Path domain	Relaxed result	Strict result
Workspace mail, custom DKIM	`example.com`	`example.com`	Pass (both)	Pass (both)
Marketing platform, default settings	`platform.example.net`	`bounces.platform.example.net`	Fail	Fail
Marketing platform, custom DKIM only	`example.com`	`bounces.platform.example.net`	Pass (DKIM)	Pass (DKIM)
SES with custom MAIL FROM and Easy DKIM	`example.com`	`bounce.example.com`	Pass (both)	Pass (DKIM only)
Platform signing with a subdomain	`em.example.com`	`em.example.com`	Pass (both)	Fail

Two lessons stand out. First, the default settings of most third-party platforms don’t align at all, in either mode; you have to turn on custom domain authentication. Second, strict mode mostly bites when a platform uses a subdomain for signing or bounces, which is common.

When to use strict alignment

Strict alignment rarely improves security for ordinary senders, and it makes legitimate mail fail more often. Consider it only if:

You have subdomains you don’t fully trust. For example, a university where departments run their own mail on dept.example.edu. With strict, a compromised department subdomain can’t produce aligned mail for example.edu.
You delegate subdomains to third parties and want to prevent mail authenticated for vendor.example.com from counting toward example.com.
Every sender already signs DKIM as the exact From domain, so strict costs you nothing.

Use relaxed when:

Any platform uses a bounce subdomain (bounce.example.com) for SPF.
Any platform signs DKIM with a subdomain (em.example.com).
You send marketing from news.example.com with From addresses on example.com.

That describes most companies.

Alignment decision checklist

List every sending platform and note its DKIM d= domain and its Return-Path domain.
For each, check: does DKIM d= equal or sit under your From domain? Does the Return-Path?
If any platform only aligns via a subdomain, keep that mechanism relaxed.
If all DKIM signatures use the exact From domain, adkim=s is safe; keep aspf=r if any bounce subdomain exists.
Watch your DMARC aggregate reports for a few weeks after any change.

Mailbox providers don’t require strict. Yahoo’s sender requirements explicitly say relaxed alignment is acceptable, and Google requires the From domain to align with either the SPF or DKIM domain for bulk senders, without demanding strict mode.

Checking alignment on a real message

Send a test to a Gmail account and open “Show original.” In the Authentication-Results header, compare:

dkim=pass header.i=@example.com
spf=pass smtp.mailfrom=bounce.example.com
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

header.from is the From domain. header.i (or header.d) is the DKIM domain. smtp.mailfrom is the SPF domain. If DMARC fails while both show pass, one of those domains doesn’t align. The DMARC checker on this site shows your published adkim and aspf values.

For the full DMARC picture, see DMARC explained, and if you’re still at monitoring, moving from p=none to p=reject.

Alignment gets your mail recognized. Keeping it out of bounce trouble is a list problem. Our free email verifier flags bad syntax, domains without MX records, disposable and role-based addresses, and common typos before you send. It doesn’t open an SMTP session to the mailbox, so it won’t confirm a specific inbox exists, but it removes the failures DNS can reveal.

FAQ

What is the default DMARC alignment mode?

Relaxed, for both DKIM and SPF. If your record doesn’t include adkim or aspf, receivers use relaxed mode, which accepts any subdomain of the same organizational domain.

Does DMARC need both SPF and DKIM to align?

No. One aligned pass is enough. RFC 9989 does caution against relying solely on SPF when your policy is p=reject, because SPF breaks when mail is forwarded, so aim for aligned DKIM on every stream.

Is strict alignment more secure?

Only in specific cases, such as when you don’t trust everyone who controls your subdomains. For most senders it just causes legitimate mail to fail. Relaxed alignment still blocks mail authenticated by unrelated domains.

Why does my email platform’s DKIM pass but DMARC fail?

The platform is probably signing with its own domain, like d=mailer.example.net, which doesn’t align with your From domain. Turn on custom domain authentication in the platform so it signs as your domain or a subdomain of it.

DMARC Alignment: Strict vs Relaxed Explained