SPF Record Checker & Lookup Tool
Enter a domain to read its SPF record, follow every include, and count DNS lookups against the RFC 7208 limit of 10 (and 2 void lookups). Over the limit means PermError.
SPF too many DNS lookups: safe fixes
RFC 7208 section 4.6.4 caps SPF at 10 terms that query DNS: include, a, mx, ptr, exists and the redirect modifier. Terms inside every nested include count too. Number 11 makes the receiver return permerror. A second limit hides behind it: more than 2 void lookups, names that come back empty or NXDOMAIN, is also a permerror. ip4, ip6 and all are free.
Under DMARC, a permerror means SPF cannot give you an aligned pass, so every message leans on DKIM. Mail that has no DKIM signature with your domain starts failing DMARC the day a provider adds one nested include to its own record. The checker above shows the total, the tree, and a “Lookups by term” table so you can see which include is expensive.
Fix it in this order
- Remove includes for services you no longer use. Old newsletter tools, a help desk you moved off, a CRM trial. Each one costs at least one lookup, often more once its own nested includes are counted.
- Check whether the include does anything at all. SPF is checked against the envelope sender (the Return-Path), not the From address. Many sending platforms use their own bounce domain by default. Open a message from the service and read its Return-Path: if it is not your domain, your SPF record is never consulted for that mail and the include can go. DMARC then passes on that service's DKIM signature with your domain, so confirm that first.
- Drop
aandmxyou do not need. They authorise your web server and inbound mail servers. If neither sends mail, they are wasted lookups. If a host does send and its IP is yours and fixed, anip4entry costs nothing. - Move a sender to a subdomain. Give the marketing platform a return path such as
news.example.comwith its own SPF record. Every name gets its own budget of 10, and relaxed alignment still matches a From ofexample.com. - Use the provider's current, documented include. Copy it from the provider's own setup page for your account, not from an old forum post. Our integration guides quote the SPF setup each service documents, including the ones that need no include at all.
The risks of flattening
Flattening swaps includes for the IP addresses they resolve to today. It gets the count down, and it trades one problem for three:
- It is a snapshot. When a provider adds sending ranges, your copy does not change and real mail starts failing SPF. Nobody tells you.
- It grows the record. RFC 7208 section 3.4 asks for the whole TXT answer to stay under 450 octets so it fits a UDP reply, and warns that bigger answers can be silently ignored by some verifiers.
- Automated flattening adds a dependency. A service that rewrites your record, or hosts it behind its own include, now sits in your mail path. If it fails or the contract ends, so does your SPF.
If you flatten anything, flatten your own static IPs and keep includes for providers that manage their ranges. Then re-run this check after every change.
What Is SPF?
Sender Policy Framework (SPF) is an email authentication standard defined in RFC 7208. It allows domain owners to publish a DNS TXT record listing the mail servers authorized to send email on behalf of their domain. When a receiving mail server gets an inbound message, it checks the sender's SPF record to confirm the sending server is legitimate.
SPF works by matching the sending server's IP address against the list of authorized IPs in the domain's SPF record. If the IP is authorized, the message passes SPF. If the IP is not listed, the message fails or softfails depending on the all qualifier at the end of the record. This process helps receivers identify and reject spoofed emails before they reach the inbox.
SPF Tag Reference
| Tag | Description |
|---|---|
| v | SPF version. The only valid value is v=spf1. This tag must appear first in every SPF record. |
| ip4 | Authorizes an IPv4 address or CIDR range to send email for your domain. Example: ip4:192.0.2.0/24. |
| ip6 | Authorizes an IPv6 address or CIDR range to send email for your domain. Example: ip6:2001:db8::/32. |
| a | Authorizes the IP address of the domain's A record. You can specify a different domain with a=example.com. |
| mx | Authorizes the IP addresses of the domain's MX records. Receivers look up the MX records and allow those IPs. |
| ptr | Authorizes senders whose reverse DNS matches the domain. This mechanism is slow, unreliable, and not recommended. |
| exists | Authorizes senders if a given domain name resolves to any address. Useful for dynamic allowlists. Example: exists:_spf.example.com. |
| include | Includes all authorized senders from another domain's SPF record. Commonly used for third-party services like Google Workspace or Mailchimp. |
| all | Matches every sender not matched earlier. Placed at the end of the record as -all (fail), ~all (softfail), ?all (neutral) or +all (pass, never use). |
| redirect | Modifier that hands evaluation to another domain's SPF record when no mechanism matched. It is ignored if the record has an all mechanism. Counts as one DNS lookup. |
| exp | Modifier that points to a TXT record with an explanation receivers may show when SPF fails. |
SPF Best Practices
Use the ~all Mechanism
Start with ~all (softfail) instead of -all (hard fail). This lets you monitor failed authentication results without rejecting legitimate email. Switch to -all once you are confident in your configuration.
Keep Your SPF Record Under the 10-Lookup Limit
Each include, a, mx, ptr and exists mechanism, and the redirect modifier, triggers a DNS lookup. Lookups inside included records count too. RFC 7208 limits SPF to 10 DNS lookups. Exceeding this limit causes a PermError, which makes your SPF record invalid.
Remove Unused include Statements
Audit your SPF record regularly. Remove any include statements for services you no longer use. Every unnecessary include consumes a DNS lookup and increases the risk of exceeding the limit.
Avoid the ptr Mechanism
RFC 7208 section 5.5 is titled "ptr (do not use)" and says the mechanism SHOULD NOT be published. It depends on reverse DNS that the owner of the connecting IP controls, not you. Use ip4, ip6, or include instead.
Do Not Use +all
A +all mechanism authorizes every sender on the internet to send email on behalf of your domain. This defeats the purpose of SPF entirely. Never use +all in a production record.
Maintain a Single SPF Record per Domain
Publishing multiple SPF TXT records at the same domain causes a PermError. If you need to add more senders, modify your existing record rather than creating a second one.
What Are the Limitations of SPF?
10-DNS-Lookup Limit
RFC 7208 caps SPF evaluation at 10 DNS lookups. Every include, a, mx, ptr, and exists mechanism, and the redirect modifier, triggers a separate lookup. Domains using multiple third-party email services often exceed this limit, which results in a PermError and invalidates the entire SPF record. Receiving servers then treat SPF as failed for your domain.
Email Forwarding Breaks SPF
When an email is forwarded, the receiver sees the forwarding server's IP address, not the original sender's. Since the forwarder's IP is not listed in the original sender's SPF record, the message fails SPF. This is a known limitation of SPF and one reason DMARC also accepts an aligned DKIM pass, which usually survives forwarding.
SPF Alignment Requirements
SPF authenticates the envelope-from address (Return-Path header), not the From header visible to recipients. For SPF to pass DMARC alignment, the envelope-from domain must match the From header domain. If your email is sent through a third-party service that uses its own envelope-from domain, SPF will fail alignment under DMARC unless you configure the service to use your domain in the Return-Path.
Frequently Asked Questions
Sender Policy Framework (SPF) is an email authentication protocol defined in RFC 7208. It lets domain owners publish a DNS TXT record listing the IP addresses and servers authorized to send email on behalf of their domain. Receiving mail servers check this record to verify whether an incoming message comes from an approved sender.
Without an SPF record, receiving servers have no way to confirm whether an email claiming to be from your domain actually originated from your servers. Attackers exploit this gap to send spoofed emails that impersonate your domain. Publishing an SPF record tells receivers which senders are legitimate. It also improves your email deliverability because many inbox providers reject or quarantine email from domains without SPF.
An SPF record checker is an online tool that queries your domain's DNS and validates your SPF record. It reports syntax errors, identifies which IP addresses and servers are authorized, counts DNS lookups, and flags configuration problems such as missing all mechanisms or duplicate SPF records.
SPF lookup is the process of querying a domain's DNS for its SPF TXT record. Receiving mail servers perform an SPF lookup on every inbound message to determine whether the sending server is authorized. The lookup result determines whether the message passes, softfails, or fails SPF authentication.
The SPF record checker helps you catch configuration errors before they affect your email delivery. It shows you the full parsed SPF record, identifies which senders are authorized, counts DNS lookups against the 10-lookup limit, and highlights issues like missing mechanism qualifiers or syntax errors. Fixing these issues improves your email authentication rate and reduces the chance your messages land in spam.
Enter your domain name in the input field above and click Check SPF. The tool queries your domain's DNS from your browser, retrieves the SPF TXT record, follows every include, and shows the results below the form. You will see the full record, the include tree, the DNS lookup count, and any errors or warnings.
When a receiving mail server gets an email, it looks up the SPF record published at the sender's domain. It evaluates each mechanism in order. If the sending server's IP address matches an authorized mechanism, the message passes SPF. If no mechanism matches, the all qualifier determines the result: +all passes, ~all softfails, -all fails, and ?all returns neutral. The receiver then uses this result alongside DKIM and DMARC to decide what to do with the message.
SPF has three main limitations. First, SPF enforces a maximum of 10 DNS lookups per record. Domains with many include statements exceed this limit and trigger a PermError. Second, SPF breaks when email is forwarded because the forwarder's IP address is not listed in the original sender's SPF record. Third, SPF authenticates only the envelope-from domain (the Return-Path header), not the From header visible to recipients. For SPF to count toward DMARC, these two domains must align.
A basic SPF record authorizing a single IP and softfailing all others: "v=spf1 ip4:192.0.2.1 ~all". A record using Google Workspace: "v=spf1 include:_spf.google.com ~all". A record combining multiple services: "v=spf1 include:_spf.google.com include:mailchimp.com ip4:203.0.113.50 ~all". Each record starts with v=spf1 and should end with an all mechanism.
Open a terminal and run: dig TXT yourdomain.com. Look for the TXT record starting with "v=spf1". On Windows, use: nslookup -type=TXT yourdomain.com. You can also use: nslookup -q=txt yourdomain.com. For a more detailed lookup, run: dig +short TXT yourdomain.com. These commands return the raw SPF record string so you can inspect it manually.
Major inbox providers such as Gmail, Outlook, and Yahoo use SPF as a signal when deciding whether to place an email in the inbox or spam folder. A passing SPF result tells the receiver the message comes from an authorized server. A failing or missing SPF record reduces your sender reputation and increases the likelihood your email is filtered as spam or rejected outright.
RFC 7208 limits SPF evaluation to 10 DNS lookups. Each include, a, mx, ptr, and exists mechanism counts as one lookup, and so does the redirect modifier. If your domain includes Google Workspace, Mailchimp, and two other services, you may already be near the limit because each service's own SPF record may contain nested includes. Exceeding 10 lookups returns a PermError and invalidates your entire SPF record.
Going over 10 DNS-querying terms, counted across every nested include, is the usual one. Others: more than 2 void lookups (names that return nothing), two v=spf1 records on one name, a syntax error such as an unknown mechanism, and an include or redirect that points to a domain with no SPF record.
Flattening replaces include mechanisms with the IP addresses they currently resolve to, since ip4 and ip6 cost no lookups. It works until a provider changes its addresses, and then your real mail fails SPF without warning. Try removing unused includes and moving senders to subdomains first; flatten only addresses you control.
Protect your domain from email spoofing
Monitor your SPF, DKIM, and DMARC records in one place. Start your guided trial and plan your path to enforcement.
Request a 14-Day Trial