An SPF pass answers whether a sending IP was authorized for the evaluated SPF identity. DMARC asks an additional question: does that authenticated identity align with the domain in From? An aggregate report can therefore show raw SPF pass and an SPF-related DMARC failure without contradicting itself.
Identify the domain SPF authenticated
References: RFC 9990 §3.1.1.13, RFC 7208 §2.4, RFC 9989 §4.4.2.
Read auth_results/spf/domain and result together. Inspect identifiers/header_from, any envelope_from and the reported scope. Do not assume SPF checked the visible From domain. RFC 7208 defines the MAIL FROM identity, while RFC 9989 uses that identity for SPF's contribution to DMARC.
For a null reverse-path, SPF defines a MAIL FROM identity using postmaster at the HELO domain. That special case should not become a rule that any independent HELO pass satisfies DMARC. Current RFC 9990 reporting permits mfrom as the SPF scope; legacy report formats may expose different fields and need explicit interpretation.
Apply the correct alignment mode
References: RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
Strict SPF alignment requires the authenticated domain to exactly match the author domain. Relaxed alignment permits the relationship defined through the applicable organizational-domain rules. Do not calculate it merely by removing a fixed number of labels: public-suffix and policy-discovery details matter.
The SPF value under row/policy_evaluated expresses the DMARC-related result, not a duplicate of the raw SPF result. A raw failure or error cannot become a successful SPF path just because the domain names resemble each other. Authentication must succeed as well as align.
Work through two contrasting rows
References: RFC 9989 §5.3.5.
Assume applicable valid policies, completed checks and unrelated organizational domains for brand.example and vendor.example. Synthetic row A uses header_from=brand.example, MAIL FROM=vendor.example and raw SPF=pass. The unrelated identity does not align, so policy_evaluated/spf=fail is expected. Adding a vendor IP to brand.example's SPF does not change the identity that this route actually evaluates.
Synthetic row B uses header_from=brand.example and MAIL FROM=bounce.brand.example with raw SPF=pass. Assume the applicable organizational-domain discovery places them together. Relaxed SPF alignment can pass, while strict SPF alignment fails because the names differ. These are illustrative field fixtures, not observed traffic.
For either row, inspect aligned DKIM before concluding that DMARC as a whole failed. A passing aligned DKIM signature can provide the successful DMARC path independently of SPF.
Choose a repair that changes the failed layer
References: RFC 7208 §10.3.
If raw SPF fails, investigate authorization and the connecting path for the actual evaluated domain. If raw SPF passes but does not align, investigate a supported custom MAIL FROM configuration or another aligned authentication path. Do not keep adding IPs to an unrelated domain's SPF record.
Confirm changes with controlled received mail and later reporting evidence, preserving both raw and aligned results. Forwarding can change the connecting IP, so test relevant routes and avoid treating SPF alone as a guarantee of delivery. Close the investigation with the evaluated identity, alignment mode and demonstrated result.
Preserve the raw-to-aligned test cases
Four partial synthetic maps share header_from=brand.example, policy p=reject and epoch interval 1704067200–1704153600. A uses MAIL FROM=vendor.example with raw SPF pass and no DKIM signatures: aligned SPF and DMARC fail. B uses MAIL FROM=bounce.brand.example with raw SPF pass and no DKIM: under an explicitly assumed shared organizational domain, relaxed mode passes SPF alignment and DMARC. The same B input under strict mode fails both. A fourth case restores A's unrelated SPF identity but adds passing DKIM for brand.example/selector billing1: DMARC passes through DKIM.
The supplied local identity exercise reproduces all four outcomes from the supplied identities, results and alignment modes. It uses an explicit organizational-domain map, not a DNS tree-walk implementation. It also does not test a real null reverse-path message; the null-path guidance above is specification-based. Actual provider and receiver behavior still needs received-message evidence.
Keep the exercise within scope
The examples are partial field projections, not schema-valid reports or measured traffic. Local checks use explicitly supplied authentication results and organizational relationships; they do not perform DNS discovery, SPF evaluation, cryptographic verification, report ingestion or receiver delivery tests. Preserve the original report and trusted message evidence before making a production change.