Read any domain's live SPF record and see exactly which services are authorised to send its mail, what happens to everything else, and whether the record is broken in a way no DNS panel shows you.
Type a domain. This reads its live TXT records, finds the SPF policy, names the sending providers it authorises and shows the raw record. It also flags the two failures that are invisible from a DNS panel: duplicate SPF records and a +all qualifier. Runs against Cloudflare's public resolver. Nothing is stored, nothing is sent to us.
The tool above queries the TXT records published at your domain's apex and picks out the one that starts with v=spf1. That single string is your entire SPF policy. It names every server allowed to send mail using your domain, and it ends with an instruction about what a receiver should do with everything else.
Reading it yourself takes about a minute once you know the shape.
Take a typical one:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
The version tag comes first and is always v=spf1. Then come mechanisms, evaluated left to right. An include: pulls in another domain's SPF record wholesale, which is how you authorise Google Workspace or SendGrid without listing their IP ranges yourself. An ip4: or ip6: authorises a specific address or range directly. The bare mechanisms a and mx authorise whatever your A record and your MX hosts point at, which is convenient and almost always unnecessary.
The record ends with an all mechanism carrying a qualifier, and that qualifier is the part people get wrong.
~all is soft fail. A receiver that sees mail from an unlisted server marks it as suspicious but usually still delivers it. This is the sensible default while you are still discovering which services send on your behalf.
-all is hard fail. Mail from an unlisted server should be rejected. This is where you want to end up, but only once you are certain you have enumerated every sender, including the invoicing tool, the helpdesk, the newsletter platform and whatever the marketing contractor set up two years ago.
?all is neutral and means nothing at all. It is functionally the same as publishing no policy.
+all authorises the entire internet to send as your domain. It is the single worst value you can publish, strictly worse than having no SPF record, because it converts an absence of information into an explicit endorsement. It appears almost exclusively by accident, usually copied from a broken tutorial.
SPF caps the number of mechanisms that trigger a DNS lookup at ten. That count includes every include, a, mx, ptr, exists and redirect, and it counts recursively: an include that itself contains three includes costs you four.
This is where the trap sits. A single include:_spf.google.com costs three or four lookups on its own. Add a marketing platform, a transactional sender and a helpdesk and you are at the ceiling without the record looking remotely long. Past the tenth lookup, evaluation stops and returns a permanent error, which most receivers treat as a failure. Senders you believe are authorised silently are not, and nothing in your own inbox tells you.
The fix is usually to remove a and mx, which are rarely needed, and to drop includes for services you no longer use.
RFC 7208, section 4.5, is unambiguous. If a domain returns more than one record beginning v=spf1, evaluation terminates with a permanent error. Receivers do not pick the first one. They do not merge them. The check simply fails.
This happens constantly, and the mechanism is always the same: someone adds a second sending platform, the vendor's setup guide says "add this TXT record", and they add it as a new row rather than editing the existing one. Both records now sit at the apex, each looking perfectly correct in isolation, and every DNS panel in the world displays them as two healthy entries.
When we audited 156 lead generation agencies, four of them were in exactly this state. These are companies that send cold email for a living.
The fix is to merge the includes into one record and delete the other.
SPF authenticates the envelope sender, the address used during the SMTP conversation, not the From address your recipient actually sees. On its own it does nothing to stop someone displaying your domain in the visible From line. That is what DMARC alignment is for, which is why SPF alone is never the whole answer.
SPF also breaks on forwarding. When a message is forwarded, the forwarding server becomes the sender and is usually not in your record, so SPF fails through no fault of yours. DKIM survives forwarding where SPF does not, which is the main argument for having both.
Once SPF is clean, check the other two layers: the DKIM record checker looks for your signing keys, and the DMARC record checker reads your policy and tells you whether it is enforcing anything. The full SPF, DKIM and DMARC guide covers how the three fit together, and the deliverability checker audits your wider setup.