Diagnosis flowchart from DNS lookup count to syntax errors.
If your SPF record is failing, your emails are missing a critical authentication check that email providers use to verify you are an authorized sender. SPF failures show up as spf=fail, spf=softfail, or spf=permerror in email headers. The most common causes are too many DNS lookups in your SPF record, syntax errors, missing include statements for your sending providers, having multiple SPF records on the same domain, or the sending server simply not being listed in the record at all. Each of these has a specific spf fail fix, and diagnosing the exact error type tells you which fix to apply.
Send a test email to a Gmail account and view the original message headers. Look for the SPF result line. If it says permerror, you have a syntax or structural issue with the record itself. If it says fail or softfail, the record exists but the sending server is not authorized. If it says none, no SPF record was found at all. The error type narrows down which of the following fixes applies to your situation.
Your domain should have exactly one TXT record that starts with v=spf1. If you have two or more SPF records, the result is a spf permerror and both records are ignored. This commonly happens when a new service is added and the person configuring it creates a new SPF record rather than adding an include to the existing one. Look up all TXT records for your domain and merge them into a single record that includes all authorized senders.
SPF has a hard limit of 10 DNS lookups per record evaluation. Each include:, a:, and mx: mechanism counts as one or more lookups, and nested includes within included records count too. If your total exceeds 10, the SPF check returns spf too many lookups as a permerror. Use an SPF record analyzer tool to count your lookups. If you are over the limit, remove services you no longer use, replace include statements for services with stable IP addresses with direct ip4: entries, or consider an SPF flattening service that resolves includes into IP addresses.
If you added a new sending provider but did not update your SPF record, emails from that provider will fail SPF. Check that your record includes the correct value for each service you use. Google Workspace uses include:_spf.google.com. Microsoft 365 uses include:spf.protection.outlook.com. Amazon SES uses include:amazonses.com. If you recently connected a new outreach tool or email service, check whether it sends from its own servers and requires an additional include in your SPF record.
SPF syntax errors include missing spaces between mechanisms, typos in include domains, using v=spf1 more than once in the record, or placing the all mechanism before other entries. The all mechanism (~all or -all) must always be the last item in the record. Run your SPF record through a validation tool that checks for syntax errors and highlights the specific problem. A correctly formatted example: v=spf1 include:_spf.google.com include:amazonses.com ~all
After making changes, wait for DNS propagation (usually a few minutes to an hour) and then send another test email to Gmail. Check the original headers again to confirm SPF now shows "pass." Also run your updated record through an SPF checker tool to verify the syntax is clean and the lookup count is within the 10 lookup limit. If the fix does not take effect, clear your local DNS cache and try again, or check whether your DNS provider has a caching layer that delays updates.
Check your SPF record any time you add or remove a sending service. Run periodic checks on your DNS lookup count as services you include may add their own nested lookups over time. Keep a single SPF record per domain and merge changes into it rather than creating additional records. Document which include statement corresponds to which service so you can clean up entries for services you no longer use.
EmailQo runs DNS authentication validation as part of its pre send inbox health checks. If your SPF record is missing, failing, or returning a permerror due to too many lookups, the check flags the issue before your campaign sends. This catches SPF problems at the point where they can be fixed rather than after your deliverability has been affected by failed authentication.
SPF fail (-all) tells receiving servers to reject unauthorized emails outright. SPF softfail (~all) tells them to accept the email but treat it with suspicion. For cold email, softfail is generally recommended because hard fail can cause legitimate emails to be rejected during forwarding scenarios.
SPF flattening services resolve your include statements into direct IP addresses, which do not count as DNS lookups. This effectively lets you authorize more than 10 services. The tradeoff is that if any of those services change their IP addresses, your SPF record becomes stale until the flattening service updates it. Most flattening services check for changes regularly and update automatically.
If the record syntax is correct and the sending service is included, check whether your email is being forwarded through a server that is not in your SPF record. Email forwarding breaks SPF because the forwarding server's IP is not authorized in the original sender's SPF. DKIM survives forwarding, which is one reason having both SPF and DKIM configured is important. Also check that your DNS provider has not silently truncated your record if it exceeds their character limit for TXT records.