An SPF pass and a DMARC fail can both be true: here’s why
Suppose a message displays billing@example.com in From but uses bounce.vendor.example as its envelope sender. The vendor’s sending IP can be authorised by the SPF record for bounce.vendor.example. SPF passes for that identity. The result does not automatically authenticate example.com.
The useful reframe is to stop treating authentication as three lights attached to a domain. SPF evaluates an SMTP identity and connecting host. RFC 7208 defines SPF around MAIL FROM and, in some cases, HELO identities. RFC 7208 DMARC evaluates the visible From domain and looks for a passing aligned SPF or DKIM result. RFC 9989
Therefore ‘spf=pass’ and ‘dmarc=fail’ are not contradictory. The message may authenticate the vendor’s bounce domain perfectly while presenting your business domain to the reader. Diagnosis begins with the identities in one message, not with a generic DNS report for the domain you expected.
This is the single most useful reframe in email authentication: SPF authenticates an SMTP identity and the host that connected, while DMARC judges the domain a person actually sees in From. A supplier can pass SPF for its own bounce domain while presenting your business name: so both results are accurate at once. Recognising that ends an entire category of confusion and points you to the real fix, which the alignment guide explains in detail.
Collect the receiver’s trusted authentication result
Use a delivered message from the affected application to a mailbox you control. Open its raw original and find the Authentication-Results field added by the receiving service. RFC 8601 defines this field and its authentication service identifier. RFC 8601
Copy the SPF method, result and property, often shown as smtp.mailfrom. Copy the DMARC result and header.from domain. Also retain DKIM results because an aligned DKIM pass could satisfy DMARC even when SPF does not. Record the receiving service, UTC time, message ID and sending feature.
Do not trust an arbitrary lower Authentication-Results line merely because it says pass. Results matter within the administrative boundary that produced them, and untrusted mail can contain header-like text. Identify which field your receiver added.
Headers can expose addresses, IPs and internal routing. Keep the full original restricted. In a ticket, share only the redacted result lines, required domains and event identifiers. If no message delivers, use the full bounce and ask the sending provider for the event’s envelope domain and authentication evidence.
A trusted receiver result taken from a real delivered message beats any dashboard badge, because it shows the actual identities in play. If you are new to reading these, the email headers guide walks you through the fields that matter and how to interpret them safely.
Write down the three identities before you change anything
Create a small note containing: visible From domain; SPF-authenticated MAIL FROM or HELO domain; DKIM d= domain if present. Preserve subdomains. Do not shorten bounce.eu.vendor.example to the supplier’s brand name or replace it with the address customers see.
SPF pass means the connecting IP matched the published policy for the evaluated SPF identity. It does not identify the human author, guarantee message integrity or say that the visible From address is authorised. Those limits are part of why DMARC adds an alignment comparison.
For DMARC, relaxed SPF alignment compares organisational domains, while strict SPF alignment requires exact domain equality, as specified by RFC 9989. DMARC identifier alignment A custom return path under your organisational domain may align in relaxed mode. An unrelated supplier domain will not. If strict mode is configured, even a related subdomain can fail SPF alignment.
Record the domain names first, then consult the active DMARC policy’s alignment mode. Guessing from a provider badge can hide the exact mismatch.
The mirror case is a valid DKIM signature that does not align, which needs the same domain-by-domain comparison.
Identify which system chose the envelope sender
Name the application and feature that produced the message. A finance platform, marketing service, help desk and website can each choose a different return path while sharing the same visible address. Check the provider event and application settings for custom bounce domain, return-path or MAIL FROM options.
Query SPF for the exact authenticated domain recorded by the receiver. Confirm there is one valid policy and that the observed IP is authorised through the mechanism the provider documents. This verifies why SPF passed; it does not repair alignment. If the authenticated domain belongs to the supplier, you may not control its SPF record and should not try to reproduce it under your root domain.
Ask who controls DNS for your domain and who owns the application account. Alignment fixes often need both: one publishes a CNAME or TXT record, while the other verifies and activates a custom domain in the service.
Stop if the sending feature is unknown, the SPF identity is not associated with an approved supplier, or no owner can confirm the message. Do not authorise an IP or domain simply because it appears in a passing result. Unexpected traffic may be misuse rather than a forgotten legitimate sender.
Which system chose the envelope sender is usually the key question, and the answer often lives in one application’s settings: a marketing service, finance platform or help desk can each pick a different return path while sharing the same visible address. When the fix needs an aligned return path, the practical stage work belongs in the SPF repair guide; when an aligned DKIM signature is the better route, see why DKIM can pass while DMARC fails.
Choose an aligned path the service actually supports
One option is a custom return-path or MAIL FROM domain beneath your own organisational domain. The service may ask for DNS records that delegate bounce handling while preserving an aligned identity. Confirm the exact hostname, account and region in the provider’s current instructions.
Another option is aligned DKIM. If the service signs with your domain or an aligned subdomain and the signature passes, DMARC can succeed even if SPF passes only for an unrelated supplier domain. This can be preferable where forwarding later changes the connecting route, although message modification can break DKIM.
The trade-off is ownership and resilience. Custom SPF alignment makes the bounce identity visible and can be straightforward, but depends on the forwarded or final connecting host. Custom DKIM ties validation to signed content and survives ordinary relaying when content remains intact, but requires key and selector lifecycle management. Many services support both, which provides better diagnostic resilience.
Do not change the visible From address to a supplier domain merely to obtain alignment unless that address is genuinely controlled, monitored and appropriate for recipients. Do not weaken DMARC policy to conceal one route’s mismatch.
Publish the supported configuration without breaking working mail
Take a DNS snapshot and check requested names for existing records. If the provider needs an SPF policy at a custom return-path domain, publish it at that exact name. Do not add its include automatically to the root-domain SPF record unless the root domain is actually the MAIL FROM identity for that route.
RFC 7208 permits one SPF policy for a DNS name and limits terms that cause DNS queries. SPF record rules Never create a second v=spf1 record. Follow include chains when validating the complete policy. Avoid copying raw shared IP addresses unless the provider explicitly supports that stable configuration and ownership is recorded.
For custom DKIM, publish the account-specific selector record without overwriting another sender. Then return to the application to complete verification and enable signing. DNS publication alone may not switch the route.
Record the previous and new values, TTL, approver, activation state and rollback. The narrowest supported change is safer than restructuring authentication for every sender at once.
Verify a new message, not merely the DNS record
Wait until the intended public DNS answer is visible and the service reports the custom domain active. Send one non-sensitive control through the same application, account, From address and message feature to the same receiving service used for the evidence.
Open the receiver’s raw original. Record SPF result and smtp.mailfrom, DKIM result and header.d, DMARC result and header.from. The repair is proved when at least one passing identity aligns under the domain’s configured mode and the receiver reports DMARC pass. An SPF pass alone is not the acceptance criterion.
Compare reply handling, bounce processing and the application event too. A custom return path that aligns but prevents the supplier from handling bounces is not a complete repair. Send a separate control through an important existing route to detect collateral DNS damage.
If the result remains DMARC fail, compare the new identities with the original. Check whether the provider activated a different account, whether strict alignment applies, whether DNS was published at the wrong name, or whether the test accidentally used another feature.
Stop when ownership or identity evidence runs out
Escalate to the service provider if it shows ‘authenticated’ but the receiver still reports its unrelated envelope domain and no aligned DKIM pass. Provide the UTC event time, redacted receiver results, visible From domain, SPF identity, DKIM signer, selector, DMARC alignment mode and relevant public DNS answers. Ask the supplier to reproduce the event from its outbound logs and state which custom MAIL FROM value that specific account should emit. Compare its answer with the next receiver result rather than accepting a screenshot from the setup screen. If the supplier claims alignment through SPF, require the exact envelope domain; if it claims DKIM, require the expected signing domain and selector.
Escalate internally if a DNS request would overwrite an unknown record, the domain has several business-critical senders, or strict alignment was enabled without an owned compatibility review. Stop normal changes if the message was not authorised, credentials may be compromised or testing would expose sensitive customer data.
Do not chase a cosmetic DMARC pass by lowering policy, switching to a misleading From address or adding every observed IP. Those changes broaden risk while leaving the route’s ownership unclear. Keep the failing example and one controlled result so a specialist can reproduce the comparison.
The apparent puzzle disappears when the identities are named: SPF authenticated one envelope domain, while DMARC evaluated the domain a recipient saw. Repair connects those identities through a supported custom return path or aligned DKIM, and same-route evidence proves that connection.
Sources and further reading
- RFC 7208: Sender Policy Framework
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance
- RFC 8601: Message Header Field for Indicating Message Authentication Status