DMARC alignment: why SPF can pass while DMARC fails

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.

The domains in a message

A single message carries at least three domain names, and people mix them up all the time.

• The envelope sender, also called MAIL FROM or return-path. Bounces go to this address, and the recipient never sees it. It shows up in headers as smtp.mailfrom. SPF checks this one.
• The DKIM signing domain, the d= tag in the DKIM-Signature header. The recipient doesn't see this one either. DKIM authenticates this one.
• The From header domain, the address shown in the mail client. It appears in headers as header.from. DMARC protects this one, and only this one.

Alignment means the domain that SPF or DKIM authenticated matches the domain the reader sees. Without it, SPF and DKIM check domains that nobody looks at, which is how email worked before DMARC existed.

When DMARC passes

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 and strict alignment

The aspf tag sets alignment for SPF, and adkim sets it 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 organizational domain, which is the registrable name plus its public suffix. That is why news.example.com and example.com are the same organization, 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 organizations that have locked down exactly which hosts may sign. If you cannot name yours, leave both tags alone.

Worked example: a vendor

SPF passes, for mail.vendorapp.net. DKIM verifies, for vendorapp.net. Neither is example.com. DMARC fails, and receivers, the mail servers at Gmail, Outlook and the rest, apply your policy. 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.

No record you publish makes plain forwarding pass SPF, so don't try. That's why DKIM matters more than a perfect SPF record. The signature survives forwarding, and the SPF check doesn't.

DKIM breaks when a forwarder edits the message, typically by adding a footer, which invalidates the body hash. DKIM body hash did not verify covers that failure. ARC lets a trusted forwarder pass on the original result, and receivers that honor it may let such mail through. Each receiver chooses whether to trust ARC, so you can't rely on it from the sending side.

Alignment in a message header

Send a message to a Gmail address you control, open Show original, and find this part of the Authentication-Results line:

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

Alignment across your own domains

• 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 favor.
• Sibling domains never align with each other. Mail from example.net signed by example.com fails, even though you own both. Each domain needs its own records.

When a message fails alignment

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 key rotation. On the Business plan and up, our signing keys check sorts each selector into keep, review or remove, using 90 days of reports.
5. If you cannot get a header, the aggregate reports have the same information for every sender at once. Reading an aggregate report takes about five minutes.

Alignment is the only hard concept in DMARC. The rest is DNS records and patience. Once you can look at a header and say which domain failed to match, every other step is a checklist item.

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. On a paid plan, we also email you the day a new sender first fails. One free domain, no card.