An SPF record is a line of text in your domain’s DNS that lists the servers allowed to send email as your domain. Mail providers check it on every message, and mail from a server that isn’t listed can be sent to spam or rejected. The checker above reads your SPF record live, follows every service it includes, counts the DNS lookups against the limit of 10 and tells you exactly what to fix.

What SPF Does

SPF stands for Sender Policy Framework. When a message arrives, the receiving server looks up the SPF record of the domain in the message’s return address and asks a simple question: is the server that just connected one of the ones listed? The answer is a result such as pass, fail or soft fail, which the receiver uses alongside its other spam checks.

On its own, SPF has a gap. It checks the hidden return address, not the From address people see. That is why SPF works best together with DKIM and DMARC. DMARC requires the domain SPF checked to match the visible From domain, which closes the gap and tells receivers what to do when the check fails.

How to Read Your Result

The headline sums up the record:

• Valid, strict: the record ends with -all, so servers that aren’t listed should be rejected
• Valid, soft fail: the record ends with ~all, so unlisted servers are treated as suspicious, which works well with DMARC
• Valid but weak: the record ends with ?all or has no all term, so it doesn’t clearly reject anyone
• Broken: the record has an error receivers treat as permanent, such as too many lookups, two SPF records or a typo, so SPF fails for every message
• No SPF record: receivers have no list of allowed servers at all

The DNS lookups meter shows how close you are to the limit of 10. What the Record Allows breaks the record into its parts, follows each include down to the services behind it and shows what each one costs in lookups.

The Parts of an SPF Record

Every SPF record starts with v=spf1 and is followed by a list of terms, checked from left to right. The first term that matches decides the result. The most common terms are:

• Include: brings in another domain’s SPF record, which is how you allow a service such as Google Workspace, Microsoft 365 or a newsletter tool
• IP addresses (ip4 and ip6): allow a specific server or range of addresses
• Your website server (a): allows the server your domain points to
• Your mail servers (mx): allows the servers listed in your domain’s MX records
• The all term: decides what happens to everything not listed, and belongs at the very end

Each term can start with a qualifier. A plus sign, or nothing at all, means pass. A minus sign means fail, a tilde means soft fail and a question mark means neutral. In practice the qualifier only matters on the all term at the end.

-all vs ~all

Ending with -all tells receivers that any server not listed is not allowed to send for your domain. Ending with ~all says the same thing less firmly: treat the message as suspicious but don’t reject it on SPF alone.

If your domain has a DMARC policy of quarantine or reject, ~all is usually the safer choice. DMARC already decides what happens to failing mail, and some receivers reject a -all failure before DMARC gets a chance to look at the DKIM signature, which can block legitimate forwarded mail. For a domain that never sends email, use v=spf1 -all on its own, since there is nothing to break.

Avoid +all and ?all. The first allows every server in the world to send as you, and the second gives no opinion at all, which offers no protection.

The 10 DNS Lookup Limit

The SPF standard, RFC 7208, limits a record to 10 DNS lookups. Every include, a, mx, ptr and exists term costs one lookup, and so does a redirect. The includes inside an include count too, which is how a record with only five services can quietly need 12 or more.

When a record goes over 10, receivers stop checking and return a permanent error. SPF then fails for every message, whether it came from you or not. For mail that relies on SPF to pass DMARC, that can mean real messages going to spam or being rejected.

The standard also limits void lookups, which are lookups that return nothing, to two. An include pointing to a service you stopped using, or an mx term on a domain without mail servers, counts as a void lookup. More than two can also produce a permanent error.

How to Fix Too Many Lookups

Start by removing services you no longer use. Old newsletter tools, a previous email host and trial accounts are the usual suspects, and each one removed saves at least one lookup.

Next, replace terms that cost a lookup with ones that don’t. If your website server or mail server has a fixed IP address, an ip4 term for it costs nothing, while a or mx costs one each. Remove ptr entirely, since the standard discourages it.

If you still have too many, move some senders to a subdomain. Marketing mail can go out from a subdomain with its own SPF record and its own 10 lookups, which also keeps its reputation separate from your everyday mail. Some services offer SPF flattening, which replaces includes with the IP addresses behind them. It works, but those addresses change without notice, so a flattened record needs to be kept up to date automatically.

Other Common SPF Mistakes

A few other errors account for most broken records, and the checker looks for each one:

• Two SPF records on the same domain, which makes SPF fail for all mail; they must be merged into one
• A typo, such as a missing colon or a stray character, which breaks the whole record
• An include that points to a domain with no SPF record, often from a misspelled service name
• Terms placed after all, which are never checked
• The SPF record published at the wrong name, such as _dmarc, instead of on the domain itself

How to Add a New Service

When you start using a new tool that sends email as your domain, its setup guide will give you an include to add, such as include:_spf.google.com for Google Workspace or include:spf.protection.outlook.com for Microsoft 365. Add it to your existing record, before the all term, rather than creating a second SPF record.

Then run the checker again. Make sure the lookup count is still 10 or fewer and that the new include shows the service you expected. Many services also ask you to set up DKIM, which you should do as well, because DKIM keeps working when mail is forwarded and SPF doesn’t.

Who Requires SPF

Every domain that sends email should have SPF, and the largest mailbox providers now require it. Since 2024, Google requires all senders to its users to pass SPF or DKIM, and senders of about 5,000 or more messages a day to have SPF, DKIM and DMARC. Yahoo set similar rules, and Microsoft added the same requirements for bulk senders to Outlook.com, Hotmail and Live addresses on May 5, 2025.

The checker reads records through public DNS, so it sees what mail providers see. If you just made a change and the result looks old, wait a few minutes and check again.