Guides

DMARC alignment, explained

Last updated 2026-08-28

Every DMARC question that starts "but SPF passes" has the same answer. SPF passing tells you a domain was authenticated. It does not tell you which domain.

Three domains per message

A single message carries at least three domain names, and people conflate them constantly.

• The envelope sender, also called MAIL FROM or return-path. Where bounces go. The recipient never sees it. Shows up in headers as smtp.mailfrom. SPF checks this one.
• The DKIM signing domain, the d= tag in the DKIM-Signature header. Also invisible to the recipient. DKIM authenticates this one.
• The From header domain, the address shown in the mail client. Appears in headers as header.from. DMARC protects this one, and only this one.

Alignment is the requirement that a domain something authenticated matches the domain the reader sees. Without it, SPF and DKIM are checks on identities nobody looks at, which is the state email was in before DMARC existed.

The rule

DMARC passes when at least one of these holds:

• SPF returns pass, and the envelope sender domain aligns with the From domain.
• DKIM verifies, and the signature's d= aligns with the From domain.

One is enough. A message with SPF failing and aligned DKIM passing gets a DMARC pass, and that is the normal state of every forwarded message you send.

Relaxed against strict

Two tags control it: aspf for SPF and adkim for DKIM. Both default to r, relaxed.

From domain	Authenticated domain	Relaxed	Strict
example.com	example.com	Aligned	Aligned
example.com	mail.example.com	Aligned	Not aligned
news.example.com	example.com	Aligned	Not aligned
example.com	bounces.vendor.net	Not aligned	Not aligned
example.com	example.co.uk	Not aligned	Not aligned

Relaxed matches on the organisational domain, which is the registrable name plus its public suffix. That is why news.example.com and example.com are the same organisation, and why example.com and example.co.uk are not, however obviously related they look to you.

Set strict alignment and every subdomain sender you have stops aligning. There are legitimate reasons to want it, mostly at organisations that have locked down exactly which hosts may sign. If you cannot name yours, leave both tags alone.

Worked example: the vendor

SPF passes, for mail.vendorapp.net. DKIM verifies, for vendorapp.net. Neither is example.com. DMARC fails, the disposition follows your policy, and the vendor's support team will tell you their authentication is configured correctly, which is true and irrelevant.

The fix is domain authentication at the vendor, which changes d= to your domain, and a custom return-path, which moves the envelope sender onto a subdomain of yours. The provider pages have the records for each of the common ones.

Worked example: forwarding

A recipient forwards this to another mailbox. The forwarding server connects from its own IP, which is not in your SPF record, so SPF fails. The signature is untouched, so DKIM verifies for example.com and aligns. DMARC passes.

Nothing you can publish makes plain forwarding pass SPF, and you should stop trying. This is the practical reason DKIM matters more than a perfect SPF record: it is the identifier that survives the path.

Where that breaks is a forwarder that edits the message, typically by appending a footer, which invalidates the body hash. That failure has its own page. ARC exists to let a trusted forwarder vouch for the original result, and receivers that honour it will let such mail through, but it is their decision and not something you can rely on from the sending side.

Reading it in a header

One line tells you everything. Send a message to a Gmail address you control and open Show original:

Compare header.from against the domains in the spf and dkim parts of the same line. If neither matches, dmarc=fail follows, whatever else passed. The field-by-field walkthrough covers the rest of that header, including Microsoft's compauth.

Alignment across your own domains

Two things surprise people who run more than one domain.

• A subdomain inherits the parent's policy unless sp= or its own DMARC record says otherwise. Alignment is relaxed by default, so this normally works in your favour.
• Sibling domains never align with each other. Mail from example.net signed by example.com fails, no matter that you own both. Each domain needs its own records.

What to check when something fails

1. Get the Authentication-Results line from a real message.
2. Write down the three domains: header.from, smtp.mailfrom, and the signature's d=.
3. Check your aspf and adkim with the DMARC checker. If either is s, ask whether you meant it.
4. Confirm the selector resolves with the DKIM checker, using the s= and d= you just wrote down. A selector that still resolves can be a leftover from a rotation; on a paid plan, the signing keys check gives each one a keep, review or remove verdict from 90 days of reports.
5. If you cannot get a header, the aggregate reports have the same information for every sender at once. Reading one takes about five minutes.

Alignment is the only conceptual part of DMARC. Everything else is DNS records and patience. Once you can look at a header and name which of the three domains failed to match, the rest of this stops being a protocol you are fighting and becomes a checklist you are working through.

Point your rua= tag at a mailbox someone reads. We parse that XML and mail you the senders that used your domain and whether each one passed. Paid plans add an alert the day a report first names a new sender failing. One free domain, no card.

DomainCanary is a DMARC monitoring service that turns your domain's aggregate reports into one weekly email.