What is the DNS lookup limit and why does it matter?

RFC 7208 Section 4.6.4 sets a hard limit of 10 DNS-querying mechanisms per SPF evaluation. This exists to prevent excessive DNS traffic and denial-of-service amplification. The mechanisms that count are include, a, mx, ptr, exists, and the redirect modifier, since each one triggers a DNS query. Mechanisms like ip4, ip6, and all do not need DNS lookups, so they are free to use without limit. Go over 10 lookups and you get a PermError, which means SPF evaluation fails entirely. Gmail, Outlook, and Yahoo will reject or quarantine the email. This is one of the most common SPF misconfigurations, especially for organisations running multiple email services. Google Workspace alone eats 3 lookups through its nested include chain. Add Microsoft 365, a marketing platform like Mailchimp, and a transactional sender like SendGrid, and you blow past 10 quickly. Use this tool to see exactly how many lookups each include chain contributes.

What is an SPF include chain?

The include mechanism (RFC 7208 Section 5.2) delegates SPF authorisation to another domain's SPF record. For example, include:_spf.google.com tells receiving servers to evaluate Google's SPF record and authorise all IP addresses listed there. Chains form when included records contain their own includes. Google's _spf.google.com includes _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com, consuming 4 total lookups from what looks like a single include. Every nested include counts toward the 10-lookup limit from RFC 7208 Section 4.6.4. Deep chains from multiple providers can burn through the budget fast. This tool resolves the full include tree recursively and displays every nested record with its IP ranges, so you can see exactly where your lookups are going. Understanding include chain depth is the key to optimising your SPF record and avoiding PermError failures that break email authentication entirely.

Why is +all dangerous?

Using +all means every IP address on the internet is authorised to send email as your domain. It completely defeats the purpose of having an SPF record. Per RFC 7208 Section 2.3, the + qualifier means Pass, so any server anywhere in the world passes SPF evaluation when claiming to be your domain. This makes spoofing trivial. Phishing attacks, business email compromise (BEC), and spam campaigns can all forge your domain in the envelope sender and pass SPF checks without any effort. Never use +all in production. Use -all (hardfail) to tell receiving servers to reject email from unauthorised IPs, or use ~all (softfail) temporarily while you are confirming all legitimate sending sources are included. Domains with +all get flagged by email security systems regularly and tend to trigger warnings in DMARC aggregate reports.

What is the difference between ~all and -all?

With ~all (softfail), as defined in RFC 7208 Section 2.5.5, the domain owner is saying the sending IP is probably unauthorised but is not making a hard assertion. Receiving servers may accept the message but should flag it as suspicious, typically by bumping the spam score. With -all (hardfail) from Section 2.5.4, the IP is definitively not authorised and receiving servers SHOULD reject the message at the SMTP transaction level. Most production setups should use -all once all legitimate sending sources are confirmed and added to the record. That includes transactional email services, marketing platforms, and CRM systems. Use ~all temporarily during initial deployment or when adding a new provider, so you do not accidentally reject legitimate email before the include directive is verified. Once DMARC (RFC 7489) is deployed with a reject or quarantine policy, the practical difference between ~all and -all shrinks because DMARC enforcement takes precedence over the SPF qualifier.

How do I fix SPF PermError?

SPF PermError almost always means your record exceeds the 10 DNS lookup limit defined in RFC 7208 Section 4.6.4. When this happens, SPF evaluation fails entirely for all incoming email. Start by running this tool to see which include chains consume the most lookups. Several strategies can bring the count down. Replace include mechanisms with explicit ip4 and ip6 CIDR ranges, which require zero DNS lookups. Remove includes for email services you no longer use. Abandoned marketing platforms and decommissioned transactional senders are common offenders. You can also consolidate multiple includes under a single subdomain's SPF record. For example, create _spf.yourdomain.com containing the flattened IP ranges of several providers. SPF flattening services automate this by periodically resolving include chains and publishing the resulting IPs directly. While you are at it, check for syntax errors, circular references (where two records include each other), and duplicate includes that waste lookups. After making changes, re-run the checker to confirm you are under 10.

What is the ptr mechanism and why is it deprecated?

The ptr mechanism (RFC 7208 Section 5.5) validates the sending IP by doing a reverse DNS lookup to find the associated hostname, then a forward lookup on that hostname to verify it resolves back to the same IP. It works, but RFC 7208 explicitly says ptr SHOULD NOT be published in SPF records. There are good reasons for this. PTR lookups are significantly slower than A or IP-based lookups because they query the reverse DNS tree under .arpa, which tends to have longer response times. Reverse DNS is also less reliably maintained than forward DNS, so ptr checks are prone to transient failures that cause legitimate email to fail SPF evaluation. On top of that, widespread use of ptr adds unnecessary query load on .arpa nameservers. To fix an SPF record that contains ptr, replace it with explicit a mechanisms pointing to specific hostnames, or use ip4/ip6 ranges listing the server IP addresses directly. Both approaches are faster and more reliable.

How do I generate an SPF record?

The SPF Generator below the checker lets you build a valid, RFC 7208-compliant record by selecting the email providers you use. Each provider preset (Google Workspace, Microsoft 365, SendGrid, Mailchimp, Amazon SES, Postmark, and others) adds the correct include directive for that provider's sending infrastructure. You can also add custom IP addresses using ip4 and ip6 CIDR notation for on-premise mail servers, plus custom include directives for third-party senders not in the preset list. The generator constructs the record automatically with the v=spf1 prefix and your chosen policy qualifier (-all or ~all). Once generated, add it to your DNS zone as a TXT record with the name @ (your root domain). A domain must have exactly one SPF TXT record. Publishing multiple SPF records causes a PermError per RFC 7208 Section 4.5 because the evaluating server cannot determine which one to use. After publishing, run the checker to verify correctness and confirm your lookup count is within limits.

SPF Record Checker

Validate your SPF record, count DNS lookups, trace include chains, and generate SPF records for the email providers you use.

SPF Record Generator

Select the email providers you use to build a valid SPF record.

Your Domain (optional — adds a and mx)

Email Providers

Custom IPs (comma or space separated)

Custom Includes (domains)

All Qualifier

“SPF tells the internet who's allowed to send email from your domain. Get it wrong and nobody trusts your mail.”

Written by Ishan Karunaratne · Last reviewed: March 11, 2026

What Is an SPF Record?

SPF (Sender Policy Framework) is a DNS-based email authentication standard defined in RFC 7208. It lets domain owners publish a list of authorised sending mail servers as a TXT record in DNS. When a receiving mail server accepts an inbound message, it checks the sending IP against the SPF record for the domain in the From header. If the IP is not listed, the receiving server can reject or flag the message.

SPF alone does not prevent spoofing of the visible From address — that requires DMARC. But SPF is a prerequisite for DMARC alignment and a fundamental layer of email authentication alongside DKIM. To verify how receivers evaluate your SPF results, analyze email headers from a test message.

What Is the 10 DNS Lookup Limit?

RFC 7208 Section 4.6.4 limits SPF evaluation to a maximum of 10 DNS lookups. Each of the following mechanisms counts as one lookup: include, a, mx, ptr, and exists. Exceeding this limit causes a PermError, which means SPF fails permanently for that evaluation.

This becomes a problem when using multiple email services. A typical setup might include Google Workspace, Mailchimp, and a transactional provider — and each of those includes may themselves include other records, quickly consuming all 10 lookups. Use this tool to see your exact lookup count and which includes are contributing most.

What Are SPF Mechanisms?

An SPF record is a space-separated list of mechanisms and modifiers, as defined in RFC 7208 Section 4.6. Each mechanism can be prefixed with a qualifier that determines what happens when the mechanism matches.

ip4: / ip6:

Authorise specific IP addresses or CIDR ranges. No DNS lookup required.

include:

Delegate to another domain's SPF record. Counts as one lookup.

a

Authorise IPs in the domain's A/AAAA records. Counts as one lookup.

mx

Authorise IPs of the domain's MX servers. Counts as one lookup.

-all

Hardfail — reject all senders not matched above.

~all

Softfail — accept but flag senders not matched above.

The qualifiers are + (pass, the default), - (fail), ~ (softfail), and ? (neutral). The all mechanism at the end of the record is the catch-all for senders not matched by any earlier mechanism.

How Do You Generate an SPF Record?

The SPF Generator in the tool above lets you build a valid SPF record by selecting the email providers you use. Each preset adds the correct include directive for that provider's sending infrastructure. You can also add custom IP ranges for on-premise mail servers or other services.

Once generated, add the record to your DNS zone as a TXT record with the name @ (representing your root domain). A domain should have exactly one SPF TXT record — multiple SPF records cause a PermError per RFC 7208 Section 4.5. After publishing, use the checker above to verify the record is correct and within the 10-lookup limit.

What Other Email Tools Help With SPF?

SPF is one part of a complete email authentication setup. For full protection against spoofing and phishing, also configure DKIM and DMARC:

•MX Lookup — Find mail servers for any domain and detect the email provider
•DKIM Checker — Verify your email signing keys and BIMI brand indicators
•DMARC Checker — Analyse your email policy and reporting configuration
•SMTP Diagnostics — Test mail server connectivity, TLS, and open relay status

Need this in code?

Every check this tool runs is also available via the SPF check API with examples in cURL, JavaScript, Python, PHP, Ruby, and Java.

API docs

Built and maintained alongside this tool. Free, no signup required.

DKIM record validatorVerify the cryptographic signature on outbound mail.DMARC policy readerCatch overly permissive p=none policies.MX record lookupWhere does inbound mail for this domain go?Email Tester (deliverability)Send a test message and grade SPF + DKIM + DMARC + content together.