DMARC alignment explained: why SPF can pass and DMARC still fail

DMARC passes when at least one of SPF or DKIM passes and is aligned: the domain it authenticated matches the domain in the From address the recipient sees. A pass for some other domain does not count. That is the whole trick, and it is why a report can show SPF and DKIM both passing while DMARC fails.

Why alignment exists

SPF and DKIM each authenticate a domain, but neither was designed to authenticate the From address. SPF checks the envelope sender, which the recipient never sees. DKIM checks whichever domain is named in the signature’s d= tag, which can be anything the signer controls. Without alignment, a spammer could send mail “From: you@yourbank.com” that passes SPF for their own domain and DKIM for their own domain, and both checks would be technically true. DMARC closes that gap by requiring the authenticated domain to be the one on the From line.

The two ways to align

• SPF alignment: the envelope sender (Return-Path) domain matches the From domain, and SPF passes for it.
• DKIM alignment: the d= domain in a valid DKIM signature matches the From domain.

Only one is needed. DKIM alignment is the more robust of the two, because a DKIM signature survives forwarding and SPF does not. If you can only get one working, make it DKIM.

Relaxed and strict

By default alignment is relaxed: the domains only need to share an organisational domain, so mail signed by mail.example.com aligns with a From address at example.com. Strict alignment (adkim=s or aspf=s in the record) requires an exact match. Relaxed is right for almost everyone; strict mostly creates failures for subdomains you forgot about.

The usual cause of failures: DKIM signed with the wrong domain

Both big mailbox providers sign outgoing mail with DKIM even if you never configured it, but by default they sign with their own domain rather than yours. That signature is valid, and it is not aligned.

• Google Workspace: until you generate a DKIM key in the Admin console and publish it (usually at google._domainkey), mail is signed with a Google-owned domain. Turning on DKIM for your domain fixes alignment.
• Microsoft 365: until you enable DKIM for your custom domain, mail is signed with your tenant’s onmicrosoft.com domain. Enabling it means publishing the two CNAME records Microsoft gives you (selector1 and selector2) and switching signing on.

Mail from your own Workspace or 365 mailbox normally aligns on SPF already, because the envelope sender is your domain. But relying on SPF alone means any forwarded message fails DMARC, so set up DKIM regardless.

Reading the record

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

• p: what receivers should do with mail that fails. none only monitors, quarantine usually means the spam folder, reject means refuse it.
• rua: where aggregate reports go. Without it you are flying blind: the reports are how you find every service sending as your domain.
• sp: a separate policy for subdomains. If absent, subdomains inherit p.
• pct: the share of failing mail the policy applies to, for a gradual rollout.
• adkim and aspf: relaxed (r, the default) or strict (s) alignment.

Rolling DMARC out without losing mail

1. 1Publish p=none with a rua address. Nothing changes for delivery, and reports start arriving within a day or two.
2. 2Read the reports for two to four weeks. Every legitimate service sending as your domain should show up aligned. Anything that is legitimate and not aligned needs DKIM configured, or needs moving to a subdomain.
3. 3Move to p=quarantine, optionally with a low pct first, once the only failing mail is mail you do not recognise.
4. 4Move to p=reject when quarantine has run cleanly for a while.

p=none is not a failure state. Google and Yahoo require bulk senders to publish DMARC, and p=none meets that requirement; see what the bulk sender rules actually ask for. But it protects nobody from spoofing until you move past it.