6 most common SPF failures and how to fix them

Your emails are authenticated, your DNS looks clean, and your deliverability is solid. Then one day, a new marketing platform goes live, someone tweaks a DNS record, and suddenly half your email lands in spam. Sound familiar?

SPF (Sender Policy Framework) failures are one of the most common email authentication problems we see across the 1,200+ organizations using Red Sift OnDMARC. And in 2026, with Google, Yahoo, and Microsoft all enforcing authentication requirements for bulk senders, a broken SPF record doesn’t just hurt deliverability. It cuts off communication with your customers entirely.

SPF is one of three core email authentication protocols, alongside DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance). It works by publishing a DNS TXT record that lists which IP addresses and servers are authorized to send email for your domain. When a receiving mail server gets a message, it checks the sending IP against your SPF record. If there’s no match, the email fails authentication.

Here’s why that matters right now. In February 2024, Google and Yahoo began requiring all bulk senders (5,000+ messages per day) to authenticate emails with SPF and DKIM and publish a DMARC record [1]. Microsoft followed suit in May 2025, applying the same requirements for Outlook.com, Hotmail.com, and Live.com addresses [2]. Together, these three providers handle roughly 90% of a typical B2C email list. One broken SPF record can cut off delivery to the vast majority of your audience overnight.

The stakes go beyond deliverability, too. The FBI’s 2024 Internet Crime Report recorded 193,407 phishing and spoofing complaints, making it the most-reported cybercrime category, with total internet crime losses reaching $16.6 billion, a 33% increase from 2023 [3]. Business email compromise (BEC) alone accounted for $2.77 billion in losses from 21,442 incidents [4]. Properly configured email authentication, starting with SPF, is your first line of defense against domain impersonation.

And it’s not just inbox providers pushing the issue. PCI DSS v4.0.1, effective March 2025, mandates DMARC at quarantine or reject for organizations processing card payments [5]. CISA BOD 18-01 requires p=reject for US federal domains. The UK’s NCSC, Australia’s ASD, and Canada’s CCCS all mandate DMARC for government domains. Cyber insurers increasingly require DMARC enforcement as an underwriting condition. For a full breakdown, see our global DMARC mandates and guidance overview.

The bottom line: SPF failures in 2026 aren’t a minor inconvenience. They’re a deliverability, compliance, and security problem rolled into one.

Let’s break down the six most common SPF failures we see and how to fix each one.

What it looks like: Emails from a legitimate sending service (your CRM, helpdesk tool, or HRP/ERP system) fail SPF because their IP addresses aren’t listed in your SPF record.

Why it happens: This is the most common SPF failure, and it usually comes down to one thing: someone set up a new sending service and didn’t update DNS. Your support team starts using Zendesk for customer emails. Your engineering team integrates an ERP for transactional notifications. Each of these services sends email using your domain, and each needs to be explicitly authorized in your SPF record.

The problem compounds over time. Organizations acquire companies that use different sending systems. Vendors change IP addresses without notification. A trial account for an email service gets promoted to production, but nobody loops in the team managing DNS. Enterprise organizations running Salesforce, SAP, or Zendesk alongside their primary email infrastructure are especially prone to gaps.

How to fix it:

Start by auditing every service that sends email using your domain. Check your DMARC aggregate reports, as they show exactly which IP addresses are sending on your behalf and whether they’re passing or failing SPF. If you’re using Red Sift OnDMARC, the platform automatically identifies unauthorized senders and flags them for action.

Once you’ve identified all legitimate sending sources, add their SPF mechanisms to your record. Each email service publishes its own include mechanism, something like include:spf.protection.outlook.com for Microsoft 365 or include:_spf.google.com for Google Workspace.

A practical example. Say you’re using Google Workspace,and Zendesk. Your SPF record should look something like:

v=spf1 include:_spf.google.com include:mail.zendesk.com ~all

Pro tip: Schedule a quarterly SPF audit. Every time you onboard a new vendor or decommission an old one, update DNS. DMARC reports make this easy. They tell you exactly what’s sending and what’s failing, so you’re never guessing. Also, remove SPF records that should not be there because of SPF alignment (more on that later!).

What it looks like: Your SPF record returns a PermError (permanent error), and all email from your domain fails SPF authentication. Every message. Not just some.

Why it happens: RFC 7208 (the SPF specification) caps SPF evaluation at 10 DNS mechanism lookups per check [6]. The include, a, mx, and exists mechanisms, plus the redirect modifier, all count toward this limit. The ip4, and ip6, mechanisms don’t count because they contain literal values and require no additional DNS resolution.

The math gets tight fast. A typical Microsoft 365 includes 2 lookups. Google Workspace uses 4. Add SendGrid (1), Salesforce (2), and a couple more services, and you’re over the limit before you know it. Each include can also contain nested includes, and those count too. It’s 10 total DNS queries, including all the recursive lookups triggered by nested include chains.

When the count exceeds 10, if the IP has not been found before the 11th lookup, the receiving mail server returns a PermError and stops evaluating. DMARC interprets this as SPF fail [7]. Your emails get rejected or routed to spam, and you’re left relying entirely on DKIM, which doesn’t help if DKIM signing wasn’t configured for a particular sending service.

There’s also a less well-known limit: the 2-void-lookup rule. If two DNS queries during SPF evaluation return NXDOMAIN (domain doesn’t exist) or an empty answer, a third void lookup triggers a PermError [8]. This commonly happens when an include points to a domain that no longer publishes an SPF record, like a decommissioned vendor.

How to fix it:

First, count your current lookups. Use Red Sift Investigate to query your SPF record and see exactly how many DNS lookups it requires.

Then reduce the count:

• Remove decommissioned services. If you cancelled that Mailchimp account six months ago but left the include in your SPF record, remove it. Old CRM systems, trial email tools, and includes added by former employees are common culprits.
• Remove ptr mechanisms.ptr mechanisms. The SPF specification strongly discourages their use, as they are now deprecated, and they waste lookups.
• Delegate sending services to subdomains. Each subdomain gets its own SPF record with its own 10-lookup budget. Route marketing email through info.yourdomain.com with its own SPF record, keeping your root domain’s record lean.

For organizations that can’t get under 10 lookups through manual optimization, Red Sift OnDMARC’s Dynamic SPF solves this automatically. Dynamic SPF replaces your complex SPF record with a single smart include that resolves to only the IP addresses actively sending for your domain. You manage sending services through the OnDMARC platform instead of editing DNS manually, and the lookup count stays within limits.

What it looks like: SPF authentication fails across all email, or the record isn’t recognized as an SPF record at all. You might see PermError or None results in DMARC reports.

Why it happens: SPF records follow strict formatting rules defined in RFC 7208. Minor mistakes break the entire record. Common syntax errors include:

• Missing or incorrect version tag. Every SPF record must start with v=spf1. Typos like v=spf2 or v=spf11, or even an extra space before the tag, invalidate the whole record.
• Missing spaces between mechanisms. Each mechanism must be separated by a single space. Something like include:_spf.google.cominclude:mail.zendesk.com (no space between them) breaks evaluation.
• Incorrect mechanism formatting. The ip4 and ip6 mechanisms require a colon before their values (ip4:192.168.1.1), not an equals sign or slash.
• Misspelled mechanisms. Typing incldue instead of include or ipv4 instead of ip4 invalidates the mechanism.
• Using the deprecated ptr mechanism.ptr mechanism. While technically still parsed, ptr is strongly discouraged by RFC 7208 and marked deprecated and creates unnecessary DNS load.

These errors affect 100% of your email. A receiving server encounters the syntax issue, can’t parse the record, and returns either PermError (if it partially evaluates) or None (if it can’t identify the record as SPF at all).

How to fix it:

Run your SPF record through a validator before publishing any changes. Red Sift Investigate checks for syntax errors, lookup counts, and other misconfigurations in seconds.

Here’s a clean SPF record structure to use as a reference:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

Notice: v=spf1 at the start, spaces between every mechanism, colons (not equals signs) after ip4, and a single ~all qualifier at the end. Always validate after making changes, then wait up to 24 hours for DNS propagation and check your DMARC reports for unexpected failures.

What it looks like: SPF returns a PermError, and all email authentication via SPF fails. This is a total failure, not a partial one.

Why it happens: The SPF specification requires exactly one SPF TXT record per domain [6]. When a domain has two or more SPF TXT records, receiving servers can’t determine which one to use and return a PermError.

This usually happens when different teams manage different parts of the email infrastructure. The IT team publishes an SPF record for Microsoft 365. The marketing team adds a separate record for their email platform. A third-party consultant adds another one for a deliverability project. Nobody checks whether a record already exists, and suddenly you’ve got three SPF records on the same domain, all of them useless.

It can also happen during migrations. Moving from Google Workspace to Microsoft 365? If the old Google SPF record isn’t removed when the new Microsoft one is added, you end up with two records and a broken configuration.

How to fix it:

Query your domain’s TXT records and look for entries starting with v=spf1. You should see exactly one. If there are multiple, merge all authorized sending sources into a single record.

For example, if you have:

Record 1: v=spf1 include:spf.protection.outlook.com ~all Record 2: v=spf1 include:_spf.google.com ~all

Merge them into:

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

Then delete the extra record. After merging, validate the combined record to confirm it doesn’t exceed the 10-lookup limit. Centralizing DNS management and requiring change approval helps prevent this from recurring. If multiple teams need to modify email sending infrastructure, use a platform like Red Sift OnDMARC where sending sources are managed through a single interface.

What it looks like: Emails pass SPF when delivered directly but fail when forwarded to another address or distributed through a mailing list. Your DMARC reports show SPF failures from IP addresses belonging to known forwarders (universities, ISPs, corporate mail servers).

Why it happens: This is a fundamental limitation of how SPF works, and it’s the one failure on this list that isn’t caused by a misconfiguration.

SPF checks whether the sending server’s IP address is authorized by the sender’s domain. When an email is forwarded, the forwarding server (Server B) sends the message to the final destination (Server C) using its own IP address. Server C checks that IP against the original sender’s SPF record and finds no match, because the forwarder’s IP was never authorized. SPF fails.

Mailing lists make things worse. They often modify the message body (adding footers, list headers, or unsubscribe links), which can also break DKIM signatures. If both SPF and DKIM fail, DMARC fails too.

This is by design. SPF was built for direct delivery paths, and it has no mechanism for handling intermediary servers.

How to fix it:

You can’t "fix" SPF for forwarded email in the traditional sense, but you can build a resilient authentication setup that compensates:

• Make DKIM your primary authentication backstop. DKIM is content-based, not path-based. As long as the message body isn’t modified during forwarding, the DKIM signature remains valid and DMARC passes. Make sure every sending service signs emails with DKIM using your domain. For a full walkthrough, see our guide to SPF, DKIM, and DMARC configuration. Our email protocol configuration guide also covers DKIM key management, selector setup, and troubleshooting in detail.
• Use ~all (soft fail), not -all (hard fail). Some receiving servers evaluate SPF before DMARC. With -all, they may reject the message at the SMTP level before DKIM or DMARC gets a chance to evaluate. Soft fail lets the message through to DMARC processing, where a valid DKIM signature can save it. Current industry guidance in 2026 favors ~all for actively sending domains [9]. Combined with DMARC at p=reject, you get the same enforcement without the early-rejection risk.
• Understand ARC (Authenticated Received Chain). ARC is a protocol that allows intermediary servers to preserve original authentication results. When a trusted forwarder (like Gmail or Microsoft 365) seals the original SPF and DKIM results, the final destination server can reference those results even if SPF fails at the last hop. ARC is applied automatically by major providers, so you don’t need to configure it on the sending side [10].

Note: The IETF just approved an initiative to officially deprecate ARC. DKIM2 is expected to take its place.DKIM2 is expected to take its place.

• Monitor forwarding-related failures in DMARC reports. Separate forwarding failures from actual spoofing attempts. Forwarding traffic typically comes from recognizable mail server IPs (mail.university.edu, corporate relay servers) and shows SPF fail with DKIM pass. Spoofing attempts come from unknown IPs with both SPF and DKIM failing.

What it looks like: SPF passes (the sending IP is authorized), but DMARC still fails. This confuses a lot of people, because they assume SPF pass equals DMARC pass. It doesn’t. For a deeper look at how SPF, DKIM, and DMARC work together, the distinction matters.

Why it happens: DMARC requires alignment between the domain that passes authentication and the domain in the visible From header. For SPF, this means the domain in the Return-Path (also called the bounce address, envelope from, or MAIL FROM) must match, or be a subdomain of, the domain in the From header that your recipients see.

Many third-party sending services use their own domain as the Return-Path by default. Salesforce, for example, uses its own domain for bounce handling unless you explicitly configure it otherwise. SPF checks the Return-Path domain, finds Salesforce’s IP in Salesforce’s SPF record, and SPF passes. But DMARC then checks alignment: "Does the Return-Path domain match the From header domain?" If your From header says @yourdomain.com and the Return-Path says @bounce.salesforce.com, alignment fails. SPF passes authentication, but will fail alignment. If you cannot align SPF, then DKIM becomes even more crucial.

This is where most organizations get stuck, especially during DMARC implementation. They configure SPF correctly, and then can’t figure out why DMARC still isn’t working or SPF still fails.

How to fix it:

For each sending service, configure the Return-Path (bounce address) to use your domain or a subdomain of your domain. The specifics vary by platform:

• Salesforce: Disable bounce management to have Salesforce use your domain as the Return-Path instead of theirs.
• Microsoft 365: Return-Path alignment is handled automatically when using your custom domain.
• Marketing platforms (HubSpot, Marketo, Mailchimp): Most offer custom Return-Path or envelope-from settings. Check each platform’s documentation for setup instructions.

DMARC supports two alignment modes:

• Strict alignment (aspf=s):aspf=s): The Return-Path domain must exactly match the From domain.
• Relaxed alignment (aspf=r):aspf=r): The Return-Path domain can be a subdomain of the From domain. This is the default and is recommended for most organizations.

With relaxed alignment, if your From header is @yourdomain.com and the Return-Path is @mail.yourdomain.com, alignment passes. This gives you flexibility to use subdomains for different sending services while maintaining DMARC compliance.

The key diagnostic tool here is your DMARC aggregate reports. They show SPF pass/fail status alongside alignment status, making it clear whether the problem is authorization (SPF itself) or alignment (the domain match between Return-Path and From).

Red Sift OnDMARC breaks this down visually, so you can see at a glance which senders are passing SPF but failing alignment, and exactly which domain mismatch is causing the issue. Start your step-by-step DMARC implementation to work through each sender systematically.

DMARC aggregate reports contain everything you need to identify and fix SPF failures. Here’s what to look for:

If you’re analyzing DMARC reports manually (parsing XML), you’re spending hours on work that a platform can do in seconds. Red Sift OnDMARC transforms raw aggregate report data into clear, actionable dashboards that show exactly which senders are failing, why they’re failing, and how to fix them. For a walkthrough of the best tools to use at each stage, see our top email authentication tools guide.

SPF failures are fixable. Every one of the six failures covered in this guide has a clear diagnostic path and a concrete solution. The real challenge isn’t complexity. It’s visibility.

Without DMARC reporting, you’re flying blind. You don’t know which services are sending as your domain, which are failing authentication, or why. With it, every failure becomes a line item you can investigate and resolve.

If you’re dealing with SPF failures right now, start with a free scan using Red Sift Investigate to see your current record status. For ongoing monitoring, automated sender management, and a clear path to DMARC enforcement, start a free trial of Red Sift OnDMARC.

[1] An update on bulk sender requirements - Google

[2] Strengthening Email Ecosystem - Microsoft Community Hub

[3] FBI Releases Annual Internet Crime Report

[4] 2024 IC3 Annual Report

[5] PCI DSS v4.0.1 Summary of Changes

[6] RFC 7208 - Sender Policy Framework (SPF)

[7] The SPF lookup limit explained - Mailhardener

[8] RFC 7208 Section 4.6.4 - DNS Lookup Limits

[9] SPF failures: Hard fail vs Soft fail - Red Sift

[10] ARC: Solving the DMARC Problem with Email Forwarding - Mailflow Authority