SPF Record Not Working? How to Find and Fix the Problem

If your emails are bouncing or landing in spam despite your DNS settings appearing "correct," your SPF record is failing. Receiving servers do not care about your intent; they only care if the record follows the strict RFC 7208 specifications. When you find your spf record not working, the culprit is almost always a violation of the protocol’s hard limits: either you have multiple SPF records published, or your record has exceeded the 10-lookup limit.

SPF (Sender Policy Framework) is a DNS-based mechanism that lists authorized sending IP addresses for a domain. Because it was designed for simplicity, it lacks the flexibility to handle configuration errors. A single syntax mistake or an extra space invalidates the entire record, causing a "PermError" and triggering immediate rejection by major providers like Gmail and Outlook.

This guide provides a technical deep dive into diagnosing and repairing SPF failures to restore your domain's sender reputation.

Immediate Diagnostics: Identifying the Failure Type

Before modifying your DNS, you must identify the specific error code returned by the receiving server. Most bounce-back messages or email headers will indicate whether the failure is a "SoftFail," a "HardFail," or a "PermError."

If you are unsure what the internet sees, use an spf record checker to pull the live record directly from your nameservers. This tool highlights syntax errors that are often invisible in a standard DNS management dashboard.

Understanding the Authentication-Results Header

To see why a record is failing in a live environment, open the "Original Message" or "Message Headers" in the receiving mailbox. Look for the Authentication-Results line.

• spf=pass: The IP is authorized, and the record is valid.
• spf=fail (HardFail): The record explicitly states the IP is not authorized (using -all).
• spf=softfail: The record suggests the IP is not authorized but asks the server to be lenient (using ~all).
• spf=permerror: The record is broken. This is usually due to multiple records or the 10-lookup limit.
• spf=temperror: A DNS timeout occurred. This is a temporary issue with your DNS provider, not the record itself.

The Two Primary Killers of SPF Functionality

The vast majority of "not working" issues stem from two specific protocol violations.

1. The Multiple Record Conflict

Per RFC 7208, a domain must have exactly one SPF record. If a receiving server detects two or more TXT records starting with v=spf1, it will return a "PermError" and ignore all of them. This effectively means you have no SPF protection at all.

This usually happens when a business adds a new service, such as Zendesk or HubSpot, and follows the setup instructions to "add this TXT record" instead of updating the existing one.

2. The 10-Lookup Limit

The SPF protocol limits the number of DNS lookups a server must perform to validate a record to prevent Denial of Service (DoS) attacks. Every include, a, mx, ptr, and exists mechanism counts toward this limit.

If you use multiple third-party services like Google Workspace and Microsoft 365, their nested include statements can quickly push your total count to 11 or higher. Once you hit 11, the record is technically invalid. Note that ip4 and ip6 mechanisms do not count toward this limit, making them essential for complex configurations.

Step-by-Step Fix: Consolidating and Repairing Records

If you have identified multiple records or a "PermError," you must merge your mechanisms into a single, clean string.

Step 1: Audit Your Current Mechanisms

Locate every TXT record on your domain that begins with v=spf1. For example, you might find:

• Record A: v=spf1 include:_spf.google.com ~all
• Record B: v=spf1 include:spf.protection.outlook.com -all

Step 2: Merge into a Single String

Create a new string that starts with v=spf1, lists all include and ip4 mechanisms in the middle, and ends with a single "all" mechanism.

Correct Consolidated Record: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Step 3: Choose the Correct Qualifier

The qualifier at the end of your record tells the receiver how to handle unauthorized mail.

The Fail Qualifier

Label: -all Action: HardFail. The receiver should reject the email entirely. Use this only when you are certain your SPF record is 100% complete.

The SoftFail Qualifier

Label: ~all Action: SoftFail. The receiver should accept the email but mark it as suspicious or send it to the spam folder. This is the recommended setting during troubleshooting.

The Neutral Qualifier

Label: ?all Action: Neutral. The receiver takes no action. This is effectively the same as having no SPF record and provides no security benefit.

Solving the 10-Lookup Limit (SPF Flattening)

If your spf record checker indicates you are over the 10-lookup limit, you cannot simply add more include statements. You must "flatten" the record using one of the following strategies.

Strategy 1: Replace Includes with IP Ranges

The most effective way to reduce lookups is to replace an include: mechanism with the actual ip4: or ip6: addresses used by the service.

• Mechanism: ip4:192.0.2.0/24
• Benefit: This counts as zero lookups toward the 10-lookup limit.
• Risk: Service providers like Google frequently change their IP ranges. If you hardcode their IPs and they change them, your mail will fail SPF. Only use this for your own static web server IPs.

Strategy 2: Remove the 'mx' and 'a' Mechanisms

Many default SPF records include mx or a. These mechanisms require the receiving server to look up your domain's MX or A records, adding to the lookup count. If your mail is sent exclusively through a provider like Microsoft 365, you can usually remove these mechanisms entirely, as the include:spf.protection.outlook.com already covers the necessary IPs.

Strategy 3: Subdomain Delegation

If your lookup count is too high because of marketing tools, move those tools to a subdomain. For example, send corporate mail from microsoft.com and marketing mail from news.microsoft.com. The subdomain news.microsoft.com can have its own independent SPF record with its own 10-lookup budget.

Common Syntax and Formatting Errors

Even a consolidated record will fail if the syntax is slightly off. SPF parsers are notoriously unforgiving.

• Smart Quotes: If you copy your SPF record from a Word document or a blog, you may accidentally paste "curly" quotes. SPF records must use straight ASCII quotes.
• Leading/Trailing Spaces: Ensure there are no spaces before v=spf1 or after the final all.
• Multiple "all" Mechanisms: A record should never end with ~all -all. Only the last "all" is processed.
• Typing Errors: Misspelling include as inclue or ip4 as ipv4 will trigger a PermError.
• The "SPF" Record Type: Some DNS providers still offer an "SPF" record type. This is obsolete. SPF records must always be published as TXT records.

Advanced Troubleshooting: DNS Propagation and TTL

Sometimes the record is technically perfect, but the spf record not working issue persists. This is usually a result of DNS caching.

Every DNS record has a Time to Live (TTL) value. If your TTL is set to 3600, receiving servers will cache your old, broken SPF record for one hour. Even if you fix the record in your dashboard, the rest of the world will continue to see the broken version until the TTL expires.

When troubleshooting, lower your TTL to 300 seconds (5 minutes). This ensures that any further changes you make propagate quickly. Once you have confirmed the fix is working, you can raise the TTL back to a standard value like 86400 (24 hours) to reduce DNS load.

The Role of DMARC Alignment in SPF Failures

SPF does not work in a vacuum. If your SPF record is correct but your mail is still failing authentication, the problem may be DMARC alignment.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) requires that the domain in the "From" header matches the domain used in the SPF check (the Return-Path). If you are sending mail through a third-party service that uses its own domain for the Return-Path, SPF will pass, but DMARC will fail because the domains do not align.

To ensure total delivery, you should verify all three protocols. You can follow our comprehensive guide on how to check SPF, DKIM, and DMARC to ensure your entire authentication suite is synchronized.

Testing Your Fix with Disposable Environments

When you are actively changing DNS settings, you need a way to test delivery without triggering spam flags on your own primary inbox. Sending dozens of test emails to your personal Gmail account during a troubleshooting session can damage your sender reputation.

Using a disposable email service allows you to verify delivery in a "clean" environment. Best-TempMail provides a reliable platform for this because their system uses real-time WebSockets to show incoming mail instantly. If your SPF fix is working, you will see the email arrive in the temporary inbox without delay.

This is particularly useful for developers testing automated systems. For instance, if you are verifying that your 10 minute mail for OTP codes is functioning, using a temporary address prevents your testing data from polluting your corporate mail logs. By sending a test mail from your server to a Best-TempMail address, you can inspect the headers in a neutral environment to confirm the spf=pass result.

Final Checklist for a Working SPF Record

Before you finish, run through this checklist to ensure your spf record not working problem is truly resolved:

1. Uniqueness: Is there exactly one TXT record starting with v=spf1?
2. Lookup Count: Does the record trigger 10 or fewer DNS lookups? (Check this with an external tool).
3. Syntax: Are there any curly quotes, extra spaces, or typos?
4. IP Inclusion: Does the record include the IP address of your web server if it sends mail directly?
5. Qualifier: Does the record end with ~all or -all?
6. TTL: Has enough time passed for the old record to clear the cache of the receiving server?

For ongoing verification, keep a set of email tools bookmarked. Regularly checking your domain's health ensures that new service additions don't silently break your authentication again.

Frequently Asked Questions

Why does my SPF pass on some checkers but fail in Gmail?

Gmail is more aggressive than most tools in enforcing the 10-lookup limit and DMARC alignment. A basic syntax checker might tell you the "code" is correct, but it may not be calculating the total nested lookups. If your include statements point to other domains that also have include statements, you may be over the limit without realizing it.

Can I use a CIDR range in an SPF record?

Yes. Using CIDR ranges (e.g., ip4:192.0.2.0/24) is the best way to authorize a large block of IP addresses without increasing your DNS lookup count. This is a standard practice for companies hosting their own mail servers.

What is the difference between a HardFail and a SoftFail?

A HardFail (-all) tells the receiving server to reject the email. A SoftFail (~all) tells the server to accept it but mark it as suspicious. Most experts recommend using ~all because it prevents legitimate mail from being deleted if your SPF record is slightly incomplete.

Why is my SPF record not found even though I added it?

This is usually due to one of three things: you added it as an "SPF" record type instead of a "TXT" record type, you added it to the wrong DNS zone, or the DNS propagation has not yet completed. Ensure the "Host" or "Name" field in your DNS settings is either @ or left blank, depending on your provider's requirements.

How do I handle multiple services like Google and Outlook?

You must combine them into one record: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all. Never publish them as separate TXT records. This consolidation is a common hurdle, and failing to do it correctly is why most temp mail services fail to receive verification emails when users attempt to configure their own custom domains.

Does Best-TempMail support SPF?

Yes, Best-TempMail uses fully authenticated domains. When you use their disposable email service to test your outgoing mail, you are testing against a system that follows all modern security protocols, ensuring your results are accurate and reflect how a major provider like Gmail would see your mail.