What is
SPF?
SPF (Sender Policy Framework) is a DNS-based email authentication protocol that lets domain owners publish which IP addresses and servers are authorized to send email on their behalf — and tells receivers to reject everything else.
IP-based sender authorization in three steps
SPF lets you declare which servers are allowed to send email for your domain. Receivers check every incoming message against your published list.
Sender Sends
An email server initiates an SMTP connection to deliver a message claiming to be from your domain. The connecting server's IP address is recorded by the receiving server.
Receiver Checks SPF
The receiving server queries DNS for your domain's SPF TXT record. It retrieves the list of authorized IP addresses, includes, and mechanisms you have published.
Pass or Fail
The connecting IP is compared against the SPF record. If it matches an authorized mechanism, the result is Pass. If not, the result depends on your all qualifier: hard fail, soft fail, or neutral.
What an SPF record
looks like in DNS
An SPF record is a single DNS TXT record published at your domain apex. It starts with v=spf1 and lists every authorized sender using mechanisms like include:, ip4:, and ends with an all qualifier.
- A domain can have exactly one SPF record (multiple records cause PermError)
- The record must start with v=spf1 as the first mechanism
- Each include: mechanism costs 1+ DNS lookups toward the 10-lookup limit
- ip4: and ip6: mechanisms do not count as DNS lookups
- The all mechanism must be last and defines the default action
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"
v=spf1 include: ip4: -all include:_spf.google.com include:sendgrid.net include:spf.mailchimp.com include:spf.hubspot.com include:spf.freshdesk.com
Why SPF breaks at
10 DNS lookups
RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS mechanism lookups. This prevents SPF records from being used as a DNS amplification vector. Each include, a, mx, redirect, and exists mechanism triggers a DNS lookup. Organizations using 4-5 email services commonly exceed this limit.
SPF flattening replaces include: mechanisms with resolved IP addresses, eliminating DNS lookups. AutoSPF — our sister product — handles flattening automatically and re-scans every 15 minutes to catch provider IP changes.
The building blocks of an SPF record
Each mechanism defines a rule for matching sender IP addresses. Mechanisms are evaluated left-to-right until a match is found.
ip4 / ip6 Authorizes specific IPv4 or IPv6 addresses or CIDR ranges. Does not count toward the 10-lookup limit because no DNS query is needed.
ip4:203.0.113.0/24 include Delegates authorization to another domain's SPF record. The receiver fetches and evaluates that record. Each include costs 1+ DNS lookups.
include:_spf.google.com a Authorizes the IP addresses returned by the A or AAAA record of the specified domain. Costs 1 DNS lookup.
a:mail.example.com mx Authorizes the IP addresses of the domain's MX (mail exchange) servers. Costs 1 DNS lookup plus additional lookups for MX resolution.
mx redirect Replaces the current SPF record entirely with another domain's record. Used when one domain's sending policy is identical to another.
redirect=_spf.example.com all Matches every IP not caught by previous mechanisms. Always appears last. The qualifier (+, -, ~, ?) determines what happens to unmatched senders.
-all What +, -, ~, and ? mean for delivery
Qualifiers prefix any mechanism to control the result when that mechanism matches. The qualifier on your all mechanism is the most important — it defines what happens to every unlisted sender.
The IP is authorized. This is the default qualifier if none is specified. Rarely written explicitly.
+all (same as all) The IP is NOT authorized. Receivers should reject the message. Strongest enforcement signal.
-all The IP is probably not authorized. Receivers should accept but mark as suspicious. Safe for initial deployment.
~all No assertion about the IP. The SPF result provides no information. Rarely used in practice.
?all Common SPF issues and how to fix them
Most SPF failures come from lookup limits, missing senders, or configuration errors that are easy to catch with the right tools.
Too Many DNS Lookups
Your SPF record exceeds the 10-lookup limit from RFC 7208. Every include, a, mx, redirect, and exists counts. Use SPF flattening or AutoSPF to resolve IPs statically.
Missing Sending Sources
A legitimate email service is not listed in your SPF record. Common after adding new services like marketing tools, CRMs, or support desks. Check aggregate DMARC reports to find senders failing SPF.
Void Lookup Limit
RFC 7208 also caps void lookups (NXDOMAIN or empty responses) at 2. Stale include domains that no longer resolve cause void lookups and can trigger PermError even under 10 total lookups.
Multiple SPF Records
A domain must have exactly one SPF TXT record. Multiple records cause a PermError. Consolidate all authorized senders into a single record starting with v=spf1.
Using ptr Mechanism
The ptr mechanism is deprecated in RFC 7208 because it is slow, unreliable, and places excessive load on DNS. Some receivers ignore it entirely. Replace with ip4/ip6 or include mechanisms.
Overly Permissive +all
Using +all authorizes every IP address on the internet to send as your domain, defeating the entire purpose of SPF. Always use -all (hard fail) or ~all (soft fail) as the final mechanism.
Frequently asked questions about SPF
What is SPF?
SPF (Sender Policy Framework) is a DNS-based email authentication protocol defined in RFC 7208 that lets a domain owner publish which IP addresses and servers are authorized to send email on behalf of that domain. Receiving mail servers check the sender IP against the published SPF record and reject or flag messages from unauthorized sources. SPF is one of the three foundational email authentication protocols alongside DKIM and DMARC.
What does an SPF record look like?
An SPF record is a DNS TXT record published at the domain apex. A typical record looks like: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all. The v=spf1 tag is required and must be first. Include mechanisms delegate authorization to another domain. The ip4 and ip6 mechanisms authorize specific IP addresses. The all mechanism at the end defines the default policy for unlisted senders: -all means hard fail, ~all means soft fail.
Why does SPF have a 10-lookup limit?
RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS mechanism lookups to prevent SPF records from becoming a DNS amplification vector. Each include, a, mx, redirect, and exists mechanism triggers a DNS lookup that counts toward the limit. When organizations use multiple email services (Google Workspace, SendGrid, Mailchimp, CRM, support desk), the combined lookups from nested includes easily exceed 10. Exceeding the limit produces a PermError that fails authentication for every message from the domain.
What happens when you exceed the SPF 10-lookup limit?
When an SPF record exceeds 10 DNS mechanism lookups, the receiving server returns a PermError result. PermError means the SPF record could not be evaluated, and most receivers treat it as a fail. This affects every email sent from the domain, not just messages from the sender that caused the overflow. The fix is SPF flattening (replacing include mechanisms with resolved IP addresses) or SPF macros. AutoSPF, the DMARC Report sister product at autospf.com, handles both approaches and re-scans every 15 minutes.
What is the difference between -all and ~all in SPF?
The -all qualifier (hard fail) instructs receiving servers to reject email from any IP address not explicitly listed in the SPF record. The ~all qualifier (soft fail) instructs receivers to accept the message but mark it as suspicious. In practice, many receivers treat both similarly due to DMARC enforcement, but -all provides the strongest signal. Use ~all during initial SPF deployment for safety, then switch to -all once all legitimate senders are accounted for.
Does SPF work with email forwarding?
No. SPF breaks when email is forwarded because the forwarding server IP address is not in the original domain SPF record. The forwarder relays the message from its own IP, which the receiving server checks against the original domain SPF record and fails. This is one of the main reasons DKIM exists: DKIM signatures are attached to the message itself and survive forwarding. DMARC requires only one of SPF or DKIM to pass and align, so DKIM covers the forwarding gap.
How do I check my SPF record?
Use the DMARC Report SPF Checker tool at dmarcreport.com/tools/spf-checker/ to look up your SPF record, count DNS lookups, check for syntax errors, and verify that all your sending sources are included. The tool resolves all include mechanisms recursively and shows the full IP address list that your SPF record authorizes. You can also use nslookup or dig from the command line: dig TXT example.com will return your SPF record.
Check your SPF record now
Use our free SPF Checker to count DNS lookups, detect missing senders, and verify your record syntax. Results in seconds.
Check SPF RecordWhat Security Teams Say About SPF Monitoring
Rated 4.8/5 on G2 · 469 verified reviews
Verified User in Information Technology and Services
"Best security tool for your own domains"
The weekly reports help me a lot to analyze quickly the emails sent from my domains and that gives me peace of mind.
Ryan C.
Director
"Control Centre for Email Security"
I like that we can see and check all reports on just 1 platform. We manage multiple domains, and monitoring them all in one place is essential.
eddy g.
Director
"A great solution to a common email problem."
I have been using them for the last month after my Google business email started giving DMARC errors. I didn't even know what it meant at that time. After a little googling I found that people can spoof it as well. So far so good — the best thing is it protects every email.