SPF Flattening Checker
Analyze any domain's SPF record for DNS lookup usage, RFC 7208 compliance, and PermError risk. Visualize the full include chain and generate a flattened SPF record with all IP ranges resolved — the diagnostic tool built for IT admins, MSPs, and email administrators.
What is SPF?
Sender Policy Framework (SPF) is an email authentication method that lets domain owners specify which mail servers are authorized to send email on their behalf. When a receiving mail server gets an incoming message, it checks the sender's domain for an SPF record — a special DNS TXT record that lists the authorized sending sources.
SPF is one of three email authentication standards alongside DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance). Together, they form the foundation of modern email authentication and spoofing protection.
SPF alone is not enough. SPF only validates the envelope sender (the "mail from" address used during the SMTP handshake), not the "From:" header that users see. A complete email authentication setup requires SPF, DKIM, and DMARC working together.
What is SPF flattening?
SPF flattening is the process of replacing dynamic include: directives in an SPF record
with the actual IP address ranges they resolve to. A typical unflattened record looks like this:
After flattening, all of the IP ranges from those include chains are resolved and listed directly:
The flattened version requires zero DNS lookups during evaluation — it is self-contained. This eliminates PermError risk from exceeding the 10-lookup limit, but introduces maintenance risk because IP ranges must be updated manually when providers change them.
Why SPF has a 10 DNS lookup limit
RFC 7208 limits SPF evaluation to a maximum of 10 DNS queries. This limit was set for two reasons:
Protect mail server performance
Every SPF check causes the receiving mail server to perform DNS queries. Without a limit, a single SPF evaluation could trigger dozens of recursive lookups, adding latency to every incoming message and overloading DNS resolvers.
Prevent DNS amplification abuse
Without a lookup limit, an SPF record could be constructed to force receiving servers to perform enormous numbers of DNS queries — effectively weaponizing the authentication check for denial-of-service attacks against DNS infrastructure.
The mechanisms that count toward the limit are: include:, a:,
mx:, ptr:, exists:, and redirect=. Mechanisms
that do not count include ip4:, ip6:, all, and
exp=.
What causes SPF PermError?
SPF PermError (Permanent Error) means a mail server encountered a condition that prevents it from evaluating the SPF record. Unlike TempError (which is transient), PermError is a definitive failure that will not resolve itself without a record change.
| Cause | Description | Fix |
|---|---|---|
| Too many DNS lookups | Evaluation exceeded the RFC 7208 limit of 10 | Flatten the record or remove unused include: entries |
| More than 10 void lookups | DNS queries returned NXDOMAIN or empty results | Remove broken or stale include: references |
| Syntax error | Record contains invalid mechanism or modifier | Correct the SPF record syntax |
| Circular include | Domain A includes domain B which includes domain A | Break the circular reference in one of the records |
| Multiple SPF records | Domain has more than one v=spf1 TXT record | Delete duplicate records, keep exactly one |
How email providers increase SPF complexity
Modern organizations typically use multiple email services simultaneously. Each one requires its own SPF include entry, and each entry consumes one or more DNS lookups:
| Service | SPF Mechanism | Typical Lookup Depth |
|---|---|---|
| Microsoft 365 | include:spf.protection.outlook.com | 4 lookups |
| Google Workspace | include:_spf.google.com | 4 lookups |
| Mailchimp | include:servers.mcsv.net | 2 lookups |
| SendGrid | include:sendgrid.net | 2 lookups |
| HubSpot | include:hubspot.com | 2–3 lookups |
| Salesforce | include:_spf.salesforce.com | 2 lookups |
| Zendesk | include:mail.zendesk.com | 1–2 lookups |
| Proofpoint | include:pphosted.com | 2–3 lookups |
The math adds up fast. A typical Microsoft 365 organization that also uses Google, Mailchimp, and Zendesk can easily reach 10+ lookups before accounting for any legacy includes from previous providers or marketing tools. This tool resolves the full chain so you can see exactly where your budget is being spent.
Pros and cons of SPF flattening
Advantages
- Eliminates PermError risk from exceeding the 10-lookup limit
- Reduces SPF evaluation latency (no recursive DNS lookups at evaluation time)
- Removes dependency on third-party DNS uptime during evaluation
- Simplifies SPF evaluation for receiving mail servers
- Provides clarity into which IP ranges are actually authorized
Disadvantages
- Static IP ranges become stale when providers change their infrastructure
- Requires manual monitoring and regular updates
- Email from new provider IP ranges will fail SPF until the record is updated
- Larger DNS TXT records may approach DNS packet size limits
- Cannot flatten
exists:orptr:mechanisms
When to flatten — and when not to
Flatten when:
- Your SPF record already exceeds 10 DNS lookups (PermError risk)
- You are approaching 10 lookups and plan to add more services
- You have a process to regularly review and update IP ranges
- You use an automated SPF management tool to keep ranges current
Do not flatten when:
- Your record is within the 10-lookup limit with comfortable headroom
- You cannot commit to regular IP range reviews
- Your providers change IP ranges frequently without advance notice
- You use
exists:mechanisms that cannot be flattened
Frequently asked questions
What is SPF flattening?
SPF flattening converts an SPF record that uses include: directives into a single record containing only explicit IP address ranges (ip4: and ip6: mechanisms). This eliminates the DNS lookup chain required during evaluation, preventing PermError failures caused by the RFC 7208 limit of 10 DNS lookups. The trade-off is that a flattened record must be manually updated whenever email providers change their IP ranges.
What is the SPF 10 DNS lookup limit?
RFC 7208 limits SPF evaluation to 10 DNS lookups maximum. Mechanisms that count toward this limit are include:, a:, mx:, ptr:, exists:, and redirect=. Mechanisms that do not count are ip4:, ip6:, and all. If a receiving mail server reaches the limit before finishing evaluation, it must return a PermError result. This can cause legitimate email to fail SPF authentication.
What causes SPF PermError?
SPF PermError is triggered by: exceeding the 10 DNS lookup limit (most common), more than 10 void lookups (NXDOMAIN responses during evaluation), syntax errors in the SPF record, multiple SPF TXT records for the same domain, or circular include references. PermError differs from TempError in that it is a permanent condition that will not resolve itself — the SPF record must be corrected.
Can SPF flattening improve email deliverability?
Yes, when your SPF record exceeds the 10-lookup limit. A PermError response from an overloaded SPF record can cause legitimate email to fail SPF authentication, reducing DMARC alignment and sender reputation. Flattening eliminates lookup chain complexity and ensures consistent evaluation. However, if your record is within the limit, flattening does not improve deliverability — it only adds IP range maintenance overhead.
Can flattened SPF records become outdated?
Yes — this is the primary risk. When you flatten, you replace dynamic include: directives with static IP ranges. If your email providers add, remove, or change IP addresses, your flattened record will not update automatically. Email from new IP ranges will fail SPF until you manually update the record. This is why automated SPF management services (such as Valimail, AutoSPF, and dmarcly) exist — they monitor provider IP ranges and automatically update flattened records when changes occur.
Why does Microsoft 365 use so many SPF include levels?
Microsoft 365 uses a hierarchical SPF structure to manage their large, changing IP address space. The root include (spf.protection.outlook.com) delegates to multiple sub-records organized by region or service group. This modular design allows Microsoft to add or change IP ranges without requiring every customer to update their SPF record — when they update a sub-record, all customers who reference the parent record automatically pick up the changes. The trade-off is that each layer of indirection consumes another DNS lookup from your 10-query budget.
What is the difference between SPF PermError and SPF Fail?
SPF Fail (or SoftFail) means the sending IP was not listed in the SPF record — the record was evaluated successfully but the sender did not pass. SPF PermError means the record could not be evaluated at all due to a configuration problem. PermError is often worse for deliverability than Fail because it indicates a broken configuration rather than an unauthorized sender, and some mail servers treat it more harshly.
Is there a size limit for SPF records?
DNS TXT records are limited to 255 bytes per string, but a single TXT record can contain multiple 255-byte strings that are concatenated. In practice, SPF records can be very long. However, DNS responses fit in a 512-byte UDP packet by default — larger responses require TCP fallback, which adds latency. If a flattened record exceeds ~512 characters, this tool will warn you. Most DNS servers and email receivers handle large TXT records correctly, but staying compact is good practice.