← Free tools

SPF record checker

Enter a domain. This resolves the whole SPF tree, follows every include and redirect, and counts DNS lookups the way a receiving mail server counts them.

Ten lookups is a hard ceiling. Go over it and evaluation stops with a permerror, which receivers treat as though you had published nothing at all. Your mail keeps sending and quietly stops being trusted.

A record can read perfectly at the top level and be broken three includes down, because a provider changed their own record and never told you. That is the check nobody runs.

Free, no account, nothing stored. It is a DNS lookup, so it costs us nothing to run.

What SPF does, in one paragraph

SPF is a public list of the servers allowed to send mail using your domain. It lives in a TXT record on the domain itself, and it starts with v=spf1. When a message arrives, the receiving server reads that list and compares it with the server the message actually came from.

That is the whole mechanism. It says nothing about the message, only about the machine that delivered it, which is why SPF on its own has never been enough and why DKIM and DMARC exist alongside it.

The ten-lookup limit, and why it breaks records that look fine

RFC 7208 caps SPF evaluation at ten DNS lookups. The terms that cost a lookup are include:, redirect=, a, mx, ptr and exists:. Anything expressed as a raw ip4: or ip6: range is free.

The trap is that the count is over the whole tree, not your record. If you include your email provider, and they include their CDN, and the CDN includes a subprocessor, every one of those costs against your ten. You can publish a three-term record on Monday and be over the limit on Friday without touching anything, because somebody upstream added a line.

When you go over, the result is not a partial pass. Evaluation returns a permerror, and most receivers score a permerror the same as no SPF record. This is the failure this checker exists to catch, and it is why the count above follows the includes instead of stopping at your record.

Reading the end of the record

The last mechanism is usually all, and its qualifier decides what happens to servers you did not list. -all says reject them. ~all says treat them as suspicious but deliver. ?all says make no judgement, which is close to publishing nothing.

+all says every server on the internet may send as you. It appears in the wild more often than it should, normally left behind by a test. A domain with `+all` is worse off than a domain with no SPF at all, because it actively authorises the people spoofing it.

~all is the sensible default while you are still discovering which systems send on your behalf. Move to -all once your DMARC reports have been quiet for a few weeks.

If you are about to start cold outreach

Sending volume is what turns a marginal SPF record into a deliverability problem. A domain that has only ever sent replies can survive a soft configuration for years. Point a hundred cold emails a day at it and the same record starts costing you the inbox.

Fix SPF, DKIM and DMARC before the first campaign rather than after, because reputation is slow to build and fast to lose. Check the other two with the DKIM checker and the DMARC checker.

The other checks

DMARC checker
DMARC record checker
Run it →
DKIM checker
DKIM record checker
Run it →
BIMI checker
BIMI record checker
Run it →

Common questions

Can I have two SPF records?

No. RFC 7208 requires exactly one TXT record beginning v=spf1 per domain, and publishing two is a permerror that most receivers treat as no SPF at all. This is the usual result of adding a second provider by adding a second record. Merge the mechanisms into one record instead.

How do I get under ten lookups?

In order of how much you will regret them: remove includes for services you no longer use, replace an include with the specific ip4 ranges it resolves to (flattening), and consolidate providers. Flattening works and it has a real cost, because the addresses go stale silently when your provider renumbers. If you flatten, put a reminder in the calendar to re-check.

Does SPF break when mail is forwarded?

Usually, yes. A forwarding server relays the message from its own address, which is not in your SPF record, so SPF fails at the final destination. This is expected and is precisely why DMARC accepts a pass from either SPF or DKIM. DKIM survives forwarding, so a domain with working DKIM is not damaged by it.

Should I use -all or ~all?

Start on ~all and move to -all once you are confident every legitimate sender is listed. The practical difference is smaller than it looks: most large receivers already weight a soft fail heavily. The real protection comes from DMARC being at quarantine or reject, not from the SPF qualifier.

Does a subdomain inherit the SPF record of the main domain?

No. SPF is not inherited. A subdomain with no record of its own has no SPF, which matters if you send from a separate domain for cold outreach. Publish a record on each sending domain.

Is this checker free?

Yes, and there is no account, no email capture and no limit worth mentioning. It is a DNS lookup, so it costs us nothing to run.

Authentication is the easy half

Wisemation finds the people worth writing to, researches each one, writes the email and the follow-ups, and sends them from your own inbox. Ten leads free, no card.

Try it free →