By Mike Walton, Founder of CertMS

After 20+ years managing IT infrastructure and PKI systems, I've seen more broken SPF records than I'd like to admit. The frustrating part? Most failures come from the same handful of mistakes that are completely preventable.

Your emails are landing in spam. Or worse, getting rejected entirely. You've set up DMARC, published an SPF record, and followed all the guides. So what's going wrong?

The culprit is almost always your SPF record. According to 2025 telemetry data from Red Sift, 41% of SPF failures are caused by exceeding the 10 DNS lookup limit alone. Another 28% come from upstream provider changes that silently break your authentication.

Let me walk you through exactly why SPF records fail and what you can do about it.

SPF Basics: A Quick Refresher

Before we dig into the problems, let's make sure we're on the same page.

SPF (Sender Policy Framework) is a DNS record that tells receiving email servers which IP addresses and servers are authorized to send email for your domain. When Gmail or Microsoft 365 receives an email claiming to be from your domain, they check your SPF record to verify the sending server is on your approved list.

If the check passes, great. If it fails, the email might get flagged as suspicious, sent to spam, or rejected outright - especially now that major email providers are enforcing stricter authentication requirements.

A basic SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Simple enough, right? In theory, yes. In practice, things get complicated fast.

The 10 DNS Lookup Limit: SPF's Hidden Trap

Here's a constraint that catches nearly everyone off guard: SPF records cannot require more than 10 DNS lookups to evaluate.

This limit is baked into RFC 7208, the specification that governs SPF. It exists to prevent denial-of-service attacks - without it, a malicious SPF record could trigger unbounded chains of DNS queries that overwhelm receiving servers.

The problem? This limit was set in 2006. Back then, most organizations used maybe two or three email services. Today, a typical mid-sized company might use a dozen.

What Counts Toward the Limit

These mechanisms trigger DNS lookups and count toward your limit:

• include: (the big one)
• a
• mx
• ptr (deprecated, don't use)
• exists
• redirect

These do NOT count:

• ip4:
• ip6:
• all

Here's where it gets tricky. Each include: mechanism doesn't just count as one lookup. It triggers a lookup for that domain's SPF record, which might contain more includes that trigger additional lookups.

As Valimail explains: "A single include for a major ESP might trigger three or four additional lookups. Email service providers don't keep their infrastructure simple."

A Real-World Example

Let's say your SPF record looks like this:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mailchimp.com include:amazonses.com -all

That's 5 include: statements. Looks fine. But:

• _spf.google.com resolves to 4 additional includes
• spf.protection.outlook.com triggers 2 more lookups
• SendGrid, Mailchimp, and Amazon SES each add their own nested lookups

Before you know it, you're at 15+ lookups. SPF fails with a PermError.

What Happens When You Exceed the Limit

When a receiving email server encounters an SPF record requiring more than 10 lookups, it returns "SPF PermError: too many DNS lookups."

According to DMARCLY's research, DMARC treats this as a fail since it's a permanent error. Your emails don't just fail SPF - they fail DMARC too, even if your DKIM is perfectly configured.

The worst part? This failure can be intermittent. As Mailhardener notes, "Depending on the sender, a verifier may not always reach the lookup limit, even if the policy requires more than 10 lookups to fully evaluate. This makes SPF lookup limit related deliverability issues particularly difficult to identify."

Your marketing emails might work fine from Mailchimp but fail when sent through HubSpot. Troubleshooting becomes a nightmare.

Seven Common SPF Mistakes (And How to Fix Them)

Beyond the lookup limit, plenty of other errors can break your SPF authentication. Industry data suggests over 20% of business domains have misconfigured SPF records. Here are the mistakes I see most often.

Mistake 1: Multiple SPF Records

This one causes more headaches than it should. According to the RFC, each domain can have only one SPF record. If you have two, receiving servers don't know which to use, and SPF fails with a PermError.

It happens easily. You set up Google Workspace and add their SPF record. Later, marketing adds Mailchimp through a different DNS interface, creating a second record instead of merging them.

The fix: Combine all your authorized senders into a single SPF record.

Bad:

v=spf1 include:_spf.google.com -all
v=spf1 include:mailchimp.com -all

Good:

v=spf1 include:_spf.google.com include:mailchimp.com -all

Mistake 2: Typos and Syntax Errors

A missing space. A misspelled mechanism. An extra comma. These small errors completely break SPF authentication.

PowerDMARC's documentation highlights common typos:

• "incldue" instead of "include"
• "ipv4" instead of "ip4"
• Missing "v=spf1" at the beginning
• Extra spaces before or after the record

The fix: Always validate your SPF record using an online tool before publishing changes. Even a single character matters.

Mistake 3: Using the Wrong Record Type

SPF records should be published as TXT records in DNS. There used to be a dedicated SPF record type, but it's been deprecated for years.

Some DNS interfaces still offer the option to create SPF-type records. Don't use them.

The fix: Use TXT records only. Delete any SPF-type records you might have.

Mistake 4: Forgetting Third-Party Services

That CRM you signed up for six months ago? The ticketing system your support team uses? The transactional email service running your password resets?

Every one of these needs to be in your SPF record. According to AutoSPF, "The problem often arises when organizations adopt new email services, switch hosting providers, or start using third-party tools without updating their SPF records."

The fix: Maintain an inventory of every service that sends email from your domain. Update your SPF record whenever you add a new tool.

 

Mistake 5: Using Overly Permissive Mechanisms

If your SPF record ends with +all, you're essentially telling the world that any server can send email as your domain. That defeats the entire purpose of SPF.

According to EasyDMARC, "If you have used the forbidden '+all' mechanism, it will trigger DMARC problems."

The fix: Always end your SPF record with -all (hard fail) or ~all (soft fail). Never use +all.

• -all: Reject emails from unauthorized servers
• ~all: Mark unauthorized emails as suspicious (soft fail)
• ?all: Take no action (neutral - basically useless)
• +all: Allow everything (dangerous)

Mistake 6: Using Unnecessary Mechanisms

The a and mx mechanisms seem convenient - they automatically authorize your domain's A records and mail exchangers. But they each consume a DNS lookup, and most of the time you don't need them.

Your web server (the a record) probably doesn't send email. Your MX records are for receiving mail, not sending it.

The fix: Remove a and mx mechanisms unless your web server or mail exchangers actually send outbound email. Replace them with specific ip4: entries that don't count toward the lookup limit.

Mistake 7: Not Monitoring for Changes

Here's a sneaky one. You set up SPF perfectly, test it, everything works. Six months later, emails start failing.

What happened? Your email service provider changed their infrastructure. They added new sending IPs or updated their SPF includes. Your record points to the old configuration.

This is why Red Sift's research found that 28% of SPF failures come from upstream provider changes.

The fix: Monitor your DNS records for changes. Tools like MonitorDMARC can alert you when your SPF, DKIM, or DMARC records change - whether you made the change or someone else did.

Fixing the 10 Lookup Limit: Your Options

Okay, so you've hit the lookup limit. Now what? You have several options, each with tradeoffs.

Option 1: SPF Flattening

SPF flattening replaces include: mechanisms with the actual IP addresses they resolve to. Instead of include:sendgrid.net, you list SendGrid's IP ranges directly using ip4: mechanisms.

As DMARCLY explains: "The advantage of using SPF flattening techniques is that you can convert a very complex SPF record with over 10 DNS lookups into an IP address list while remaining just as secure."

The catch? Those IP addresses change. Cloud providers rotate their sending IPs regularly. If SendGrid adds new servers and you're using flattened IPs, your authentication breaks.

Manual SPF flattening is described as a "trap" by industry experts - "It looks like a quick fix, but vendor IP rotations make static records go stale fast."

Best for: Organizations that can commit to monitoring and updating their SPF records weekly.

Option 2: Subdomain Delegation

Instead of cramming everything into your main domain's SPF record, delegate different sending services to subdomains.

Your marketing team uses marketing.yourdomain.com. Transactional emails come from notifications.yourdomain.com. Support uses help.yourdomain.com.

Each subdomain gets its own SPF record with its own 10-lookup budget. Microsoft recommends this approach for bulk email services specifically: "You don't want issues with mail sent from those email services to affect the reputation of mail sent by users in your main email domain."

Best for: Organizations with clearly separated email streams (marketing, transactional, support) and the infrastructure to manage multiple subdomains.

Option 3: SPF Macros

RFC 7208 includes SPF macros - special variables that allow dynamic SPF record evaluation. They're powerful but complex to implement correctly.

Macros can reduce the number of lookups required by encoding sender information into the DNS query itself. However, they require careful planning and aren't supported by all email infrastructure.

Best for: Large enterprises with dedicated email engineering teams.

Option 4: Automated Dynamic SPF

This is the modern approach. Automated SPF services maintain a single, compressed record that stays updated automatically.

According to Red Sift's data, "Domains that implemented automated SPF flattening with 24-hour refresh saw an 83% reduction in SPF permerrors and a 12-19% improvement in DMARC alignment pass rates."

These services monitor your email providers' infrastructure changes and update your SPF record automatically. You get one include mechanism that points to their dynamically maintained record.

Best for: Organizations that want a reliable, low-maintenance solution.

Third-Party Services: The Hidden Challenge

Most DMARC failures stem from misconfigurations with third-party email services. According to PowerDMARC, "If you commonly use third-party tools like HubSpot, MailChimp, or any other CRM platforms, and haven't integrated them yet into your SPF record, the emails sent by them are going to fail."

Each service you use needs proper configuration:

For SPF: Add their sending infrastructure to your SPF record or set up a dedicated subdomain they can control.

For DKIM: Most services let you configure custom DKIM signing with your domain. As DMARC Report explains, "It's essential to ask your vendor to create a DKIM key pair for your personalized domain. They will utilize the private key to sign the emails they send on your behalf, and you must publish the corresponding public key on your publicly accessible DNS."

Here's a typical setup for a popular CRM like Salesforce: Salesforce, by default, uses their own domain as the Return-Path domain. This breaks DMARC alignment. You need to configure a custom Return-Path and DKIM to make it work properly.

 

How to Audit Your SPF Record

Before you can fix problems, you need to find them. Here's a systematic approach:

Step 1: Check for multiple SPF records

Use your DNS provider's interface or a tool like dig:

dig TXT yourdomain.com | grep spf

If you see more than one record starting with "v=spf1", that's your first problem to fix.

Step 2: Count your lookups

Use an online SPF checker to count total DNS lookups. Several free tools exist. Look for anything at 8+ lookups - you're at risk if you add another service.

Step 3: Validate syntax

Run your SPF record through a validator. Check for typos, missing spaces, deprecated mechanisms (ptr), or overly permissive endings (+all).

Step 4: Verify all senders are included

List every service that sends email from your domain. Check that each one is covered by your SPF record. Common sources to verify:

• Email hosting (Google Workspace, Microsoft 365)
• Marketing platforms (Mailchimp, HubSpot, Constant Contact)
• CRM systems (Salesforce, Zoho)
• Transactional email (SendGrid, Amazon SES, Mailgun)
• Support systems (Zendesk, Freshdesk)
• Accounting software (QuickBooks, Xero)
• Internal applications

Step 5: Check for nested lookup issues

Some SPF checkers show the total lookups after resolving all nested includes. If you're over 10, you need to address it before it causes failures.

Monitoring Is Not Optional

Here's the reality: SPF configuration isn't a one-time task. Your email infrastructure changes. Third-party providers update their systems. Records can be accidentally modified.

If you set up DMARC and started receiving those XML reports (as covered in our complete DMARC guide), you have visibility into SPF failures. But raw XML is difficult to parse, and SPF issues can be hard to spot in aggregate data.

MonitorDMARC can help in two ways:

1. DMARC report parsing: Transform those unreadable XML reports into actionable dashboards. See exactly which emails are failing SPF and why.

2. DNS record monitoring: Get alerted when your SPF, DKIM, DMARC, or BIMI records change. Whether the change was intentional or not, you'll know about it.

The combination matters. DMARC reports tell you when authentication is failing. DNS monitoring tells you when the underlying records change. Together, you can catch and fix problems before they impact your email deliverability.

The 2026 Reality: Stricter Enforcement

If SPF configuration felt optional before, it isn't anymore.

Since February 2024, Google and Yahoo require DMARC for bulk senders - anyone sending more than 5,000 emails per day. By November 2025, Google moved from warnings to outright rejection of non-compliant emails.

Microsoft joined the enforcement push in May 2025, implementing strict authentication requirements for Outlook.com and related services.

And if you handle payment card data, PCI DSS 4.0 mandated DMARC implementation by March 31, 2025. Non-compliance can result in penalties up to $100,000 per month.

SPF errors that once caused minor inconveniences now cause serious deliverability problems.

Taking Action

SPF isn't complicated in theory. Publish a record listing your authorized senders. Done.

But modern email infrastructure makes it complex in practice. Too many services, too few DNS lookups, and too little monitoring lead to authentication failures that hurt your deliverability and potentially your compliance posture.

Here's your action plan:

1. Audit your current SPF record for the issues outlined above
2. Fix any immediate problems - multiple records, syntax errors, missing senders
3. Address the lookup limit if you're at risk - consider subdomain delegation or automated solutions
4. Set up monitoring for ongoing visibility into authentication failures

Your DMARC reports are already telling you when SPF fails. The question is whether you're listening.

Start your 14-day free trial of MonitorDMARC (no credit card required) and see what's actually happening with your email authentication.

---

Mike Walton is the founder of CertMS, a certificate management platform. He has 20+ years of experience in IT infrastructure and PKI management.

---