DMARC Alignment Explained: Why SPF and DKIM Pass but DMARC Fails

Every email actually involves several domains, and DMARC's job is to referee between them. The first is the header From domain, the address a human sees in their mail client, and the one attackers forge. The second is the envelope From domain (also called return-path or MAIL FROM), a hidden address used for bounces, and the one SPF (Sender Policy Framework) checks. The third is the d= domain in the DKIM (DomainKeys Identified Mail) signature, whatever domain the sending system signed with.

SPF and DKIM each validate their own domain and know nothing about the others. Nothing in either protocol requires the domain they validate to be the domain displayed to the recipient. That gap is the loophole spoofers used for years: pass SPF and DKIM for a domain you control, display someone else's domain in the From line.

DMARC (Domain-based Message Authentication, Reporting and Conformance) closes the loophole with one rule: a message passes DMARC only if SPF or DKIM passes for a domain that aligns with the header From domain. SPF alignment means the envelope From domain matches the header From domain. DKIM alignment means the signature's d= domain matches the header From domain. One aligned pass is enough: you don't need both.

This is why raw pass/fail results can mislead. A DMARC report line reading 'SPF: pass, DKIM: pass, DMARC: fail' isn't a contradiction: it means both checks passed, but for domains other than yours.

Alignment comes in two modes, set per mechanism with the adkim (DKIM) and aspf (SPF) tags in your DMARC record. Relaxed is the default for both, and it's the right choice for almost everyone. Strict mode mainly exists for high-security domains that want to prevent even their own subdomains from authenticating as the parent.

The most common alignment failure by far: an email service provider (ESP, a tool like Mailchimp, SendGrid, or Brevo that sends on your behalf) signing with its own domain. Out of the box, a Mailchimp campaign shows your address in the From line but carries a DKIM signature for a Mailchimp domain such as mailchimpapp.net, and uses a Mailchimp bounce domain for SPF. Both checks pass; neither aligns; DMARC fails. The fix is the service's domain authentication setup: a few CNAME records that let it sign as your domain.

The second common case is forwarding. A forwarded message loses SPF alignment (the forwarder's server sends it, with its own envelope domain) but usually keeps DKIM alignment, so it still passes DMARC, unless the forwarder modified the message and broke the signature, which is typical of old-style mailing lists.

The third is internal systems (scan-to-email copiers, monitoring alerts, CRM notifications) sending with your domain in the From line but no DKIM signature and an unaligned envelope. These show up as steady, low-volume failures from IP addresses you own or rent, and they're the long tail that keeps domains stuck at p=none.

DMARC aggregate reports show, for every sending source, which domain SPF passed for and which domain DKIM signed with, which makes unaligned senders easy to spot once the data is readable. A source whose DKIM domain is an ESP's own domain rather than yours is an alignment fix waiting to happen: complete that ESP's custom-domain setup and the source flips to passing.

This sender-by-sender cleanup is the real work of a DMARC rollout, and it's the part DMARCPath is built around: it groups report data by sending service, flags exactly which senders are unaligned and why, and tells you when everything legitimate is aligned so you can tighten your policy safely.