What an SPF record is, and why it breaks.
SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are allowed to send email claiming to be from your domain. When a receiving server gets a message from "you," it looks up your SPF record and checks whether the sending server is on the list.
An SPF check sounds simple until your record starts pulling in Google Workspace, Microsoft 365, a CRM, a help desk, a marketing platform, and old mail vendors nobody remembers. At that point, the important question is not just whether a record exists. It is whether receivers can finish evaluating it.
Evaluating an SPF record can trigger further DNS lookups: every include, a, mx, ptr, exists mechanism and redirect modifier costs one. RFC 7208 caps this at 10 to bound how much work a receiver has to do. Cross it, and strict receivers stop evaluating your record entirely and return PermError, which can behave like having no SPF at all, just intermittently and without a friendly warning.
Every SaaS product you add for sending email, like a CRM, support desk, marketing platform, billing system, or newsletter tool, usually asks you to add its include: to your SPF record. Each one looks harmless on its own, but they stack, and each include can itself include more domains. Nobody removes old ones when a vendor gets dropped. The lookup count only ever grows.
The last mechanism in a record is usually all, and its qualifier decides what happens to mail from servers not on the list: -all (fail) rejects it, ~all (softfail) flags it as suspicious but usually still delivers it, and +all (pass) explicitly authorizes anyone: worse than publishing no SPF record at all.
SPF alone doesn't stop spoofing: it just tells receivers who's allowed to send. DKIM adds a cryptographic signature to messages. DMARC ties the two together, tells receivers what to do when a message fails both, and (if you turn on reporting) tells you who's actually sending mail as your domain, including senders you never authorized.
A useful SPF checker should do more than print the first TXT record it finds. It should count DNS-triggering mechanisms, follow nested includes and redirects, detect duplicate SPF records, flag syntax errors, explain risky policies, and show which services are consuming the DNS lookup budget.
See who is actually sending mail as your domain, catch spoofing, and move DMARC from monitoring to enforcement.
Analyze DMARC reports with MyDMARC →Get alerted when SPF, DMARC, MX, or other DNS records change before a vendor surprise becomes a mail problem.
Monitor DNS with OneDollarDNS →