A message does not need both SPF and DKIM to produce a message-level DMARC pass. It needs at least one qualifying path: SPF must pass and align, or at least one DKIM signature must pass and align.
That rule is easy to oversimplify. A message-level pass is not the same as a complete domain-authentication deployment. It also does not override separate mailbox-provider requirements that may expect senders to configure both SPF and DKIM. Keep the protocol result, the sending programme and provider requirements as three separate decisions.
Apply the Boolean rule correctly
For a well-formed message with an applicable valid policy and completed checks, RFC 9989 §5.3.5 gives the message-level validation rule:
DMARC pass =
(SPF passes AND SPF identity aligns)
OR
(a DKIM signature passes AND its d= domain aligns)The word OR matters. Either branch can satisfy the message-level condition. The word AND matters inside each branch. A raw authentication pass without alignment does not satisfy it.
Alignment compares the authenticated domain with the Author Domain in From. Strict mode requires exact equality under RFC 9989 §3.2.10.2. Relaxed mode uses the discovery relationship in RFC 9989 §4.10.2.
Compare the three essential cases
The following fictional examples use From orders@example.com. They are synthetic teaching cases, not captured customer traffic.
- Case: A; SPF: Pass for example.com, aligned; DKIM: Fail; DMARC result: Pass; Reason: The SPF branch qualifies
- Case: B; SPF: Fail; DKIM: Pass with d=example.com, aligned; DMARC result: Pass; Reason: The DKIM branch qualifies
- Case: C; SPF: Pass for vendor.example.net, unaligned; DKIM: Pass with d=vendor.example.net, unaligned; DMARC result: Fail; Reason: Neither branch qualifies
Case A shows why a DKIM failure does not automatically mean DMARC failure. Case B shows why forwarding that disrupts SPF can still leave an aligned DKIM path. Case C shows why two green raw results can still produce DMARC failure.
Do not read these examples as design targets. Depending only on the envelope path can be fragile when messages are forwarded. Depending only on DKIM can be fragile when intermediaries modify signed content. Resilience usually comes from configuring both mechanisms correctly, then verifying how real messages behave.
Distinguish validation from full participation
Message-level validation answers whether the received message has at least one passing aligned path. A mature domain programme asks broader questions: are legitimate messages consistently covered, are both mechanisms deployed as required, is policy appropriate, are reports reviewed, and do operational owners fix exceptions?
RFC 9989 also defines full participation for a domain more broadly than a single message's validation result. In particular, a domain publishing reject MUST NOT rely solely on SPF and MUST apply valid DKIM signatures under RFC 9989 §7.4. Full participation is specified in RFC 9989 §8. Do not turn the message-level OR rule into advice that one mechanism can be ignored across the organisation.
The same distinction matters when a mailbox provider publishes sender requirements. For example, Google’s sender guidelines require SPF, DKIM and DMARC setup for bulk senders to personal Gmail accounts. A provider may require both SPF and DKIM to be configured for a sender category even though DMARC validation for a particular message still uses the aligned-path rule. Failure to meet the provider's separate requirement cannot be argued away by citing the DMARC Boolean expression.
Diagnose the failing branch before changing policy
When a legitimate message fails DMARC, capture:
- Evidence: From domain; Question: Which Author Domain is being protected?
- Evidence: SPF result and evaluated domain; Question: Did the envelope path pass, and was it aligned?
- Evidence: Each DKIM result and d= domain; Question: Did any signature pass and align?
- Evidence: Alignment modes; Question: Was strict or relaxed comparison applied?
- Evidence: Trusted receiver result; Question: Where was the conclusion produced?
Then repair the branch the sender is meant to use. For SPF, that might involve a custom envelope domain and authorised sending path. For DKIM, it might involve enabling signing with the organisation's domain and verifying a representative received message. Do not weaken policy simply because the identity table has not yet been assembled.
Understand indirect mail
As described in RFC 7208 §10.3, forwarding often changes the connecting source, so SPF can fail at the final receiver even though it passed earlier. A surviving aligned DKIM signature may still provide a qualifying path. Changes to signed content can invalidate DKIM under RFC 6376 §3.7, while other intermediary behaviour can affect both paths.
DMARC does not guarantee that every legitimate indirect flow will preserve a qualifying path. Evaluate the actual route, receiver evidence and business need. A receiver can also apply local policy and other evidence when deciding disposition.
Avoid four common conclusions
First, do not say that both SPF and DKIM must pass for every message to pass DMARC. That is not the message-level rule.
Second, do not say that one mechanism is sufficient for the entire sending estate. A single passing example does not establish coverage, resilience or full participation.
Third, do not equate pass with inbox placement. Authentication is one input to receiving decisions.
Fourth, do not equate failure with proven fraud. A legitimate service can be misconfigured, while an attacker-owned domain can authenticate its own mail.
Use the email identity-chain guide to collect the evidence and the SPF, DKIM and DMARC guide to place the result in the wider programme.
Keep the conclusion within the evidence
For the Boolean fixture, evaluate each branch as pass AND aligned before combining them with OR. A signature that fails cannot borrow alignment from another signature, and an SPF pass cannot borrow another domain’s alignment. If required DNS checks fail to complete, RFC 9989 §5.3.6 separates that error from a normal pass/fail result. No actual verifier was run.