SPF failed: why it happens and how to fix it

You’re looking at a DMARC report or an email header, and there it is: SPF failed. Maybe spf=fail, maybe spf=softfail, maybe the dreaded spf=permerror. Your email landed in spam, or got rejected outright.

Now what?

SPF failures have different causes, and each needs a different fix. Before you start editing DNS records, let’s figure out what actually went wrong.

The difference between SPF failing and SPF alignment failing

This trips up a lot of people, so let’s clear it up first.

SPF failing means the sending server’s IP address was not authorized by your SPF record. The SPF check itself returned fail, softfail, or error.

SPF alignment failing means SPF passed (the IP was authorized), but for DMARC purposes, the domain checked by SPF does not match your From header domain. SPF worked fine. DMARC just does not count it.

Different problems, different solutions.

When you use a third-party service like SendGrid or Mailchimp, they often set the Return-Path (envelope sender) to their own domain for bounce handling. SPF passes because their IP is authorized for their domain. But your From header shows your domain. The domains do not match, so SPF alignment fails.

The fix for alignment issues is usually DKIM, not SPF. You configure your third-party sender to sign emails with your domain, and DKIM alignment passes instead. We explain this in detail in our guide on DMARC, SPF, and DKIM alignment.

For the rest of this article, we’re focusing on actual SPF failures, where the SPF check itself does not pass.

Cause 1: No SPF record published

The simplest failure: your domain has no SPF record at all.

When a receiving server looks up your SPF record and finds nothing, most treat it as neutral (neither pass nor fail). Some stricter receivers treat it as a soft failure. Either way, without SPF you’re relying entirely on DKIM for DMARC authentication.

Run your domain through our DMARC checker. If no SPF record appears, you need to create one. Our SPF generator helps you build a record that includes all your legitimate sending sources. Publish it as a TXT record at your domain’s root.

Cause 2: The sending IP is not in your SPF record

This is the most common legitimate SPF failure. An email was sent from an IP address your SPF record does not authorize.

This happens when:

• Someone configured a new email service but forgot to update SPF
• An employee is using an email tool the IT team does not know about (shadow IT)
• Your mail server’s IP changed and no one updated the SPF record
• Someone is actually spoofing your domain

Look at the source IP in your DMARC reports or email headers. Then check your SPF record to see if that IP (or a range containing it) is listed. The IP might be included directly, or through an include: mechanism for a third-party service.

If the IP belongs to a legitimate service, add it to your SPF record. Add the appropriate include: mechanism for services you use. If you do not recognize the IP and cannot trace it to anyone in your organization, it might be a spoofing attempt. In that case, SPF is correctly rejecting it.

For more on identifying unknown senders, see our article on building a sender inventory.

Cause 3: SPF PermError (too many DNS lookups)

SPF has a hard limit of 10 DNS lookups during evaluation. This limit exists to prevent denial-of-service attacks, but it catches many organizations off guard. The limit is lower than you’d think, and modern companies often use enough email services to blow past it.

Every include:, a:, mx:, ptr:, and redirect: mechanism triggers a DNS lookup. The lookups are recursive. If your include:_spf.google.com points to a record that contains more includes, all of those count toward your limit.

When a receiver evaluates your SPF record and hits the 10-lookup limit, it returns a PermError. This counts as an SPF failure. Every email from your domain fails SPF, regardless of which authorized server sent it.

Use our domain checker to see your total DNS lookup count. If you see “PermError” in your DMARC reports or the checker shows more than 10 lookups, you have hit the limit.

You have several options:

• Remove includes for services you no longer use
• Replace some includes with direct IP addresses (if the service has stable IPs)
• Move some sending to subdomains, each with its own SPF record and lookup budget
• Consider SPF flattening (with caution, as it requires ongoing maintenance)

Our SPF generator shows lookup counts in real-time as you build your record, helping you stay under the limit. For more detail on the 10-lookup trap, see our guide on SPF overview and its limitations.

Cause 4: SPF SoftFail vs HardFail

SPF records end with an all mechanism that tells receivers what to do with messages that do not match any authorized source.

-all (HardFail) means reject emails that do not match. This is the recommended setting for domains with mature email authentication.

~all (SoftFail) means treat non-matching emails as suspicious but do not outright reject them. This was common during early SPF adoption but provides weaker protection.

?all (Neutral) means neither pass nor fail. Rarely useful.

If you’re seeing spf=softfail in your reports, your SPF record probably ends with ~all. This is not necessarily a problem. SoftFail is intentionally less strict and lets receivers make their own decisions.

However, if you’re seeing SoftFail for emails you expect to pass, you still have a configuration issue. Probably an IP not in your record or a service not included.

Once you have verified all your legitimate sending sources are in your SPF record, change from ~all to -all for stronger authentication. Just make sure DKIM is also working, since SPF often fails due to forwarding.

Cause 5: Forwarding breaks SPF

Forwarding is a structural problem you cannot fix on your end.

Here’s what happens:

1. You send an email to [email protected]
2. The university server checks SPF. Your IP is authorized. SPF passes.
3. Alice has forwarding set up to her personal Gmail account
4. The university server forwards the email to Gmail
5. Gmail checks SPF. It sees the university’s IP, not yours.
6. Your SPF record does not authorize the university’s IP. SPF fails.

This is not a bug. This is how SPF works. SPF validates the connecting IP address, and after forwarding, that IP belongs to the forwarder, not you.

In your DMARC reports, look for SPF failures from recognizable forwarding sources: universities, ISPs, or companies known for forwarding (like alumni email services). If DKIM is passing for these messages, DMARC still passes overall.

You cannot fix this directly. The solution is to ensure DKIM is properly configured and survives the forwarding journey. DKIM signatures are embedded in the message and do not depend on the delivering server’s IP.

For a deeper explanation, see our article on why forwarding and mailing lists break DMARC.

Cause 6: Multiple SPF records

DNS allows multiple TXT records at the same name. Some administrators accidentally add a new SPF record instead of updating the existing one.

When a receiver finds multiple SPF records (multiple TXT records starting with v=spf1), it returns a PermError. The situation is ambiguous, so SPF fails entirely.

Look up your domain’s TXT records:

dig TXT yourdomain.com +short

You should see exactly one record starting with v=spf1. If you see two or more, that is the problem. Consolidate your SPF records into a single record that includes all authorized sources. Delete the duplicates.

Cause 7: Syntax errors in your SPF record

SPF records have strict syntax requirements. Common mistakes include:

• Missing spaces between mechanisms
• Using include instead of include: (missing colon)
• Incorrect IP format (like ip4:192.168.1 instead of ip4:192.168.1.0/24)
• Typos in mechanism names
• Record not starting with v=spf1

Any syntax error can cause the entire record to fail parsing, resulting in a PermError or unpredictable behavior.

Use our domain checker to validate your SPF record syntax. It flags parsing errors. Our SPF generator produces syntactically correct records, so consider using it to avoid these mistakes entirely.

How to troubleshoot SPF failures step by step

When you see SPF failures in your DMARC reports, work through this process.

First, identify the source. Look at the source IP in the report. What server or service does it belong to? Sometimes the organization name is included. You can also do a reverse DNS lookup on the IP.

Second, check if the source is legitimate. Is this a service your organization uses? Did someone recently configure a new email tool? Or is this completely unrecognized?

Third, verify your SPF record. Use our domain checker to see your current SPF record and its evaluation status. Check the DNS lookup count. Look for syntax errors.

Fourth, determine the failure type. Is it a simple “not in record” failure? A PermError from too many lookups? A forwarding situation? Each requires a different response.

Fifth, apply the appropriate fix. If a legitimate service is missing, add it to your SPF record. If you hit the lookup limit, optimize your record by removing unused includes or using direct IPs. If it is forwarding, ensure DKIM is working. If it is spoofing, SPF is working correctly by rejecting it.

Finally, monitor after changes. After updating your SPF record, watch your DMARC reports for the next few days. DNS changes take time to propagate, and you want to confirm the fix worked.

When SPF fails but you should not panic

Some SPF failures are expected and not a sign of problems.

Forwarded email will almost always fail SPF. If DKIM passes and DMARC passes overall, you’re fine.

Mailing lists modify messages and send from their own servers. SPF will fail for your domain. This is expected behavior. Modern lists often rewrite the From header to avoid this issue entirely.

Low-volume failures from random IPs are often spam or phishing attempts that your SPF record is correctly rejecting. This is SPF working as intended.

Focus your attention on high-volume failures from recognizable infrastructure, or failures that affect legitimate email delivery.

FAQ

Why does SPF fail when I use Gmail or Office 365?

If you send through Google Workspace or Microsoft 365, your SPF record needs to include their servers. For Google, add include:_spf.google.com. For Microsoft, add include:spf.protection.outlook.com. Without these includes, emails sent through these services will fail SPF.

Can SPF pass but DMARC still fail?

Yes. This happens when SPF passes but alignment fails. The domain validated by SPF (the Return-Path domain) does not match your From header domain. DMARC requires alignment, so SPF passing alone is not enough. This is common with third-party email services. See our alignment guide for details.

What is the difference between SoftFail and HardFail?

SoftFail (~all) tells receivers the message is suspicious but does not instruct them to reject it. HardFail (-all) explicitly says to reject messages from unauthorized sources. HardFail is stronger but relies on you having a complete SPF record. Many organizations start with SoftFail and move to HardFail once they confirm all legitimate sources are included.

How do I know if SPF failed because of forwarding?

Look at the source IP in your DMARC reports. If it belongs to universities, ISPs, or companies known for forwarding (and not your own infrastructure), forwarding is likely the cause. Another clue: if DKIM passes but SPF fails for these messages, forwarding is almost certainly the reason.

Should I add every possible IP to my SPF record?

No. You should only include IPs and services that legitimately send email on your behalf. Adding unnecessary entries increases your lookup count and weakens your security posture. If someone is spoofing your domain, you want SPF to fail for their messages.

Monitor your SPF authentication

Troubleshooting SPF failures is much easier when you can see what is happening. Our DMARC monitoring shows you which sources are passing and failing SPF, with trends over time.

Check your domain now with our free DMARC checker to see your current SPF record and spot issues before they affect delivery.