SPF Record Syntax Explained: Includes, IPs, and the 10-Lookup Limit

SPF records look harmless: one short TXT record, a few include: values, and an all at the end. But that single line decides which servers are allowed to send mail for your domain, and one bad token can make every legitimate message fail SPF. The most dangerous part is that the record can look fine in your DNS dashboard while receivers reject it in the real world.

If you want the broader foundation first, read the plain-English guide to SPF, DKIM, and DMARC. This post zooms in on the SPF line itself: what each piece means, what breaks most often, and how to keep it under the limit.

A basic SPF record, decoded

A common SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Read it left to right. v=spf1 marks the record as SPF. Each include: authorizes another provider to send for you. The final ~all says mail from anything else should soft-fail: treat it as suspicious, but do not necessarily reject it outright.

Other mechanisms show up too: ip4: and ip6: authorize specific addresses, a authorizes the IP behind your domain's A record, mx authorizes your mail exchangers, and redirect= points the whole policy at another SPF record.

The 10-lookup limit is the trap

SPF allows only 10 DNS lookups during evaluation. Mechanisms like include:, a, mx, and redirect= count toward that limit. Nested includes count too, which means the visible record can look short while the real lookup count is already at the edge.

Cross the limit and receivers return a permanent error. In practical terms, SPF fails for mail that may have been perfectly legitimate. This usually happens slowly: a company starts with Google Workspace, adds a newsletter platform, then a CRM, then support software, then a transactional sender. Nobody notices the lookup count until deliverability drops.

One SPF record means exactly one

Another common failure is publishing multiple SPF records at the same hostname. DNS allows multiple TXT records, but SPF does not allow multiple v=spf1 policies for the same domain. If you have one record for Google and another for SendGrid, receivers treat the SPF setup as invalid.

The fix is to merge providers into one policy:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

What should the all mechanism be?

The final mechanism tells receivers what to do with anything not matched earlier. ~all is a practical default while you are still auditing senders. -all is stricter and says unauthorized mail should fail hard. +all is almost always wrong because it authorizes everyone on the internet to send as your domain.

SPF by itself is not enough to block spoofing, though. For that, SPF has to work alongside DKIM and a DMARC policy. Once you know every legitimate sender is passing, tighten DMARC in stages instead of relying on SPF alone.

How to check yours without guessing

Run your domain through the free SPF checker. It resolves every include, counts the real DNS lookups, flags duplicate SPF records, and catches unsafe endings like +all. If your record is drifting toward the 10-lookup limit, you will see it before it becomes a delivery problem.

And because SPF records change whenever someone adds a new sending tool, Zeqo Mail keeps watching daily. The moment a provider edit pushes you toward failure, you get the exact alert while the fix is still small.