DMARC alignment explained

What alignment means

DMARC exists to protect one address: the domain in the From header, the one a mail app shows the reader. RFC 9989 calls it the Author Domain. Neither SPF nor DKIM checks the domain in that header against anything: DKIM signs the header, but its d= domain doesn't have to match it. Each of them authenticates a domain of its own, and DMARC's job is to decide whether either of those domains is close enough to the From domain to vouch for it. That comparison is alignment.

The two domains DMARC can borrow are:

• The SPF domain. SPF checks the envelope sender from the SMTP MAIL FROM command, which receivers usually record as the Return-Path header. RFC 7208 also checks the HELO name, but section 3.2.4 of RFC 9989 says DMARC relies only on the MAIL FROM result. When the envelope sender is empty, as it is on bounce messages, RFC 7208 section 2.4 uses postmaster@ plus the HELO name instead, so for bounces the name the server announced in HELO is the domain that has to align.
• The DKIM signing domain. This is the d= tag of a DKIM signature that verified. RFC 6376 section 3.5 describes it as the domain claiming responsibility for the message, and it is also where the public key is looked up.

Here are all three domains in one message sent through a mailing service:

Return-Path: <bounce-91c2@mailer.example.net>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mk1; ...
From: Example Shop <news@example.com>

SPF runs against mailer.example.net, the service's bounce domain. The signature was made with d=example.com. The reader sees example.com. Only the DKIM domain matches the From domain here, and that is enough: under section 5.3.5 of RFC 9989 a message passes DMARC when one or more authenticated identifiers align with the Author Domain. You do not need both. A message can carry several DKIM signatures, and any one aligned, valid signature counts (section 4.4.1).

The rule has to be this strict for a simple reason, which sections 4.4.1 and 4.4.2 spell out: anyone can sign mail with a domain they own, and anyone can publish an SPF record for a domain they own. A pass on its own proves only that some domain vouched for the message. Alignment makes it your domain. Two more details from section 4.4: domain names are compared without regard to case, and alignment is impossible when the From header is missing, malformed or repeated, because then there is no single Author Domain to compare against.

Relaxed vs strict

"Close enough" has two settings. In strict mode the authenticated domain must be identical to the From domain; RFC 9989 section 4.10.2 notes that this takes nothing more than a string comparison. In relaxed mode the two only need to share the same Organizational Domain, which for most senders means the same registered domain, so a subdomain lines up with its parent and with its siblings.

Your DMARC record sets the mode separately for each method. aspf covers SPF and adkim covers DKIM, and each takes r or s. Both are optional and default to r, so a record that mentions neither is relaxed for both. Mixing is allowed, for example strict DKIM with relaxed SPF:

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

The table shows how the same pairs of domains fare under each mode, assuming example.com publishes the DMARC record that covers its subdomains:

The third row is the common one in practice: a newsletter sent from news.example.com and signed with d=example.com passes in relaxed mode and fails in strict mode. The last row never aligns, whatever the mode, because example.net belongs to someone else.

Section 4.4 of RFC 9989 observes that nearly all domain owners have found relaxed alignment sufficient. Strict mode earns its place when you hand subdomains to other people. Section 11.8 describes the risk: if someone else controls the SPF record or the DKIM keys of a subdomain such as team.example.com, relaxed alignment lets them produce a DMARC pass for mail from example.com itself. If that cannot happen in your organization, relaxed is the more practical choice, because strict mode fails every service that signs or bounces with a subdomain of yours. Setting aspf=s without checking is a classic cause of the problem covered in DMARC fails even though SPF passes.

The Organizational Domain and the DNS Tree Walk

Relaxed mode depends entirely on one question: what is the Organizational Domain of a name? RFC 9989 defines it as the domain at the top of the namespace hierarchy that still has the same administrative authority. For news.example.com that is normally example.com, not com: whoever runs example.com does not run com.

What changed from RFC 7489

The original DMARC specification, RFC 7489, took the answer from a Public Suffix List, a published list of suffixes such as com and co.uk under which people register names. Section 4.10 of RFC 9989 explains why that was replaced: RFC 7489 required no particular list and said nothing about how often receivers should refresh it, so two receivers could disagree about the same domain. RFC 7489 itself suggested that a more reliable method should take over if one appeared. RFC 9989 provides it, a discovery technique it calls the DNS Tree Walk, which reads the answer from DMARC records in DNS instead.

How the walk works

The receiver looks for a DMARC record at _dmarc. plus the starting name, then removes the left-most label and asks again, one level at a time, until it runs out of labels. Records that do not start with the DMARC version tag are ignored, and if one name returns more than one DMARC record, all of them are discarded. The walk stops early when it finds a single record carrying psd=y or psd=n. To keep a hostile sender from forcing hundreds of lookups with a very long name, the walk makes at most eight queries: after the first one, a name with eight or more labels is cut down to its last seven.

From the records it found, the receiver picks the Organizational Domain, working from the longest name to the shortest:

1. A record with psd=n makes its own domain the Organizational Domain.
2. A record with psd=y, other than one at the starting name, marks a public suffix, so the Organizational Domain is the name one label below it.
3. Otherwise the record with the fewest labels wins.

If the walk finds no DMARC record at all, the starting name is its own Organizational Domain.

Worked examples

Take mail from example.com signed with d=mail.example.com, where only example.com publishes a DMARC record. The walk for the signing domain asks for _dmarc.mail.example.com (nothing), _dmarc.example.com (a record) and _dmarc.com (nothing). The Organizational Domain is example.com for both names, so they align in relaxed mode. Now take d=mailer.example.net: if no DMARC record turns up on the way up, the Organizational Domain of that name is mailer.example.net itself, which can never match example.com.

The walk also lets a domain owner draw a boundary. Suppose example.com has a record and another team publishes one at _dmarc.mail.example.com with psd=n. That record makes mail.example.com an Organizational Domain of its own, so a.mail.example.com belongs to it, and a signature with d=example.com no longer aligns with From addresses at or under mail.example.com, even in relaxed mode. Section 5.1.8 of RFC 9989 describes this setup for large organizations that delegate parts of their DNS to local departments.

What the psd tag means for you

psd takes three values. y is for the operators of public suffixes such as com. n declares that a domain is not a public suffix but is the Organizational Domain for itself and everything below it. u, the default, leaves the decision to the walk. Most domain owners never need the tag. RFC 9989 mentions one situation where it helps and one limit to know about:

• Section 11.8 suggests psd=n on your own record if a public suffix above you ever publishes a DMARC record without psd=y, so that its record is not mistaken for your Organizational Domain.
• Section 5.1.8 warns that the eight-query limit means a psd=n record deep inside a very long name may never be queried. A From domain with more than eight labels that needs its own policy must publish a DMARC record at its exact name, because receivers always ask there first.

The same walk also decides which policy applies when the From domain has no record of its own: receivers fall back to the Organizational Domain's record and use its sp tag for subdomains (or np when the subdomain does not exist), and p when neither is set. What is DMARC? covers those policy tags.

Why SPF often isn't aligned

When a newsletter platform, a help desk or a billing system sends mail for you, it usually puts its own domain in the envelope sender, so that bounces come back to its servers and it can remove dead addresses from your list. SPF then passes for the platform's bounce domain, which is a different organization's domain, and the SPF result cannot count toward your DMARC. The message still passes if the platform signs with your domain, and fails if it signs with its own as well.

There are two ways to bring such a service into alignment:

• A custom return-path. Many platforms let you set a bounce subdomain such as bounces.example.com. Once its DNS records are in place, SPF runs against that subdomain, which aligns with example.com in relaxed mode (and not in strict mode).
• DKIM with your domain. Most platforms can sign with a key published under your domain, so the signature carries d=example.com. Because DMARC needs only one aligned pass, this alone fixes DMARC for that service, and it is the option that keeps working when a message is forwarded unchanged and SPF fails at the next hop.

One change that does not help: adding the platform's include: to the SPF record on example.com. While the platform uses its own envelope domain, receivers never consult your record for that mail. DMARC fails even though SPF passes walks through diagnosing this from headers and reports and setting up both fixes step by step.

Checking alignment

For a single message, open its full headers and paste them into the email header analyzer. It finds the From domain, the envelope domain and the d= domain of every DKIM signature, and says for each one whether it aligns in relaxed mode and in strict mode. It shows both because headers do not reveal which mode your record asks for. The tool decides relaxed alignment with the Public Suffix List rather than a DNS Tree Walk, which gives the same answer when your registered domain publishes the DMARC record but can differ in other setups, for example with psd=n or when only a subdomain has a record. That is why it also shows the receiver's own dmarc= verdict from Authentication-Results and points out when the two disagree: the receiver's verdict is the one that decided delivery.

For all of your mail at once, use your DMARC aggregate reports. Each record lists the From domain, the envelope domain, the raw SPF and DKIM results, and the receiver's alignment verdict in policy_evaluated. Upload one report to the DMARC report analyzer and every source gets a sentence explaining its verdict, such as SPF passing for a bounce domain that does not align with yours. How to read DMARC aggregate reports explains the fields if you would rather read the XML. To see which aspf and adkim values you actually publish, run the DMARC checker.

Alignment is also the main gate on the way to enforcement. With a Patchkit account, the "Path to p=reject" card on your domain page only recommends the next policy step when at least 98% of the mail from your authorized senders passed DMARC with alignment over the last 14 days and no more than 0.5% of all your mail came from senders marked misconfigured, so the services that fail alignment are the ones to fix first. The staged move from p=none to p=reject describes the other checks on that card.