SPF Record Too Long: How to Fix SPF Length and Lookup Limits

As your business adds email services — a marketing platform here, a CRM there, a helpdesk tool on top — your SPF record grows. At some point, you may hit a limit. The tricky part is that there are actually two different SPF limits, and they cause different problems. This guide explains both, helps you figure out which one you're hitting, and walks through practical fixes. For a full overview of SPF setup and best practices, see our complete SPF guide.

The Two SPF Limits You Need to Know

Most people talk about "the SPF limit" as if there's only one, but there are two distinct constraints that can break your SPF record.

Limit 1: The 255-character DNS string limit. This is a restriction in how DNS TXT records work at the protocol level.

Limit 2: The 10 DNS lookup limit. This is an SPF-specific rule that caps the number of DNS queries your record can trigger during evaluation.

Both can cause your emails to fail authentication, but they fail in different ways and require different fixes.

The 255-Character String Limit

DNS TXT records have a maximum string length of 255 characters per string, as defined in RFC 1035. This isn't an SPF rule — it's a fundamental constraint of the DNS protocol itself. If your SPF record is longer than 255 characters as a single string, it won't work correctly.

How to check your length: Look at your raw SPF record. Count the characters. If it's over 255 characters, you've hit this limit.

Here's an example of a record that exceeds 255 characters:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.protection.outlook.com include:mail.hubspot.net include:spf.constantcontact.com include:mailgun.org ~all

That's well under 255 characters (about 195). But add a few ip4 blocks and another couple of includes, and you'll cross the line.

How DNS string splitting works

The good news: DNS does support TXT records longer than 255 characters through string splitting. The record is broken into multiple strings within a single TXT record, and DNS resolvers automatically concatenate them back together.

"v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net "
"include:spf.protection.outlook.com include:mail.hubspot.net ~all"

Most DNS providers handle this automatically when you paste in a long SPF record. However, some older or less common DNS providers don't handle this well, which can cause parsing errors.

Fixing the 255-character limit

If your DNS provider isn't splitting strings correctly:

1. Contact your DNS provider — most modern providers handle this. Ask if they support multi-string TXT records.
2. Manually split the record — if your provider allows you to enter multiple strings in a single TXT record, split at any space between mechanisms, keeping each string under 255 characters.
3. Shorten the record — use the techniques in the "How to Shorten Your SPF Record" section below.

The 10 DNS Lookup Limit

The more common problem is the 10 DNS lookup limit. The SPF specification (RFC 7208 Section 4.6.4) says that evaluating an SPF record must not require more than 10 DNS lookups. If your record triggers more than 10 lookups, receiving servers return a PermError and your emails fail authentication.

We have a detailed guide on the 10 DNS lookup limit, but here's a quick summary.

What counts as a lookup:

• Each include: mechanism = 1 lookup (plus any lookups inside that include)
• Each a mechanism = 1 lookup
• Each mx mechanism = 1 lookup
• Each redirect= modifier = 1 lookup

What does NOT count:

• ip4: mechanisms (no DNS query needed)
• ip6: mechanisms (no DNS query needed)
• The all mechanism

The challenge is that include statements are recursive. When you include _spf.google.com, that record itself contains more includes, each of which counts toward your total. A single include:_spf.google.com can consume 3-4 of your 10 lookups.

How to Shorten Your SPF Record

When you're hitting either limit, here are practical techniques to reduce the size and complexity of your SPF record.

Replace includes with IP addresses

Every include: statement triggers at least one DNS lookup and adds characters to your record. If a service uses a small, stable set of IP addresses, you can replace the include with direct ip4: entries.

Before (1 include, uses lookups):

v=spf1 include:mail.example.com ~all

After (direct IPs, no lookups):

v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.5 ~all

SPF flattening

SPF flattening is the process of resolving all your include statements down to their underlying IP addresses and listing them directly in your record. It's essentially the "replace includes with IPs" technique applied to your entire record.

This can dramatically reduce your lookup count — potentially to zero. However, it comes with maintenance overhead, since you need to re-flatten whenever a provider changes their IP addresses.

For a full explanation and pros/cons, see our guide on SPF flattening.

Split sending across subdomains

Instead of authorizing every service on your root domain, you can assign different services to different subdomains and create separate SPF records for each.

Root domain (yourdomain.com):

v=spf1 include:_spf.google.com ~all

Marketing subdomain (mail.yourdomain.com):

v=spf1 include:sendgrid.net include:servers.mcsv.net ~all

Transactional subdomain (notify.yourdomain.com):

v=spf1 include:mailgun.org ~all

Configure each email service to send from its assigned subdomain. This spreads your lookups across multiple records, each with its own limit of 10. It also has the added benefit of isolating sender reputation — if your marketing emails get flagged, your transactional emails aren't affected. Keep in mind that subdomains do not inherit SPF records from the parent domain, so each one needs its own record.

Remove services you no longer use

This sounds obvious, but it's surprisingly common. Businesses switch email providers or cancel marketing tools and forget to remove the old includes from their SPF record. Audit your record and remove any includes for services you've stopped using. Not sure what each include is for? SPF Creator can help you identify common include domains.

When Your Record Is Genuinely Too Complex

Some organizations — especially those with many departments, agencies, or SaaS tools all sending email — genuinely have more than 10 legitimate email services to authorize. At that point, no amount of trimming will keep you under the limit with a single domain.

Your options:

1. Subdomain splitting (described above) is the most sustainable approach. It scales indefinitely and has the bonus of reputation isolation.

2. SPF flattening works but requires ongoing maintenance. If you go this route, automate the re-flattening process or use a monitoring tool that alerts you when provider IPs change.

3. Evaluate whether all services are needed. Sometimes consolidating from three marketing tools to one, or routing all transactional email through a single provider, solves the problem entirely.

Verifying Your Changes

After shortening your SPF record, verify that it's still valid and working:

1. Check the record with the tool above to confirm the lookup count is under 10 and the syntax is correct.
2. Send test emails from each service you've authorized. Check the headers to confirm spf=pass.
3. Run a full deliverability check at Deliverability Checker to see your complete authentication picture.

References

• RFC 7208: Sender Policy Framework (SPF) — The current SPF specification
• RFC 7208 Section 4.6.4: DNS Lookup Limits — The 10 DNS lookup limit
• RFC 1035: Domain Names — Implementation and Specification — Defines the 255-character DNS TXT string limit

Monitor Your SPF Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.