Free SPF checker — no account, no card

Does your SPF record still authorise your own mail?

We read your published record, count the DNS lookups it costs, and flag the mechanisms that quietly let anyone send as you. DKIM, DMARC, MX and blacklists come with it, in the same run.

~40 seconds · you get a report link you can send to anyone

What we read in your SPF record

The five ways an SPF record fails.

NO RECORD Nothing published at all: every receiver is free to guess whether your mail is yours.
TWO RECORDS Two SPF records is not twice the protection — it is a permerror, and receivers ignore both.
10 LOOKUPS Every include: and a: costs a DNS lookup. Past ten, SPF fails for everyone, silently.
+all / ?all The mechanism at the end decides what happens to unauthorised mail. +all authorises the internet.
DEAD INCLUDES A vendor you dropped, an include: that no longer resolves — it still burns a lookup.

SPF in one minute

A list of who is allowed to send as you.

SPF is a TXT record on your domain naming the servers permitted to send your mail. Receivers read it, compare it to the server that actually connected, and score you on the answer.

A healthy record

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

The 10-lookup limit is the one that bites. Each include: costs a DNS lookup, and the includes have includes of their own. Google alone spends three. Add a CRM, a helpdesk and a newsletter tool and you are over ten — at which point SPF returns permerror and receivers treat your mail as if you had published nothing at all. Nothing warns you. It just starts failing.

The last mechanism is a policy, not decoration. ~all means "anything else is suspicious", -all means "anything else is forged", and +all means "anyone on earth may send as me" — which is worse than having no record, and more common than you would think.

The ten-lookup ceiling

Why includes quietly nest past the limit.

Every include:, a:, mx:, ptr and exists: costs a DNS query, and the count is cumulative across every level of nesting — not per line, per record.

How four vendors spend eleven lookups

include:_spf.google.com            → 4  (nested)
include:spf.protection.outlook.com → 3
include:mailgun.org                → 2
include:_spf.brevo.com             → 2
                                    ─────
                                     11  → permerror

Permerror is not a soft fail. It is a structural error that tells the receiver your record is broken, and a broken record authenticates nothing — every message is scored as if you had published no SPF at all. Google spends three or four lookups behind a single include; Microsoft 365's spf.protection.outlook.com resolves cleanly today but Microsoft has widened it before without notice. You do not have to be careless to cross ten. You just have to add a CRM, a helpdesk and Mailchimp.

Flattening buys lookups back, and freezes a moving target. Replacing includes with the raw ip4: ranges they resolve to today drops your count — but Google, SendGrid and Amazon SES rotate their sending ranges, and the day one adds an address your flattened record has never heard of, that mail fails SPF with no include left to keep it current. Flatten only what you control, or what a service keeps in sync for you.

Envelope vs the visible From

SPF checks an address your reader never sees.

There are two sender addresses on every message. SPF only ever looks at one of them, and it is not the one that appears in the inbox.

Two different From addresses

MAIL FROM: [email protected]   ← SPF checks this
From:      [email protected]     ← your reader sees this

SPF authenticates the envelope, not the header. The MAIL FROM is the return-path the sending server hands over during the SMTP conversation — invisible to recipients. The From: they actually read is a separate field written into the message itself, and SPF never inspects it.

This is the gap spoofers walk through. A forger sends from a domain they own, passes SPF on that domain perfectly, and drops your domain into the visible From:. SPF passes. The forgery lands. Closing that gap is DMARC's job — it demands the domain SPF authenticated align with the name your reader sees. On its own, SPF proves a server was allowed to send. Not that the name on the letter is real.

What we flag beyond the count

Six mistakes hiding in a record that "works".

A record can parse, resolve and still be wrong. These pass a glance and cost you later.

Two records. More than one v=spf1 string is a permerror on its own — receivers ignore both. Merge into a single record with one all mechanism.

The ptr mechanism. It does a reverse DNS lookup on the connecting IP, is slow and unreliable, and the specification explicitly tells receivers they may skip it. Delete it.

+all. A record ending in +all authorises every server on the internet to send as you. It is almost always a copy-paste accident, and it is worse than publishing nothing.

Dangling includes. An include: for a vendor you stopped using still resolves, still burns a lookup, and still authorises their entire estate to send under your name.

Hand-written macros. Macros like %{i} and %{d} are valid, and outside the handful of ESPs that generate them for you, almost always a mistake — usually a hidden exists: lookup you did not intend.

Whitelisting whole blocks. Authorising a provider's entire /8 to make a stubborn sender work hands sending rights to every tenant on that network — shared-host neighbours included.

What DNS shows, and what it cannot

A checker reads the record. Only mail reads the traffic.

Half of SPF is structural and readable from DNS this second. The other half is behaviour, and it lives in the mail itself.

From DNS alone we can prove a lot. Whether a record exists, whether there is exactly one, how many lookups it will cost, which mechanism ends it, and whether every include: still resolves. That is the half you fix today by editing a TXT record.

What DNS cannot show is behaviour. Which of your senders actually pass SPF in real mail, whether a passing sender is aligned with your From:, and who is spoofing you right now. That lives in the traffic, and only DMARC aggregate reports collect it. A checker tells you the record is sound. The reports tell you the record is true.

Common questions

About SPF, specifically.

What is a "too many DNS lookups" error? Your record costs more than 10 lookups to evaluate. Receivers stop, return permerror, and ignore your SPF entirely. Flatten includes or drop the vendors you no longer use.
How do I fix "too many DNS lookups"? Drop includes for vendors you no longer send through, consolidate senders behind fewer providers, and where a sender publishes only static IPs, replace its include with those ip4: ranges. Re-count after every change — you have ten, not eleven.
Should I use ~all or -all? Start on ~all. Move to -all once DMARC reports show every legitimate sender passing — otherwise you are the one you block.
Can I publish two SPF records? No. Two records is a permerror. Merge everything into one, with a single v=spf1 and a single all mechanism.
What is SPF flattening? Replacing include: mechanisms with the raw ip4: ranges they currently resolve to, so the record costs fewer lookups. It works until a provider rotates its IPs, so flatten only ranges you control or that a service keeps in sync for you.
Does my SPF need to include my website host? Only if that host sends your mail. A server that serves pages but never sends email does not belong in SPF. Include whatever actually delivers your mail — your mailbox provider and every app that sends on your behalf.
Is SPF enough to stop spoofing? No. SPF checks the envelope, not the From: your users see. Without DMARC, a spoofer can pass SPF on their own domain and still display yours.
Why does my SPF pass but mail still goes to spam? SPF is one signal. Passing it does not override a missing DKIM signature, an unaligned From:, a cold IP, weak engagement or poor content reputation. Filters weigh all of them — SPF just keeps you from failing the easy one.

How it works

Real DNS queries, not a cached database.

We query your records live, the way Gmail or Outlook would at the moment of delivery. What you see is what receivers see.

  1. 1 You enter a domain. No verification needed — the records we read are public DNS, the same ones every mail server reads.
  2. 2 We run ~90 live queries. DNS records, selector probes, and one lookup per blacklist — about 40 seconds in total.
  3. 3 Every finding is scored and explained. Problems that cost you deliverability today, watches that will — each with numbered steps to fix it.
  4. 4 The report gets its own link. It stays at that URL: send it to your host, your IT provider or your client instead of a screenshot. Public DNS only — we store the answers, never your mail.

The other free checks

Same run, different question.

Full domain check → Everything at once: SPF, DKIM, DMARC, MX and the blacklists, scored out of 100. DMARC checker → Policy strength, alignment with SPF and DKIM, and where your reports go. Blacklist checker → Your domain and your sending IPs against every major RBL, with delisting links. Email tester → Send a real message and see SPF, DKIM and DMARC as a receiver does — with true alignment.