What Is SPF and How to Set It Up Correctly
A practical guide to Sender Policy Framework (SPF): how the record works, how to build one for your domain, common mistakes, and how to verify it.
By the DNSLab team Updated July 9, 2026
Quick answer
SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are allowed to send email for your domain, so receiving servers can reject forged messages. To set it up, publish a single TXT record at your domain root, such as v=spf1 include:_spf.google.com ~all, listing every service that sends on your behalf and ending with ~all (softfail) or -all (hardfail).
What SPF actually is
SPF (Sender Policy Framework) is a DNS-based mechanism that lets a domain owner declare which mail servers are allowed to send email using that domain in the envelope sender address. You publish a single TXT record on your domain, and receiving servers read it when a message arrives. If a message claims to come from your domain but originates from an IP that your record does not authorize, the receiver can treat it as suspicious. SPF does not encrypt mail or scan content; it only answers one question: was this server permitted to send for this domain? It is one of the three pillars of email authentication alongside DKIM and DMARC.
Why SPF matters for deliverability
Without SPF, anyone can forge your domain in the From line and mailbox providers have no reliable way to tell your real mail apart from spoofed messages. That hurts you twice: spammers can send phishing that appears to come from you, and your legitimate newsletters or transactional email are more likely to land in spam. Gmail, Outlook, and Yahoo now expect authentication for bulk senders, and a missing or broken SPF record is a common reason mail is rejected outright. A correct record improves inbox placement, protects your brand reputation, and is a prerequisite for enforcing a DMARC policy later.
How an SPF check works
When a receiving server accepts a connection, it looks at the envelope sender domain (the MAIL FROM address, also called the Return-Path). It queries that domain's TXT records for one starting with v=spf1, then evaluates the mechanisms left to right. Each mechanism, such as ip4, ip6, a, mx, or include, either matches the connecting IP or does not. The first mechanism that matches decides the result: pass, fail, softfail, or neutral, based on the qualifier in front of it. The record ends with an all mechanism that catches everything else. Crucially, SPF checks the envelope domain, not the visible From header, which is why DMARC is needed to tie them together.
Building your SPF record step by step
Start by listing every source that sends mail as your domain: your own mail server, your web host's outgoing relay, and third parties like Google Workspace, Microsoft 365, SendGrid, or Mailchimp. Most providers publish an include value for you to use. A typical record looks like: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all. Use include for services, ip4 or ip6 for servers you control by address, and choose an ending: ~all (softfail) while testing, or -all (hardfail) once you are confident every legitimate source is listed. Publish it as a single TXT record at the root of your domain, never as an SPF-type record.
Common mistakes to avoid
The biggest pitfall is the ten-DNS-lookup limit: every include, a, mx, ptr, and exists mechanism costs a lookup, and exceeding ten causes a permerror that fails the whole check. Consolidate providers or use flattening if you approach the limit. Never publish more than one v=spf1 TXT record on a domain; two records is an automatic permerror. Do not use ptr, which is slow and deprecated. Avoid ending with +all, which authorizes the entire internet. Also remember SPF does not survive most forwarding, and it only protects the envelope domain, so subdomains and the visible From address need their own coverage plus DMARC.
Verifying your record with dnslab tools
After publishing, wait for DNS to propagate, then confirm the record resolves correctly. The dnslab SPF tool parses your record, counts DNS lookups so you can catch the ten-lookup limit before it bites, and tells you how a given sending IP would be evaluated. Pair it with the DMARC tool to check your policy and alignment, and the Blacklist tool to make sure your sending IPs are not listed on major RBLs. Use the WHOIS tool to confirm you are editing the right zone and to see the authoritative nameservers. Re-test whenever you add or remove an email provider, since a forgotten include is a frequent cause of silent delivery failures.
Frequently asked questions
- Can I have more than one SPF record?
- No. A domain must have exactly one TXT record beginning with v=spf1. If a receiver finds two, SPF returns a permerror and the check fails entirely. When you add a new sending service, merge its include or ip4 value into your existing record rather than publishing a second one.
- What is the difference between ~all and -all?
- Both mark unlisted senders as unauthorized, but the receiver reacts differently. ~all (softfail) says the mail is probably not legitimate, so it is often accepted but flagged. -all (hardfail) says it is definitely not authorized, so receivers may reject it. Use ~all while testing, then switch to -all once every valid source is covered.
- Do I still need DKIM and DMARC if I have SPF?
- Yes. SPF only validates the envelope sender and often breaks when mail is forwarded. DKIM adds a cryptographic signature that survives forwarding, and DMARC ties SPF and DKIM to the visible From address while telling receivers what to do on failure. All three together give you real spoofing protection and reporting.