How it works
An SPF record is a TXT record on the domain itself that starts with v=spf1, for example v=spf1 ip4:203.0.113.10 include:_spf.google.com -all. Mechanisms such as ip4, ip6, a, mx and include name the servers that are allowed to send for the domain.
The receiving server takes the domain of the envelope sender (the Return-Path you see in the headers), looks up its SPF record and checks whether the connecting IP address is covered. The all mechanism at the end decides what happens to every other server: -all means fail, ~all softfail, ?all neutral, and +all lets anyone send.
Every include, a, mx, ptr, exists and redirect costs one DNS lookup, including the ones nested inside your providers’ includes. More than 10 of them, or more than one SPF record on the same domain, results in a permanent error (permerror) at the receiver, and SPF counts as failed.
SPF does not look at the From address shown in the mail client. Only DMARC ties the SPF result to the visible sender.
Why it matters
Without SPF, or with +all or ?all, any server can deliver mail with your domain in the return path and the receiver has no technical reason to reject it. Gmail, Yahoo and Microsoft now require SPF or DKIM from senders; without either, even legitimate mail ends up in spam or bounces.
A broken record is more common than a missing one: a second SPF record added for a new newsletter tool, a typo in an include, or the eleventh lookup caused by one more service. At that point SPF fails for every message from the domain, often unnoticed until clients start asking why their mail lands in spam.
How to prevent it
- Keep exactly one v=spf1 TXT record per domain and add new sending services to it instead of publishing a second record.
- End the record with -all once every legitimate sender is listed; use ~all only during the transition.
- Count lookups before adding another include, remove services you no longer use, and list fixed servers as ip4 or ip6 instead.
- Protect domains and subdomains that never send mail with v=spf1 -all.
- Do not use the ptr mechanism; RFC 7208 explicitly discourages it.
- After every change, send a test message through each sending path (mailbox, shop, contact form, newsletter) and check the SPF result.
How DomainWarn detects it
The SPF check queries the domain’s TXT record, parses it and follows every include all the way down. It reports a missing record, multiple SPF records (critical, because receivers return permerror), syntax errors, includes without an SPF record, includes that do not resolve or loop back on themselves, and more than 10 DNS lookups; 9 or 10 lookups trigger a hint. A record ending in +all, ?all or with no all at all is flagged as too permissive, ~all is a hint and the ptr mechanism a warning.
These findings open incidents such as “SPF missing”, “Multiple SPF records”, “SPF invalid”, “SPF: too many lookups” and “SPF too permissive”. Change detection also reports when the record is changed, weakened or removed, and a removed SPF record is a critical change. On a subdomain, a missing record is only a hint.
If a domain exceeds the lookup limit, DomainWarn can flatten the record into ip4 and ip6 ranges and keep it current. Whether a specific message actually passes SPF is shown by the mail test.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.