What SPF Does and Why It Breaks
Sender Policy Framework (SPF) is an email authentication method that tells receiving mail servers which hosts are allowed to send mail for your domain.
When SPF is misconfigured, mail can fail authentication, land in spam, or trigger hard bounces that are difficult to diagnose.
If you are trying to understand how to fix SPF record not working, the issue is usually not SPF itself but a DNS or sender mismatch.
The key is to identify which mail source is actually sending and whether your record authorizes it correctly.
How SPF Works at a Basic Level
An SPF record is a DNS TXT record published at your domain.
During delivery, the receiving server checks the sender IP, follows any SPF mechanisms such as include or ip4, and compares the result to the envelope sender domain.
- Pass: the sender is authorized.
- Fail: the sender is not authorized and should be rejected or flagged.
- SoftFail: the sender is probably unauthorized, but handling is left to the receiver.
- Neutral: the policy does not explicitly authorize or deny the sender.
- PermError: the SPF record is malformed or exceeds DNS evaluation limits.
Check the SPF Record Syntax First
Many SPF failures come from simple syntax mistakes.
A valid record usually starts with v=spf1 and ends with a qualifier such as -all or ~all.
Every mechanism must be separated cleanly, and the record must remain in a single TXT string or properly combined strings at the DNS provider.
Common syntax problems
- Missing the
v=spf1version tag - Using multiple SPF TXT records for the same domain
- Typographical errors in
includedomains - Extra spaces, unsupported characters, or broken quotes
- Using a deprecated
SPFDNS record type instead of TXT
If your DNS host splits long TXT values, confirm the software recombines them correctly.
Some registrars display records in segments, but mail receivers evaluate the combined string.
Verify That You Have Only One SPF Record
A domain should have only one SPF record.
If you publish more than one TXT record containing v=spf1, many receivers return a PermError because they do not know which policy to trust.
This issue often appears after adding a new email platform such as Google Workspace, Microsoft 365, Mailchimp, SendGrid, HubSpot, or Zendesk without consolidating older settings.
Combine all authorized senders into one SPF record rather than creating a separate record for each service.
Example of a consolidated SPF record
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all
That structure authorizes Google Workspace, SendGrid, and one explicit IP address, then rejects everything else.
Confirm the Sending Service Is Covered
One of the most common reasons SPF is not working is that the service sending the message is not included in the record.
Many organizations believe they have authorized their mail provider, but the actual mail stream comes from a different system.
Check whether the message is sent by:
- A primary mailbox platform such as Microsoft 365 or Google Workspace
- A marketing automation tool such as Mailchimp, Klaviyo, or HubSpot
- A transactional email platform such as SendGrid, Amazon SES, Mailgun, or Postmark
- An internal application, printer, scanner, or ticketing system
- A third-party vendor sending on your behalf
Each sender may need its own SPF mechanism, and each platform usually documents the required entry.
Use the official vendor SPF guidance rather than guessing the include domain.
Check for DNS Lookup Limits
SPF has a strict limit of 10 DNS lookups during evaluation.
If your record uses too many include, mx, a, or redirect mechanisms, receivers may stop with a PermError.
This is a frequent failure point for domains that stack multiple third-party services.
A single include can trigger additional nested lookups, so the effective total rises quickly.
How to reduce lookups
- Remove unused or outdated senders
- Replace broad includes with explicit
ip4orip6addresses when appropriate - Ask vendors whether they offer a flatter SPF mechanism
- Separate internal systems from marketing tools if possible
Tools that flatten SPF can reduce lookups, but use them carefully.
Over-flattening can create maintenance issues when vendor IP ranges change.
Make Sure the Record Exists on the Correct Domain
SPF checks are tied to the envelope-from domain, also known as the return-path or MAIL FROM domain.
If your business sends mail from multiple subdomains, the SPF record must exist where the receiver expects it.
For example, mail sent as [email protected] may require an SPF record on news.example.com, not only on example.com.
This is especially important for SaaS tools that use custom return-path domains or branded tracking domains.
Review IP Addresses and Dynamic Servers
If you authorize a sending IP with ip4: or ip6:, the address must be exact.
A single digit error makes the record ineffective.
Also, SPF is not suitable for dynamic residential IPs or networks that change frequently.
When you operate your own mail server, confirm the outbound IP in your mail logs and compare it with the SPF record.
If your server uses a cloud provider such as AWS, Azure, or Google Cloud, verify whether the platform applies NAT, load balancing, or relays that alter the public IP address.
Test the SPF Record with Real Mail Headers
DNS lookup tools are useful, but the strongest evidence comes from actual message headers.
Send a test email to a mailbox you control and inspect the Authentication-Results header, Received-SPF header, or equivalent diagnostic fields.
Look for these clues:
- The domain used for SPF evaluation
- The sending IP address
- The SPF result and reason for failure
- Whether the message was routed through an unexpected relay
Email providers such as Gmail, Outlook, and Yahoo often expose header details that show exactly where the SPF check failed.
That makes it easier to fix the record instead of making broad changes blindly.
Understand How SPF Interacts with DKIM and DMARC
SPF rarely works alone in modern email authentication.
DKIM signs the message content, while DMARC uses SPF and DKIM alignment to determine policy.
A message can pass SPF and still fail DMARC if the authenticated domain does not align with the visible From address.
If you are troubleshooting deliverability, check whether the issue is actually DMARC alignment rather than SPF itself.
In many environments, a properly configured DKIM record can preserve authentication even when SPF is affected by forwarding or mailing list rewriting.
Fix Forwarding and Mailing List Issues
Forwarded mail often breaks SPF because the forwarding server changes the sending IP.
The original sender may have valid SPF, but the recipient sees the forwarder’s IP instead.
Mailing lists can also alter headers and cause SPF to fail at the final destination.
In these cases, SPF failure does not always mean the original sender is misconfigured.
This is one reason DMARC and DKIM are important, because DKIM can survive forwarding better than SPF alone.
A Simple Troubleshooting Checklist
- Confirm the exact sender domain and outbound IP
- Ensure there is only one SPF TXT record
- Check that the record starts with
v=spf1 - Verify every active mail service is included
- Stay under the 10 DNS lookup limit
- Publish the record on the correct root domain or subdomain
- Inspect live headers from a test message
- Check DMARC and DKIM if SPF appears correct but delivery still fails
When to Update or Simplify Your SPF Strategy
If your organization uses many email services, the best long-term fix may be simplification.
Limit the number of systems allowed to send mail, retire unused vendors, and standardize outbound traffic through a small number of approved platforms.
A lean SPF record is easier to maintain, less likely to hit DNS limits, and faster to audit during an incident.
For larger organizations, document who owns each sender, what domain it uses, and which DNS changes are required before a new service goes live.
Tools That Help Diagnose SPF Problems
Several reputable tools can help you validate records and inspect authentication results, including MXToolbox, dmarcian, Google Admin Toolbox, Microsoft message trace, and vendor-specific email diagnostics.
These tools can reveal malformed syntax, excess lookups, missing includes, and sender mismatches.
Use them alongside your DNS provider’s control panel and your mail server logs.
The combination of DNS data, message headers, and vendor documentation usually identifies the root cause quickly.