SPF Errors and Fixes: PermError, SoftFail, Multiple Records

June 20, 2026 • InboxGreenEmail Team

Most SPF failures trace back to one of six patterns. You don't need to debug DNS from scratch every time. Find the pattern that matches what you're seeing, apply the fix, and verify with a scan.

Before making changes: check your current SPF record with the SPF Lookup tool or run a full scan at InboxGreen.email/check. Some of the issues below have symptoms that look identical on the surface.

1. PermError: too many DNS lookups

The SPF specification caps DNS lookups at 10 per evaluation. Each include:, a:, mx:, and redirect= mechanism counts as one lookup. The problem is that each of those includes can nest further includes.

A common over-limit record looks innocent at first:

v=spf1 include:sendgrid.net include:servers.mcsv.net include:_spf.google.com include:send.klaviyo.com include:spf.protection.outlook.com ~all

Five top-level includes. But Google's SPF record alone nests three levels deep, and SendGrid's adds two more. By the time a receiving mail server finishes resolving the chain, the counter is over 10 and the result is PermError.

PermError is treated as a hard failure by DMARC. Gmail logs it as a permanent configuration error. Your email can fail DMARC because of this even if every include: would have matched.

How to fix it:

• Use the SPF Lookup tool to count your actual lookup depth
• Remove services you no longer send through (old ESPs are common culprits)
• Replace include: references with flat IP ranges for ESPs that provide them
• For SendGrid and Mailgun, use CNAME-based domain authentication. Their DNS handles the lookups so yours stays under the limit

2. Multiple SPF records on the same domain

RFC 7208 is clear: a domain must not have more than one SPF record published. If your domain has two TXT records that both begin with v=spf1, receivers must return PermError. They are not allowed to pick the "best" one.

This happens most often when someone adds a second SPF record for a new ESP without noticing that one already exists. It also happens after domain migrations when the old record wasn't removed.

How to diagnose it:

dig TXT yourdomain.com +short

Or use the TXT Lookup tool. Look for two lines starting with "v=spf1.

How to fix it:

Merge both records into one. All sending sources go in a single v=spf1 ... ~all record. Delete the old one completely. Your DNS panel should end up with exactly one TXT record starting with v=spf1 for that hostname.

3. ~all vs -all: what the difference actually means

The final mechanism in your SPF record tells receivers what to do with email from IPs not listed in your record:

• ~all (tilde) = softfail. The message came from an unlisted IP, but accept it and mark it.
• -all (hyphen) = hardfail. Reject any message from an unlisted IP.

Many guides recommend ~all as the safe default. The problem is that many spam filters treat softfail the same as hardfail anyway. ~all does not protect you from spam folder placement; it just avoids outright rejection at some receivers.

If you know every IP that sends email on behalf of your domain, use -all. It makes your SPF record more authoritative and prevents spoofing from unlisted addresses.

Stay with ~all if you are still in the process of identifying all your sending sources. Switch to -all once you are confident your record is complete.

4. SPF passes but DMARC still fails (alignment)

This is the most commonly misunderstood SPF scenario. SPF has two results: whether the sending IP is authorized, and whether the domain in the envelope sender matches your From: domain. DMARC requires alignment, not just a pass.

When you send through an ESP, the envelope sender (the address used in the SMTP conversation) is often the ESP's own domain, not yours. SPF passes because the ESP's record covers that IP. But DMARC alignment fails because the envelope domain is bounce.sendgrid.net, not yourdomain.com.

This is why DKIM matters. If DKIM is configured correctly with your own domain in the d= tag, DMARC can pass via DKIM alignment even when SPF alignment fails.

Fix: Set up DKIM signing with your own domain at your ESP. DMARC only needs one alignment to pass. See the Email Authentication Guides for step-by-step DKIM setup at SendGrid, Mailgun, Brevo, and others.

Note: email forwarding also breaks SPF alignment. A forwarded message changes the envelope sender. Again, DKIM is what saves DMARC from failing for forwarded mail.

5. SPF record syntax errors

A malformed SPF record returns PermError and fails silently. Common mistakes:

• Starting with v=spf2 or missing v=spf1 entirely
• Typos in mechanism names: includes: instead of include:
• Using a semicolon as a separator instead of a space: include:x.com;include:y.com
• An all mechanism in the middle of the record (it must always be last)
• Duplicate mechanisms for the same domain

Check syntax using the SPF Lookup tool. If the tool shows a parsed list of mechanisms, your syntax is valid. If it returns an error or empty result, there is a syntax problem.

6. SPF passes but emails still go to spam

SPF passing is necessary but not sufficient. It tells receivers that your IP is authorized to send for your domain. It says nothing about your reputation, engagement history, or content quality.

If your SPF is passing and email still goes to spam, check:

• DKIM: is the message signed with your own domain? Unsigned messages have lower trust.
• DMARC: is the policy set and are you passing alignment? Check at InboxGreen.email/check.
• Domain reputation: a new domain or a domain with a history of spam complaints will be filtered regardless of authentication.
• IP reputation: shared sending IPs at ESPs inherit reputation from other senders on the same IP.
• Content: certain phrases, excessive links, and broken HTML increase spam scoring.

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of [email protected]
       designates 198.51.100.42 as permitted sender)
  [email protected]

Authentication-Results: mx.google.com;
  spf=fail (google.com: domain of [email protected]
       does not designate 203.0.113.0 as permitted sender)
  [email protected];
  dmarc=fail (p=QUARANTINE sp=QUARANTINE) header.from=yourdomain.com

When SPF passes but DMARC still fails, look at the smtp.mailfrom domain. If it is your ESP's domain instead of yours, that is the alignment gap. Fix: enable custom domain authentication at your ESP.

Run the full deliverability check to get a complete picture of what's affecting your inbox placement.

SPF Tools

Related Guides

Common Questions About SPF