SPF Record

We verify a domain’s entire mail setup, not just the mailbox, and SPF is one of the first things we read. It is a quiet line of DNS text that most senders publish once and forget, yet it decides whether the world believes a message really came from you. Here is what an SPF record is, how it works, how it sits alongside DKIM and DMARC, and where it tends to break.

How an SPF record works

SPF, short for Sender Policy Framework, is a single DNS TXT record published on the root of your domain. It enumerates the servers authorized to send email using your domain in the envelope sender. When a receiving server accepts a message, it reads the sending domain’s SPF record and compares the connecting IP against the authorized list. A match means the sender is recognized. No match means the message is handled according to the record’s policy.

Every record begins with the version tag v=spf1 and is built from mechanisms. An include delegates to another provider’s record (this is how you authorize a marketing platform or help desk), ip4 and ip6 name specific addresses, and a and mx authorize the hosts in those records. A domain may publish only one SPF record, so every sender has to be folded into that single line.

Hard fail, soft fail, and the all mechanism

The record ends with an “all” mechanism that catches every sender not explicitly listed, and the prefix on it is the whole game. -all is a hard fail: unlisted senders are declared unauthorized, and strict receivers reject their mail. ~all is a soft fail: unlisted senders are suspicious but usually still delivered, often to spam. A bare ?all is neutral and asserts nothing, so it offers no real protection. Most domains should run ~all while testing, then tighten to -all once every legitimate sender is covered.

The 10-lookup limit

SPF has a ceiling that surprises a lot of teams: evaluating a record may trigger no more than ten DNS lookups. Each include, a, mx, ptr, and redirect counts toward that budget, and because includes can nest, a single vendor can quietly consume several. Cross the limit and the evaluation returns a permerror, which most receivers treat as if there were no SPF record at all. It is one of the most common silent failures we see: a domain that added one vendor too many and broke authentication for every message without noticing.

SPF vs DKIM vs DMARC

SPF rarely works alone, and it is easy to confuse with its two companions. SPF verifies which servers may send for your domain. DKIM attaches a cryptographic signature to each message so a receiver can confirm the content was not tampered with in transit. DMARC sits on top of both: it tells receivers what to do when SPF or DKIM fails, requires the authenticated domain to align with the visible From address, and sends you reports so you can see who is sending as you.

They are layers, not options. SPF alone can be bypassed by forwarding and does nothing about tampering, which is the gap DKIM fills, and neither one enforces a policy or covers the visible From header, which is what DMARC adds. Inbox providers increasingly expect all three aligned, so we evaluate them as a set in the DMARC, DKIM, and SPF check rather than in isolation.

Why SPF matters for deliverability and anti-spoofing

SPF does two jobs at once. For anti-spoofing, it makes it far harder for an attacker to send phishing mail that forges your domain, because a forged message from an unlisted server fails the check. For deliverability, a passing SPF result is one of the first trust signals a mailbox provider weighs when choosing inbox versus spam. A missing or broken record, or a silent permerror, erodes sender reputation and can bury legitimate campaigns in junk.

Because SPF also underpins DMARC alignment, a misconfigured record quietly undermines the whole authentication stack, not just SPF itself. Confirming a domain’s records before you send is the cheapest deliverability win available, which is why our free email checker surfaces the domain’s mail configuration alongside each address it verifies.

Common SPF misconfigurations

Most SPF problems are not exotic. They are the same handful of mistakes repeated across thousands of domains, all avoidable once you know to look for them.

• Too many lookups. Stacking vendors pushes the record past the ten-lookup ceiling and triggers a permerror. Flatten the record or remove unused includes to stay under budget.
• Two SPF records. Publishing more than one v=spf1 TXT record is invalid. Receivers see the conflict and may ignore SPF entirely. Merge them into one line.
• A missing sender. Forgetting to include a marketing tool or help desk means its mail fails SPF even though it is legitimate.
• Ending in ?all or nothing. A neutral or absent “all” mechanism leaves the domain open to spoofing because no sender is ever rejected.
• The record on the wrong host. SPF belongs on the root domain in the envelope sender, not on a subdomain that never sends mail.

When we verify a domain’s mail setup, reading its SPF record alongside its MX records is part of judging whether it is a real, well-run mail host or a risky one. A clean, single, correctly terminated record under the lookup limit is a positive signal. The mistakes above are red flags. You can audit any domain’s full authentication, including its SPF value, with the mail domain lookup, and the volume tiers for verifying at scale are on the pricing page.