SPF Record Checker & Lookup Tool
Verify your domain's SPF record configuration. Identify authorized senders, detect errors, and prevent email spoofing.
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.
Publishing an SPF record is one of the foundational steps in email authentication. Together with DKIM and DMARC, SPF protects your domain from impersonation attacks, improves your sender reputation, and increases your email delivery rates across major inbox providers.
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
The ptr mechanism depends on reverse DNS, which is slow and unreliable. Most receivers ignore or penalize ptr-based authorization. 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.
The most common cause is exceeding the 10-lookup limit through too many include mechanisms. Another frequent cause is publishing two or more SPF TXT records on the same domain. Syntax errors like missing quotes, incorrect mechanism qualifiers, or an invalid SPF version also trigger PermError. Using a redirect to a domain without an SPF record produces a PermError as well.
SPF flattening resolves all include mechanisms into their constituent IP addresses and removes nested lookups. This lowers the DNS lookup count because ip4 and ip6 mechanisms need no DNS lookups. Flattening is necessary when your SPF record approaches or exceeds the 10-lookup limit. You must update the flattened record whenever a third-party service changes its sending infrastructure.
Protect your domain from email spoofing
Monitor your SPF, DKIM, and DMARC records in one place. Start your free trial and secure your email authentication today.
Start Your 14-Day Trial Now