SPF Record Checker

What an SPF record does

SPF is a list of servers you have authorised to send mail on behalf of your domain, published as a TXT record in DNS. When a message reaches a receiving mail server, it checks the IP address it came from against your SPF record and decides whether that address is on the list.

Records need re-checking well after the initial setup, because they decay. You add another sending service and cross the lookup limit; a provider changes its IP ranges; someone publishes a second TXT record without noticing the first. In every one of those cases the DNS panel looks perfectly normal while validation on the receiving side fails.

What the checker shows

Alongside the record itself you get the expanded chain: every include points at another domain's SPF record, which may contain includes of its own, and all of it counts towards one shared limit. The lookup counter shows how many of the ten allowed you have already spent. That single number is the most common cause of deliverability problems nobody can explain.

The trailing all mechanism is analysed separately. A record ending in +all authorises every server on the internet to send as your domain, which is worse than having no SPF at all: the record exists, and it permits everything.

Common mistakes

• Two v=spf1 records. Usually the result of adding SPF a second time without removing the first. The outcome is permerror and no working SPF at all.
• More than ten DNS lookups. Typically appears once a third or fourth sending service is connected.
• The ptr mechanism. Deprecated, slow, and ignored by some receivers.
• No all mechanism. Without a trailing term the record defaults to neutral and achieves very little.
• Includes for services you no longer use. They consume lookups and leave authorisation with someone who should not have it.

What a correct record looks like

For a domain that sends only through its own mail server:

v=spf1 mx -all

For Google Workspace plus a marketing platform:

v=spf1 include:_spf.google.com include:spf.example-esp.com ~all

The record is published as a TXT record on the root of the domain (name @). Subdomains do not inherit it automatically: if campaigns go out from mail.example.com, that name needs its own record.

What the expanded chain shows

A record like v=spf1 include:_spf.google.com ~all looks short, but a single include can hide several more levels. The checker unrolls the whole chain and shows how many lookups each branch consumed and which networks ended up authorised to send as you.

Two things are worth reading there. First, the total lookup count: the closer to ten, the greater the chance that some service adds an include to their record and yours breaks without you touching anything. Second, networks you do not recognise: leftovers from a service you stopped using a year ago still carry permission to send from your domain.

What the final mechanism means

• -all — hard fail. Mail from anywhere else is rejected. The right destination, but move there once DMARC reports confirm every one of your senders is accounted for.
• ~all — soft fail. The message is accepted but marked. A sensible setting while you are still configuring.
• ?all — neutral, meaning the check gives receivers no signal at all.
• +all — everyone is authorised. Worse than no record: the domain looks configured while standing wide open to forgery.
• No mechanism at all. Treated as ?all.

Where it breaks most often

Three failures cover almost every case. Two v=spf1 records on a domain produce a permerror that makes the check fail for everyone. An exhausted lookup budget, which produces the same result and can appear on its own when a third-party service adds an include to theirs. And an include pointing at a domain with no SPF record at all: that mechanism breaks the whole evaluation.

Worth re-checking after every change

SPF is the one authentication record that can break without you touching anything. The ten-lookup limit counts recursively, and the contents of other people's include targets change whenever their provider adds servers. A record that fitted yesterday can exceed the limit today.

So it is worth running the check not only after editing your own record, but whenever you connect a new service, and every few months besides, simply to confirm the headroom is still there.