5.7.24

Enhanced Status Code 5.7.24: SPF Validation Error

Permanent failure High severity Authentication RFC 7372
What it means

Enhanced Status Code 5.7.24 means “SPF Validation Error.” SPF evaluation could not be completed. This is not a fail, it is a broken record or a DNS problem that stopped the check from producing an answer at all, and many receivers treat that as a fail.

At a glance
Code5.7.24
Bounce typeHard (permanent)
SeverityHigh
CategoryAuthentication
What to doSuppress the address; do not retry
StandardRFC 7372
What it looks like in your mail logs
550 5.7.24 SPF record for the sending domain contains suspicious entries

What does 5.7.24 mean?

Enhanced status code 5.7.24 means an SPF validation error, which RFC 7372 distinguishes carefully from an SPF fail. A fail means the check completed and the answer was no. An error means the check could not complete: the record is syntactically invalid, it exceeds the permitted DNS lookups, it triggers a void lookup limit, or the DNS query itself failed.

The practical difference matters because the fixes are different. A fail is corrected by adding the sending IP address. An error is corrected by repairing the record itself, and the most common repair is reducing DNS lookups. SPF permits ten, and every include, a, mx, ptr, exists and redirect term counts, including lookups performed inside a provider's own record. A record that has accumulated one include per vendor will cross that line eventually, and it can cross it without you making any change at all, because a vendor expanded their record inside your include.

Google also returns 5.7.24 with text saying the SPF record contains suspicious entries, which covers records using deprecated or dangerous mechanisms such as ptr, records with overly broad address ranges, or records whose includes resolve to something unexpected. In every case the message is the same: the receiver could not arrive at a trustworthy answer, so it declined to guess.

How 5.7.24 plays out

Your server attempts delivery
The recipient server returns a permanent 5.7.24 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.7.24 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
5.7.24 is✓ this code

What each provider means by 5.7.24

A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.

IANA registry SPF validation error: evaluation could not be completed Reference
Gmail The SPF record contains suspicious entries Reference

Common causes of 5.7.24

  • The SPF record exceeds the ten DNS lookup limit and evaluation returns permerror
  • The record contains a syntax error such as a stray character or a missing colon
  • More than one SPF TXT record is published for the domain, which is invalid
  • The record uses the deprecated ptr mechanism, which many receivers reject outright
  • An include points at a domain that no longer publishes an SPF record, producing a void lookup
  • Authoritative DNS for the domain timed out or answered inconsistently

How to fix 5.7.24

  • Count the DNS lookups in the record with SPF Record Checker and get below ten
  • Publish exactly one SPF record, merging any duplicates into it
  • Remove the ptr mechanism entirely, it is deprecated and actively harmful
  • Remove includes for vendors you no longer use, since each one costs a lookup
  • Flatten stable includes to ip4 and ip6 ranges where the vendor addresses rarely change
  • Check that every include still resolves, since a dead include produces a void lookup

Frequently asked questions

What is the difference between 5.7.23 and 5.7.24?
They describe different outcomes of the same check. 5.7.23 means SPF completed and returned fail: the sending IP is genuinely not authorised. 5.7.24 means SPF could not complete at all, because the record is broken, too complex, or DNS did not answer. The first is fixed by authorising the IP, the second by repairing the record.
What causes an SPF permerror?
Most often exceeding the ten DNS lookup limit. Every include, a, mx, ptr, exists and redirect term counts toward it, and so do the lookups inside a provider include, which is why a record with five includes can already be over. Syntax errors, publishing two SPF records, and the deprecated ptr mechanism are the other common causes.
My SPF record worked for years and just started failing. Why?
Because the lookup count is not fully under your control. When a provider you include expands their own SPF record, your total goes up without you touching anything. This is the single most common way a stable record breaks. Audit the count periodically rather than only when you add a sender.
How do I get under the ten lookup limit?
Remove includes for services you no longer use, which is usually where the easy wins are. Then flatten the stable ones by replacing an include with the ip4 and ip6 ranges it resolves to, accepting that you must re-check those ranges periodically. Do not flatten a provider whose addresses change often, since a stale flattened range fails silently.
Should I still use the ptr mechanism in SPF?
No. It is deprecated, it is slow, and several major receivers treat its presence as grounds to distrust the whole record. If your record contains ptr, remove it and replace the intent with explicit ip4 and ip6 ranges or a proper include.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes