SPF Mistakes Report 2026: What Goes Wrong and How Often

Published July 2026 · By The InboxGreen Team · Methodology

Key Findings

SPF Status Across All 1,247 Domains

Most domains have SPF configured. The problem is that having a record is not the same as having it configured correctly. A significant portion of domains have SPF set up in ways that reduce or eliminate protection.

Mistake 1: Softfail Instead of Hardfail (23.2% of all domains)

The most common SPF configuration problem is using ~all (softfail) instead of -all (hardfail). The difference matters: softfail tells receiving servers that unauthorized senders are suspicious, but leaves the final decision to the receiver. Hardfail tells them to reject unauthorized senders outright.

Most major email providers treat softfail leniently. Gmail, in particular, rarely rejects softfail messages on SPF alone. In practice, ~all offers little meaningful protection unless it is combined with an enforced DMARC policy.

Fix: Change ~all to -all at the end of your SPF record. Before doing this, confirm your SPF record covers all your legitimate sending sources. Switching to -all without covering all senders will cause legitimate mail to fail SPF.

Also check your DMARC record. If SPF softfail is the current configuration, moving to -all while simultaneously moving DMARC to p=quarantine or p=reject will give you actual protection.

Mistake 2: No SPF Record (5.5% of all domains)

68 domains in the sample had no SPF record at all. These domains send mail with no SPF authentication. Receiving servers have no way to verify whether the sending server is authorized, so the message may be accepted, flagged, or filtered depending on other reputation signals.

The risk is higher than it might appear. Without SPF, DMARC cannot use SPF alignment to authenticate messages, which removes one of the two authentication paths DMARC relies on. If DKIM is also absent or misconfigured, DMARC fails entirely.

Fix: Create a TXT record at your root domain with your sending sources. A minimal example for a domain using only Google Workspace:

v=spf1 include:_spf.google.com -all

If you use multiple services, add each one. Keep the total DNS lookup count below 10. Use InboxGreen's SPF Lookup to count your lookups after making changes.

Mistake 3: Lookup Limit Exceeded (2.7% of all domains)

SPF allows a maximum of 10 DNS lookups during evaluation (RFC 7208, Section 4.6.4). Mechanisms that trigger DNS lookups include include:, a:, mx:, and redirect=. Each include: may itself contain further lookups, which all count toward the limit.

When the limit is exceeded, SPF returns a PermError. A PermError causes SPF to fail for every message from that domain, regardless of whether the sender is authorized. This is the same result as having a missing SPF record, but it is caused by having too many.

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org include:_spf.salesforce.com -all

Fix: Count your current lookups using an SPF lookup tool before making changes. Then reduce includes by:

• Removing ESP includes for services you no longer use
• Consolidating sending through fewer platforms
• Using IP ranges (ip4: or ip6:) for services that publish static IPs rather than nested includes
• Using an SPF flattening service if consolidation is not possible

Mistake 4: Multiple SPF Records on One Domain (0.7% of all domains)

9 domains had more than one v=spf1 TXT record on the same domain. RFC 7208 specifies that this condition should result in a PermError, which means SPF fails for all mail from the domain. The behavior is technically undefined and mail servers may handle it differently, but most major providers treat it as an error.

This usually happens when a new SPF record is added without removing the old one. It is a common mistake when switching email providers or adding a second ESP to an existing setup.

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

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

Fix: Query your domain's TXT records with dig TXT yourdomain.com +short and confirm there is exactly one line starting with v=spf1. Merge all mechanisms into a single record and delete the extras.

SPF Mistake Summary

Why SPF Errors Matter in 2026

Google and Yahoo's February 2024 sender requirements made SPF authentication mandatory for bulk senders. But SPF alone does not protect against spoofing unless it is paired with an enforced DMARC policy. The compound finding from this data is that most SPF errors are not technical failures; they are configuration choices that leave protection incomplete.

The softfail result, in particular, is often treated as "close enough." The data suggests otherwise: 61% of domains with softfail SPF also lack meaningful DMARC enforcement, meaning neither check is providing real protection. Attackers targeting those domains can spoof the sender address with no automated rejection.

PermError is the other standout. Unlike softfail, a PermError causes SPF to actively fail for every message the domain sends. A domain trying to use SPF correctly but misconfiguring the lookup count ends up in a worse position than a domain with no SPF at all, because PermError signals misconfiguration to receiving servers.

Check and Fix Your Own SPF Record

Methodology

Data collection: InboxGreen recorded SPF check results for domains submitted to the tool between May 1 and July 10, 2026. Only unique apex domains were included. Subdomains were excluded. Domains checked more than once during the period were counted once using the most recent result.

Sample: 1,247 unique domains. The sample is self-selected: these are domains that users actively checked, which may skew toward domains experiencing deliverability problems. The rate of SPF issues in this sample (32.1%) is likely higher than the rate across all email-sending domains.

SPF pass criteria: A domain is marked pass if it has exactly one valid TXT record starting with v=spf1, the record syntax is valid, the total DNS lookup count does not exceed 10, and the all mechanism is -all. Domains using ~all are marked as warn, not pass.

PermError detection: InboxGreen counts DNS lookups recursively through all include:, a:, mx:, and redirect= mechanisms. A PermError is reported when the count exceeds 10 during evaluation.

Multiple record detection: All TXT records at the apex domain are retrieved. If more than one record begins with v=spf1, a multiple-record error is reported.

DMARC correlation: For the softfail analysis, DMARC records were retrieved from the same domains at the same time as the SPF check. DMARC policy was classified as enforced (p=quarantine or p=reject), monitoring-only (p=none), or missing.

Limitations: This data reflects the configuration state at the time of the check. SPF records change over time. Domains that were misconfigured at check time may have since been corrected.

Raw data: Download the aggregate dataset (.csv). Source code and methodology notes are also available on GitHub.