A common surprise: your mail shows spf=pass and dkim=pass in the headers, yet DMARC reports fail. The cause is almost always alignment.
What DMARC actually checks
DMARC does not just need SPF or DKIM to pass. It needs one of them to pass for a domain that matches the visible From address.
- SPF is checked against the envelope sender (Return-Path), not the From header.
- DKIM is checked against the
d=domain in the signature.
If a third-party sender uses its own Return-Path domain and its own d= domain, both checks can pass and neither will align with your From domain.
Find it in 2 minutes
Send a test message to a mailbox you control, open "Show original" and read Authentication-Results. Compare three values:
header.from=yourdomain.com
smtp.mailfrom=bounce.vendor.net <- SPF domain
header.d=vendor.net <- DKIM domain
If neither of the last two matches (or is a subdomain of, in relaxed mode) the first, DMARC fails.
Fix
- In the vendor's admin, enable the custom domain / "authenticate your domain" option so DKIM signs with
d=yourdomain.com. - Optionally set a custom return-path (CNAME) so SPF aligns too.
- Keep
p=nonewith anrua=report address while you confirm every sender aligns, then tighten.
Why it comes back
Alignment is per sender. A new tool, a changed vendor setting or a DNS edit can silently break it months later, and you only notice when mail starts landing in spam. Reading aggregate reports on a schedule is what catches this early.
Top comments (1)
The 'both pass, neither aligns' case catches a lot of teams after adding a transactional email provider. One extra check: in relaxed alignment a subdomain such as mail.example.com still aligns with example.com, so the fix is often just a custom DKIM domain rather than touching SPF. Rotating DKIM selectors also quietly break alignment if the vendor keeps signing with an old key, so the aggregate reports are worth reading after any DNS change, as you say. Starting at p=none with rua before moving to quarantine is the safest rollout..