SPF Record Checker
Which DNS lookup is breaking your email

What is an SPF record, and what does this checker test?

An SPF record is one line of text in your domain's DNS listing which mail servers are allowed to send email using your domain name. SPF stands for Sender Policy Framework, defined in RFC 7208. A receiving server reads the sender domain from the SMTP conversation, fetches that domain's record, and checks whether the connecting IP address is on the list. The answer is one of seven results, and the receiver decides what to do with it.

Here is a real-shaped record with every part named. Read it left to right, because that is exactly how a receiver reads it:

What happens at the receiver, step by step

The detail that catches almost everyone is which address SPF checks. It is not the one your recipient sees.

So a record can be flawless and still leave the address your recipient reads completely unprotected. That is not a bug in SPF; it is the boundary of what SPF was designed to do. Authentication is also the part of sender reputation you control directly rather than earn over time, which is worth reading about alongside how receivers build an IP reputation score.

How to check an SPF record

1. Enter the domain, not the email address. SPF lives on the domain after the @. A pasted URL or full address is reduced to the hostname for you.
2. Read the lookup counter first. The number out of ten decides whether the record works at all. A perfectly written record still fails at eleven.
3. Add a sending IP if you are debugging one server. Enter the address your mail actually leaves from and the result shows which mechanism matched.
4. Work through the issues in order. Anything marked must fix breaks the record for every sender. Warnings weaken it without breaking it.
5. Re-check after editing DNS. Results here are cached for fifteen minutes, and your record's own TTL keeps the old value alive at receivers for longer.

Counting the lookups yourself

Worth knowing, because it explains results that otherwise look arbitrary. Three rules cover it:

• An include costs one lookup plus everything inside it, recursively. Four providers can easily cost twelve.
• ip4, ip6 and all cost nothing. This is the only reason flattening works.
• The budget is spent per check, not per record, and left to right. Terms sitting after the tenth lookup are never evaluated by anyone.

That last rule is why the total on your own record tells you so little. You need to see which branch is expensive, which is what the lookup tree above prints.

Checking it from a terminal

Any DNS client returns the raw value, which is useful for confirming what your provider actually published rather than what their control panel displays. These will not count lookups or follow the include chain.

To read the other records this one depends on — the MX hosts an mx term authorises, or the _dmarc TXT record — our DNS lookup tool returns them with their TTLs.

How to read your SPF result

Every evaluation ends in one of seven defined results. Four describe what your record says about a sender; three describe a problem with the record or the lookup. Which one you have decides whether to fix DNS or fix your sending setup.

What receivers actually do with a permerror

This is worth being precise about, because the two most common assumptions are both wrong. A permerror does not mean "your mail is rejected", and it does not mean "SPF is ignored, no harm done". What happens depends on the receiver. Microsoft documents the harsh end for the lookup case: the message fails with a permanent error and "the destination email system rejects the message in a non-delivery report" citing too many lookups. Other receivers treat permerror as an absent result and fall through to DMARC, which then has only DKIM to work with. Either way you have lost the protection you thought you had.

Reading the result on a real message

A record tells you what is permitted. A message header tells you what happened. Every receiver that checks SPF stamps the outcome into the message, usually in an Authentication-Results header and sometimes a separate Received-SPF line, naming the result and the identity it checked. If a specific message went wrong, that header is the primary evidence and this record is the secondary evidence. Paste one into our email header analyzer to see the recorded result and which identity produced it.

SPF too many DNS lookups: the ten-lookup limit and how to fix it

This is the most common way a correct-looking record fails. Evaluating a record costs DNS queries, and RFC 7208 §4.6.4 limits the total to ten, then requires receivers to return permerror above that. The count is cumulative through nested records, which is why three or four providers is often enough to break it.

Fixes, in the order worth trying

1. Remove dead includes. Providers you no longer use are free to delete, and they often show as void lookups because the provider withdrew their record. This tool names them.
2. Drop ptr and redundant a or mx terms. An mx term spends a lookup authorising servers that in most setups only receive mail.
3. Replace a small include with its ip4 ranges — but only where the provider publishes a stable list and tells you to. This is flattening in miniature and inherits its problem.
4. Move a provider to a subdomain. If the marketing platform sends from news.example.com, that subdomain gets its own record with a fresh budget of ten.
5. Flatten last, knowingly. Flattening replaces includes with the IPs they resolve to today. Valimail describes the result as a static snapshot of a dynamic reality: when your provider changes addresses, the record is stale and legitimate mail fails with no warning.

Void lookups: the limit almost nobody checks

Separately from the ten, RFC 7208 §4.6.4 says implementations SHOULD limit void lookups — queries returning nothing — to two. Note the wording: a recommendation with a recommended default, not a hard requirement, so receivers differ on enforcement. In practice a void lookup means an include pointing at a domain that no longer publishes a record: a wasted lookup, and a sign the record has not been maintained.

The size limits nobody mentions

Two separate constraints, and the first breaks records silently. A single DNS character-string cannot exceed 255 octets, so long records are published as several strings which RFC 7208 §3.3 says are joined with no space added. If a DNS editor splits mid-term, or inserts a space, the record becomes nonsense that still looks fine in the control panel. Separately, §3.4 recommends keeping the whole answer under about 450 octets so it fits a 512-octet UDP reply. The counters above report both.

Five SPF rules that surprise people

These come straight from the specification and are the reason two records that look equally valid can behave differently. Most checkers do not report any of them.

1. A redirect= is ignored when all is present

These two modifiers look interchangeable and are not. An include consults another record and carries on; a redirect hands the entire verdict to another domain. And RFC 7208 §6.1 is explicit that a redirect MUST be ignored if an all mechanism appears anywhere in the record. So v=spf1 ip4:203.0.113.7 redirect=example.net -all never consults example.net at all. The redirect is dead text, the record ends at -all, and nothing warns you.

2. mx overflow is fatal, ptr overflow is silent

Both mechanisms cap the address records they will process at ten, and the consequences are opposite. Exceed it inside mx and §4.6.4 requires a permerror. Exceed it inside ptr and everything past the first ten is simply ignored. The reasoning is ownership: your MX records are yours to control, while PTR records belong to whoever owns the IP address. Guides routinely state one rule for both.

3. ptr is not merely discouraged

Section 5.5 of RFC 7208 is titled, in the specification itself, "ptr (do not use)". The mechanism trusts reverse DNS, which is published by whoever owns the IP address rather than by you. Implementations must still support it, so it will work — it just authorises senders on someone else's word.

4. Some records answer differently for different senders

Terms containing %{...} are macros, expanded at evaluation time from the sending IP, the sender address and the domain. A record like v=spf1 exists:%{i}._spf.example.net -all builds a hostname out of the connecting IP and authorises the sender only if that name resolves. It is a legitimate technique used by large senders, and it means there is no single answer to "does this record authorise my server" without naming the server. This checker expands macros before resolving them, which is why the sending IP field changes the result.

5. Publish TXT, and only TXT

SPF briefly had a DNS record type of its own, type 99. RFC 7208 §3.1 records that the experiment was discontinued, so a record published only as type 99 is invisible to modern receivers. If a DNS panel offers you an "SPF" record type, use TXT instead. One more trap in the same family: a bare a or mx authorises your own hosts, which does nothing for mail sent by a third-party platform on your behalf — those need their own include.

SPF versus DMARC, and the -all question

SPF authenticates the envelope sender. DMARC cares about the From: header your recipient reads. For DMARC to pass on SPF's strength, those two domains must align: relaxed alignment accepts the same organisational domain, strict alignment demands an exact match. This is why a record can score perfectly here and still leave the domain unprotected — many platforms send with their own bounce domain, so SPF passes for that domain while your From: domain stays unauthenticated. A custom return path fixes it, or an aligned DKIM signature does the job instead. Our DMARC checker reports your alignment mode and policy.

What the current specification actually says about -all

Nearly every guide online marks ~all as the weaker choice and tells you to move to -all. The two largest receivers do not agree with each other: Microsoft recommends -all, and says why — "we recommend -all so DMARC can act on messages that fail SPF if the messages also lack DKIM signatures" — while Google calls -all overly restrictive and recommends ~all.

RFC 9989, published in May 2026 as the current DMARC specification, resolves this more usefully than either. Section 7.4 states that domain owners publishing p=reject MUST NOT rely solely on SPF to secure a DMARC pass and must apply valid DKIM signatures to their messages. Section 7.1 adds the warning that follows from it: with -all, a message that would otherwise have passed DMARC on an aligned DKIM signature can be rejected on the SPF failure alone.

Read together, the qualifier is the second question. The first is whether DKIM is signing your mail. With DKIM working and DMARC enforcing, either qualifier is defensible and ~all absorbs the forwarding cases SPF gets wrong. Without DKIM, -all makes your single point of failure stricter, which is not the same as making it safer.

• DKIM signing and DMARC enforcing: either qualifier works. Choose ~all if you forward mail or run mailing lists.
• No DKIM, DMARC at p=reject: you are outside what RFC 9989 permits. Fix DKIM before touching the qualifier.
• No DMARC record at all: ~all enforces nothing. Use -all, or publish DMARC.
• Never use ?all or a bare all. The first asserts nothing; the second authorises the whole internet.

What the large receivers now require

Since February 2024, Google has required senders of more than 5,000 messages a day to Gmail to publish SPF, DKIM and DMARC, and to align the From: domain with either the SPF or the DKIM domain; p=none is accepted. Google's guidance also states that from November 2025 it began ramping up enforcement against non-compliant traffic, with both temporary and permanent rejections — the full requirements are on Google's bulk sender page. Yahoo asks every sender for SPF or DKIM at minimum, and bulk senders for both plus a DMARC policy at p=none or stricter. Microsoft's own documentation puts it in four words: SPF alone is not enough.

Why SPF still fails when the record is correct

A record can pass every check on this page and mail can still be rejected, because SPF has structural limits no amount of editing removes. These five account for most real cases.

Forwarding

When a message is forwarded — an alumni alias, a role address, a mailing list — the forwarding server becomes the connecting IP and your record does not authorise it. SPF fails, correctly. Sender Rewriting Scheme rewrites the envelope sender so the forwarder takes responsibility, but Microsoft's documentation states that SRS does not rewrite the From: header and so does not stop forwarded messages failing DMARC. DKIM travels with the message, which is the part that survives.

A flattened record that has drifted

A record made almost entirely of ip4: ranges was probably flattened to get under the limit. It authorises servers that no longer send and omits the ones that do, from the day the provider changes addresses. Nothing warns you.

Includes pointing at domains you no longer control

Researchers at Guardio Labs documented a campaign in February 2024 known as SubdoMailing, in which abandoned domains still referenced in large organisations' DNS were re-registered and used to send authenticated spam. An include for a lapsed domain is a standing authorisation handed to whoever registers it next. An old include is not only a wasted lookup; it is a delegation you have forgotten about.

Subdomains, and the domains that never send

SPF does not inherit from the parent domain, so every sending subdomain needs its own record — including the bounce subdomain your platform uses. The mirror of that rule is the one people miss: a domain that never sends mail should publish v=spf1 -all to say so, which costs nothing and removes it as a spoofing target.

The problem is somewhere else entirely

Authentication and reputation are different failures with similar symptoms. If your record checks out and mail is still being refused, the sending IP may be listed or simply distrusted. Our IP blacklist check queries the major DNSBLs, our sender reputation check covers the softer signals receivers weigh, and the walkthrough for diagnosing an SPF, DKIM or DMARC failure starts from what the receiver told you rather than from your DNS.

Frequently asked questions about SPF records