A message can pass DMARC while SPF or DKIM fails. The immediate task is to identify the passing aligned path, then decide whether the other failure is an expected property of the route or a fault that leaves the service fragile.
Do not change a correct DMARC result merely to make every indicator green. Equally, do not use the pass as permission to ignore a broken signing service. A message-level outcome and the resilience of an entire sending system are different assessments.
Identify which path carried the result
DMARC uses the domain in the visible From address as its reference. A passing SPF identity or a passing DKIM signing identity can satisfy DMARC when the required alignment relationship holds. Use receiver-generated results within the trust boundary described by RFC 8601 §7.1. For DKIM, inspect every relevant signature, not just the first one shown by a mail client. The pass/fail rule is specified in RFC 9989, section 5.3.5.
The following cases are synthetic examples. Assume an applicable valid policy and exact domain matches wherever alignment is marked yes.
- Case: A; SPF: Fail; DKIM: Pass for the From domain; DMARC conclusion: Pass through DKIM
- Case: B; SPF: Pass for the From domain; DKIM: Fail; DMARC conclusion: Pass through SPF
- Case: C; SPF: Pass for an unrelated domain; DKIM: Fail; DMARC conclusion: Fail, because no passing path aligns
- Case: D; SPF: Fail; DKIM: One signature fails; another passes for the From domain; DMARC conclusion: Pass through the aligned signature
In your real investigation, replace these labels with the domains and trusted results from the actual received message. A provider's “authenticated” account status is not sufficient evidence of which route succeeded.
When SPF fails but DKIM survives
Forwarding can change the connecting source seen by the final receiver. That can disrupt SPF for the original envelope identity while an intact DKIM signature continues to verify. This is one reason to inspect the route before expanding SPF permissions. SPF forwarding considerations are discussed in RFC 7208, section 10.3.
First determine whether the affected message was sent directly or through an intermediary. Compare the direct and forwarded samples, including their envelope identities, receiving boundaries and DKIM results. If the aligned DKIM signature survives, the DMARC pass is explainable.
Do not authorise a broad set of forwarding systems in your domain's SPF simply to erase the failure. Such a change may not address the identity evaluated on the forwarded route and could unnecessarily enlarge sending authority. Record the route-specific explanation and investigate unexpected direct-mail failures separately.
When DKIM fails but SPF carries the message
A direct message may have a passing aligned SPF identity while its DKIM signature fails. Check the signing domain and selector, key availability, signature diagnostics and whether a gateway changed signed content under RFC 6376 §3.7. A signature failure alone does not prove message modification; key, signature-value and implementation problems are also possible. Compare samples taken before and after the suspected modification point where you are authorised to do so.
The DMARC pass does not make that DKIM failure harmless. A different route may not preserve the SPF path. A later infrastructure change may expose the dependency. Make the defect visible in the sender's operational record rather than hiding it behind an aggregate pass rate.
There is also a standards distinction: RFC 9989 states that domain owners must not rely solely on SPF for a DMARC pass when their policy is p=reject. That deployment requirement does not change the fact that a particular message can obtain a DMARC pass through SPF. See RFC 9989, section 8. Repair and verify aligned DKIM rather than treating the isolated pass as a complete rollout approval.
Distinguish DMARC from provider requirements
A receiving provider may impose requirements beyond the DMARC pass condition. For example, Google's guidelines require bulk senders to personal Gmail accounts to set up SPF, DKIM and DMARC, while direct mail must align through SPF or DKIM. These are related but separate checks. Review the current Gmail sender guidelines for the applicable sender category.
Do not promise delivery based on one authenticated message. Other requirements, reputation and content filtering still apply. If the reported problem is rejection, retain the exact SMTP response instead of assuming the failed authentication method caused it.
Decide whether to repair or document
Classify the finding with a specific action. An expected forwarding-related SPF failure with surviving aligned DKIM may need route documentation and monitoring. An unexplained DKIM failure on a direct production route needs an owner and repair plan. An unaligned pass needs identity configuration work, not merely a more permissive policy.
For each affected workflow, retain the observed successful path, the failing method's cause or open question, the supported correction and a retest through the same route. Exercise a representative message after any key, gateway or provider change. A successful test from a different application cannot close this workflow's issue.
Use the DKIM body-hash guide for message-modification investigations and the alignment failure guide when the passing identity is unrelated. The goal is a result you can explain and a sending route you can maintain.
Make the next decision explicit
For case A, document the forwarding explanation only when route evidence supports it; otherwise leave the cause open. For case B, assign DKIM repair without falsifying the message-level DMARC pass. For case D, retain the passing signature’s exact d= independently from the failing signature. These are analytical classifications, not observed incident outcomes.