ModeesA green tick beside SPF feels like proof that authentication is done. It is not. SPF answers a narrow question — did this message come from an IP the envelope domain allows? — and the envelope domain is usually not the domain your subscriber sees.
That gap is where a campaign can pass every check in a DNS tool and still land in spam.
What SPF actually authenticates
SPF is published on a domain and lists the IP addresses allowed to send for it. The receiver checks the IP against the domain in the SMTP MAIL FROM (the return path), not the From: header.
An email platform typically sends with a return path on its own domain, something like bounce.mailplatform.example, while the visible From is hello@youragency.example. SPF passes for the platform's bounce domain. Everything about your domain is still unproven.
That is not a failure by itself, because DMARC can accept either SPF or DKIM — but only when the authenticated domain aligns with the From domain. If the return path is the platform's domain and DKIM signs the platform's domain too, DMARC has nothing that belongs to you.
The two-minute test
Open a real message, not a preview, and look at three things:
- Return-Path: the domain in it is the one SPF authenticated.
- Authentication-Results: the header added by the receiving mailbox provider. It records
spf=,dkim=anddmarc=with the domains that were checked. - DKIM-Signature: the
d=value is the signing domain. It must be your domain, or a subdomain of it under relaxed alignment.
If spf=pass names the platform and dkim=pass d=mailplatform.example while your From is youragency.example, DMARC is failing even though two green ticks are visible in a checker that tests each record separately.
A checker that asks only "is there an SPF record?" cannot see this. A checker that asks "does this message align?" can.