Why can DMARC fail when SPF and DKIM pass?
A message can show successful authentication and still fail DMARC. The results are not necessarily contradictory: a domain that authenticated successfully may be different from the domain the recipient sees in From. Put those identities next to each other and the mismatch becomes easier to find.
Identify the domain behind each result
SPF checks whether the connecting IP is authorized to use an identity such as the MAIL FROM domain. DKIM verifies a signature that associates a signing domain with the message. Neither result, by itself, guarantees a relationship with the visible From address.
Three places, three roles
SPF also supports HELO/EHLO checks, but DMARC uses the MAIL FROM identity for SPF alignment. The display name, Reply-To and DKIM selector s= are not the domains compared for alignment. See RFC 7208 §2, RFC 6376 §3.5 and RFC 9989 §4.4.
| Location | Example | Role |
|---|---|---|
| From header | news@example.com | The visible author; DMARC uses example.com as its reference |
| SMTP MAIL FROM | bounce@mailer.example.net | The envelope sender, normally also used for delivery-error returns |
| DKIM-Signature d= | example.com | The domain taking responsibility for the signature |
Alignment connects authentication to From
For a message with an applicable DMARC policy, either an SPF pass aligned with From or a DKIM pass aligned with From is enough for DMARC to pass. Both are not required. If a message has several DKIM signatures, one valid, aligned signature is sufficient.
Strict and relaxed alignment
The adkim and aspf tags select the modes separately; the default is relaxed. An Organizational Domain is not simply the last two labels. Current RFC 9989 §4.10.2 uses DNS Tree Walk discovery, replacing the Public Suffix List approach described in RFC 7489.
| Mode | Comparison | Example |
|---|---|---|
| Strict | The domain names match | From uses example.com and the authenticated domain is example.com |
| Relaxed | The Organizational Domains match | news.example.com and mail.example.com align if both resolve to the Organizational Domain example.com |
Compare three messages with the same From address
Assume From is news@example.com and a DMARC policy applies. These are actual authentication results established by a receiver, not text made trustworthy merely by including the word pass in a header.
From results to a DMARC verdict
The second row explains the apparently contradictory result. Authenticating a delivery-service domain is not enough on its own; the authenticated identity also needs the required relationship with the author domain.
| SPF | DKIM | DMARC interpretation |
|---|---|---|
| pass / mailer.example.net | pass / d=example.com | Pass through DKIM: its authenticated domain exactly matches From |
| pass / mailer.example.net | pass / d=example.org | Fail: neither authenticated domain aligns with From |
| fail | pass / d=example.com | Pass: aligned DKIM is enough even though SPF failed |
Forwarding and delivery policy add another layer
Forwarding changes the connecting sender and can change SPF results. DKIM can survive forwarding when the signed material is preserved, but a mailing list that modifies a signed subject or body may break it. A failure therefore needs the delivery path for context. RFC 7960 §3 describes these indirect-mail problems.
Policy is a handling preference
DMARC p=none, quarantine and reject express handling preferences for failures. A receiver can apply its own policy, so reject does not guarantee rejection, and pass does not guarantee inbox delivery. Authentication also does not establish that the links or message content are safe. Before tightening a policy, compare authorized senders, forwarding paths and aggregate reports to understand the effect on legitimate mail.
Separate DNS publication from message authentication
The Online Tools mail authentication checker sends the entered domain and selectors to the server and looks up DNS TXT/CNAME records. For example.com with selector s1, the key lookup name is s1._domainkey.example.com. Find the real selector in the sending-service settings or the s= tag of a message signature.
A published record does not establish a DMARC pass
This checker does not verify a received message, recursively evaluate SPF includes or discover the DMARC Organizational Domain. Its SPF lookup estimate counts visible terms only. Failure to find a key among common selector candidates does not prove DKIM is absent. Continue with reading mail headers to relate the published configuration to observations made by a receiver.
Current specifications and related reading
RFC 9989 §4.4 defines alignment and §5.3 covers receiver actions. RFC 9989 replaces RFCs 7489 and 9091; aggregate reporting is specified in RFC 9990, and failure reporting in RFC 9991. For changes that are not yet visible everywhere, read DNS TTL and caching.