Proudly Canadian 
SPF record errors are behind a significant portion of the email deliverability problems we see. The frustrating thing about them is that the sending side shows no error at all. Your mail server reports a successful send, the message leaves your server without issue, and you have no indication that anything went wrong until someone tells you they did not receive your email, or you discover it in their spam folder.
SPF errors happen at the receiving end, when the destination mail server checks your DNS to verify whether the server that sent your message was authorized to do so. If your SPF record is missing, duplicated, syntactically incorrect, or exceeds the lookup limit, that check fails and the message is treated as suspicious or rejected outright depending on how the receiving server handles SPF failures.
This guide covers how SPF validation actually works, what each type of error means, how to diagnose which error you have, and how to fix it correctly so the problem does not return.
Quick Fix Summary
- Ensure your domain has exactly one SPF TXT record, no more
- Merge all sending services into that single record
- Keep the total DNS lookup count at or below 10
- Verify the record using MXToolbox or Google Admin Toolbox before considering it done
- Check email headers after fixing to confirm SPF is passing
How SPF Validation Works
SPF, or Sender Policy Framework, is a DNS record that lists every server authorized to send email on behalf of your domain. When a message arrives at a receiving mail server, that server extracts the sending IP address and your domain from the message envelope, then queries your DNS for an SPF record. It evaluates whether the sending IP matches any of the authorized sources listed in your record. If it does, SPF passes. If it does not, or if the record is invalid, SPF fails.
The important technical detail here is that SPF checks the envelope sender, also called the Return-Path or MAIL FROM address, not the visible From address that recipients see in their email client. This is why SPF alone does not fully prevent email spoofing. A sender can craft an email where the envelope sender passes SPF while the visible From header shows a completely different domain. This is one of the reasons DMARC exists, to enforce alignment between the SPF-authenticated domain and the visible From address.
SPF results fall into several categories. A pass means the sending IP was authorized and the record was valid. A fail, sometimes written as hardfail, means the sending IP was explicitly not authorized. A softfail means authorization failed but the record instructed receiving servers to accept the message anyway and mark it rather than reject it. A permerror means the record itself is invalid, typically due to a syntax error or exceeding the lookup limit. A temperror means the DNS query could not be completed at that moment due to a temporary infrastructure issue.
Permerror is the outcome most commonly caused by the configuration mistakes covered in this guide, and it is the most important to fix because it causes SPF to fail completely for every message you send until the record is corrected.
Step 1: Check What Is Currently in Your DNS
Before making any changes, you need to see exactly what your DNS currently contains. The most direct way to do this from a command line is:
dig TXT yourdomain.com
Look through the TXT records returned for any line containing v=spf1. If you see more than one such line, you have a duplicate SPF record problem that needs to be resolved before anything else.
If you prefer a browser-based tool, MXToolbox at mxtoolbox.com/spf.aspx is the most useful option. Enter your domain and it returns your SPF record, validates the syntax, counts the number of DNS lookups the record requires, and flags any specific errors. Google Admin Toolbox at toolbox.googleapps.com provides similar output with slightly different error messaging.
Make a note of everything currently in your SPF record before changing anything. If you are merging or rewriting the record, you need to ensure that no authorized sending source is accidentally dropped in the process.
The Most Common SPF Errors and How to Fix Each One
Multiple SPF records on the same domain
This is the most common error and one of the most damaging. RFC 7208, the technical specification that defines how SPF works, is explicit: a domain must not have more than one TXT record that begins with v=spf1. When a receiving server finds two or more, it cannot determine which one is authoritative and returns a PermError. Every message you send will fail SPF until this is resolved, regardless of how correct the individual records appear to be.
This situation typically arises when someone adds a new email service and creates a second SPF record instead of editing the existing one, or when a DNS zone was migrated and records were duplicated in the process.
The fix is to delete all but one of the SPF records and merge all the include directives into the single remaining record. If you have:
v=spf1 include:_spf.google.com ~all
v=spf1 include:mailgun.org ~all
Delete both and replace with a single record that contains everything:
v=spf1 include:_spf.google.com include:mailgun.org ~all
Only one TXT record starting with v=spf1 should exist on your domain at any time.
Exceeding the 10 DNS lookup limit
SPF evaluation involves DNS lookups. Each include: directive in your record requires the receiving server to look up the SPF record of the included domain to find the authorized IPs. The a, mx, and exists mechanisms also trigger lookups. SPF allows a maximum of 10 lookups during a single evaluation. If your record requires more, the evaluation returns a PermError and SPF fails.
The problem is that each include: statement may itself contain further include: statements, which each count toward your limit. A record that looks like it has five includes may actually trigger eight or nine lookups once the nested references are followed.
To find out how many lookups your record currently requires, use MXToolbox's SPF checker. It counts the lookups explicitly and flags records that exceed the limit.
There are several approaches to resolving a lookup count that is too high. The cleanest is to replace include: directives with the actual IP ranges they resolve to, using ip4: and ip6: mechanisms instead. These do not trigger DNS lookups and therefore do not count against the limit. For example, if you know the exact IP ranges your mail service uses:
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all
The trade-off is that IP ranges for third-party services can change without notice, requiring you to update your record when they do. Services that frequently change their IP ranges are better left as include: directives with the understanding that you will need to manage the lookup count carefully.
Another option is SPF flattening, where a script or service periodically resolves all the nested includes in your record and replaces them with the resulting IP list, removing the lookup dependency entirely. Tools like AutoSPF or dmarcly.com offer this as a managed service. The downside is that flattened records need regular maintenance as sending service IP ranges change.
Missing include directives for third-party senders
Every service that sends email on behalf of your domain needs to be authorized in your SPF record. This includes your primary email provider, but also your CRM if it sends automated emails, your marketing platform if it sends campaigns, your transactional email service, your support ticketing system, and any other tool that generates outbound mail using your domain in the From or Return-Path address.
A common scenario is a business that sets up Google Workspace and adds include:_spf.google.com to their SPF record, then later starts using Mailchimp, HubSpot, or Zendesk without updating the SPF record. Messages from those services fail SPF because they are not authorized.
Common include directives for frequently used services:
Google Workspace: include:_spf.google.com Microsoft 365: include:spf.protection.outlook.com SendGrid: include:sendgrid.net Mailgun: include:mailgun.org Mailchimp: include:servers.mcsv.net HubSpot: include:hubspotemail.net Zendesk: include:mail.zendesk.com Salesforce: include:_spf.salesforce.com
When adding a new service, check its documentation for the correct SPF include directive. Most major services publish this in their email authentication or DNS setup documentation.
Syntax errors in the record
SPF records must follow a specific format. Common syntax mistakes that cause the record to be invalid include using a semicolon instead of a space between mechanisms, forgetting the v=spf1 prefix, placing all somewhere other than at the end of the record, using include without a colon before the domain, and leaving a trailing space or invisible character in the record value.
A correctly formatted SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 ~all
Each mechanism is separated by a single space. The record starts with v=spf1 and ends with an all mechanism. There are no semicolons, no commas, and no characters outside the defined SPF mechanism syntax.
If you are not certain whether your record syntax is valid, paste it into MXToolbox's SPF checker, which will flag specific syntax errors and show you what each part of the record means.
Using redirect instead of include incorrectly
SPF has two mechanisms for referencing external records: include: and redirect=. They behave differently and are often confused. The include: mechanism imports the mechanisms from another domain's SPF record as if they were written in your own. If the included domain's record passes for the sending IP, the evaluation continues. The redirect= modifier replaces your entire SPF record with the record of the specified domain. It should only be used when you want to delegate SPF entirely to another domain, not when you want to authorize one additional service.
Using redirect= when you meant include: means your entire SPF record is replaced by whatever the redirected domain specifies, removing any other authorizations you had. This is a subtle but consequential mistake.
Verifying Your Fix
After making changes to your SPF record, DNS propagation typically takes between a few minutes and a few hours depending on your registrar's TTL settings. Once propagation is complete, verify the fix using a combination of the following methods.
Run your domain through MXToolbox's SPF checker again. Confirm that it shows exactly one SPF record, that the syntax is valid, that all your sending services are included, and that the lookup count is within the 10-lookup limit.
Send a test email from each service you have authorized in your SPF record to a Gmail address you control. Open the message in Gmail, click the three-dot menu, and select Show Original. Look for the Authentication-Results header near the top of the raw headers. It will contain a line starting with spf= followed by either pass, fail, softfail, or permerror, along with the domain and IP that were checked.
If you see spf=pass, the fix is working. If you still see spf=permerror, the record is still invalid and needs further investigation. If you see spf=fail or spf=softfail for a specific service, that service is not covered by your SPF record and needs its include directive added.
Managing SPF Through Your WHMCS Client Area
If your domain DNS is managed through our platform, you can edit your SPF record directly from your client area without needing to access a separate DNS control panel. Navigate to My Domains, click Manage next to the relevant domain, and select DNS Management. Your SPF record will be listed as a TXT record at the root host, shown as @ or your domain name. Edit the value field directly and save. Changes typically propagate within a few minutes to a few hours depending on the TTL configured for that record.
If you cannot locate the DNS management option or your domain's DNS is managed elsewhere, contact our support team and we can review your current SPF record and advise on the correct changes.
SPF as Part of a Complete Email Authentication Setup
SPF is one of three authentication protocols that together form a complete email authentication setup. Fixing your SPF record is an important step, but in isolation it does not provide full protection against spoofing or guarantee inbox placement.
DKIM adds a cryptographic signature to outgoing messages, which proves the message was not altered in transit and provides an authentication signal that survives email forwarding better than SPF does. DMARC builds on both by enforcing alignment between the authenticated domains and the visible From address, and by providing aggregate reports that show you how your domain is being used and whether authentication is passing across all your sending sources.
If you have fixed your SPF record and want to complete your email authentication setup, the next steps are enabling DKIM through your email provider and publishing a DMARC record starting with p=none to begin monitoring. Both are covered in detail in our DMARC and DKIM configuration guides.
When to Contact Support
If you have verified your SPF record is syntactically correct, contains all your sending services, and stays within the 10-lookup limit, but messages are still failing SPF authentication at specific providers, the issue may involve how a particular service sends on your behalf. Some services send using a subdomain or a Return-Path address that does not match your root domain, which causes SPF to check a different part of your DNS than where your SPF record lives.
Similarly, if you are hitting the lookup limit but cannot reduce your authorized services, an SPF flattening approach may require implementation help. Open a support ticket from your client area with your domain name and a copy of your current SPF record. Our team can identify the specific issue and recommend the right fix.
What Happens If You Have No SPF Record
The queries that bring many people to this guide start from a different place than a broken record. They have no SPF record at all, and they want to understand what that means before they create one. If that is your situation, this section is for you.
When a receiving mail server processes an incoming email from your domain, it checks DNS for an SPF record at your domain's root. If no SPF record exists, the result is neither a pass nor a fail — it is a neutral result called "none." What the receiving server does with a none result is entirely up to its own policy. Some servers treat none the same as a pass and deliver the message normally. Others treat none as a soft fail and apply additional scrutiny. Gmail and Outlook both use the absence of an SPF record as a negative signal in their spam filtering, even if they do not explicitly reject messages on that basis alone.
The more significant consequence of having no SPF record is its interaction with DMARC. If you have a DMARC policy in place and SPF returns none rather than pass, DMARC cannot use SPF for alignment. DMARC requires at least one of SPF or DKIM to pass and align with the From address. Without a passing SPF record, the burden falls entirely on DKIM. If DKIM is also not configured or fails, DMARC will fail, and if your DMARC policy is set to quarantine or reject, your legitimate emails will be blocked or sent to spam.
Creating an SPF record for a domain that has none is straightforward. The minimum viable SPF record that authorises your hosting server to send on behalf of your domain is:
v=spf1 a mx ~all
This record authorises the IP addresses associated with your domain's A record and MX record to send mail. The ~all at the end is a soft fail for anything not covered by the record. If you use Google Workspace for email, the record becomes:
v=spf1 include:_spf.google.com ~all
If you use both your hosting server and Google Workspace, combine them:
v=spf1 a mx include:_spf.google.com ~all
Add this as a TXT record at the root of your domain in your DNS management panel. Once published, allow up to 48 hours for propagation and then verify it is visible using MXToolbox's SPF lookup.
Gotekky
Need help deciding what to do next?
Tell us what you are seeing and what outcome you need. We will identify whether a managed service, scoped project or paid technical assessment is the right next step.