Free, no accountLive DNS queryRated Weak → ExcellentMade in Montréal

SPF record checker: read the record, and count the lookups that break it

Most SPF failures are not typos. They are silent permerrors from crossing the ten-DNS-lookup limit, or a second SPF record someone added years ago. This checker parses every mechanism, expands your includes, rates the record from Weak to Excellent, and gives you the exact change to make, plus a copy-paste stronger record.

v=spf1
include:
ip4 / ip6
a / mx
redirect=
-all / ~all
ptr (deprecated)
lookup budget

/100Rated, with fixes

0Accounts needed

FreeNo limits, no card

SPF record checker

The live lookup needs JavaScript, because it queries DNS from your browser. Enable JavaScript to check a domain, or read the guide below to validate a record you already have.

Quick answer

What is an SPF record?

SPF (Sender Policy Framework, RFC 7208) is a TXT record listing which servers are allowed to send email using your domain. A receiving server takes the envelope sender's domain, looks up its SPF record, and evaluates the mechanisms left to right against the connecting IP address. The first match decides the outcome.

Exactly one SPF record per domain. Two v=spf1 TXT records is a permerror, and SPF fails for everything you send.
Ten DNS lookups, total. Every include, a, mx, exists, ptr and redirect counts, including the ones inside your includes.
The ending qualifier is the policy. -all rejects unlisted senders, ~all marks them softly, +all authorises the entire internet.
SPF does not survive forwarding. A forwarded message keeps your From address but arrives from someone else's server. DKIM is what survives; this is why DMARC accepts either.
SPF checks the envelope, not the From header. A message can pass SPF and still display a forged From address. Only DMARC alignment ties the two together.

How the rating works

A score, a band, and the exact change to make

Every lookup returns a score out of 100 and a band, derived from the things that actually decide whether SPF works: how many records are published, how close the evaluation is to the ten-lookup ceiling, which qualifier ends the record, and whether deprecated mechanisms are present. Under the band is a numbered list of findings, each with the reason it matters and the specific change to make, and where a better record can be written mechanically, a copy-paste value.

Rating bands
Rating	What it means	Typical cause
Excellent	One record, comfortable lookup headroom, hardfail ending, no deprecated terms.	A maintained record on a domain with a known sender inventory.
Strong	Correct and safe, with one refinement left, usually `~all` where `-all` would do.	The common state of a well-run domain mid-rollout.
Normal	Valid but doing modest work: softfail, or a lookup count with little headroom.	Most business domains sit here.
Low	Published but close to useless, `?all`, no final mechanism, or void includes burning lookups.	A record edited over years without review.
Weak	Effectively broken or actively harmful: duplicate records, over ten lookups, or `+all`.	A second record added to authorise a new vendor, or a copied template.
Missing	No `v=spf1` record at all.	Nothing has been published, or DNS was migrated without it.

“Aggressive by design” is not a failure

A record ending in -all is flagged as strict rather than penalised. Hardfail is the goal state, and it is also unforgiving: forwarded mail fails because the forwarder is not in your record, and a sending service you forget stops working outright instead of being marked. If you run mailing lists, alumni forwarding, or a long tail of departmental senders, ~all with DKIM published may be the better business decision. The tool says so and leaves the choice with you.

Two ways to read the same result

For a domain owner, the findings are a work queue: fix, improve, or a judgement call, in that order. For an analyst looking at someone else's domain, the same lookup reads as a footprint, which third-party platforms are authorised to send, how wide that vendor surface is, which includes resolve to nothing, and whether the record is maintained or merely inherited. The intelligence panel states both, including a plain spoofability verdict.

Reference

Every SPF mechanism, and whether it costs a lookup

The ten-lookup limit is the single most common way a valid-looking SPF record stops working. This is which terms count against it.

SPF mechanisms and their DNS lookup cost
Term	Costs a lookup	What it does	Notes
`ip4` / `ip6`	No	Authorises an address or CIDR range directly.	Free. This is what SPF flattening converts includes into.
`include:`	Yes	Evaluates another domain's SPF record and passes if it passes.	Its own lookups count too. One provider include can consume five.
`a`	Yes	Authorises the domain's A/AAAA addresses.	Cheap but easy to forget when you move hosts.
`mx`	Yes	Authorises the hosts in the domain's MX records.	Inbound hosts rarely send. Often removable.
`exists:`	Yes	Passes if a macro-expanded name resolves.	Used for per-IP allowlisting; rare.
`ptr`	Yes	Reverse-then-forward lookup of the sending IP.	RFC 7208 §5.5 says do not use it. Slow and unreliable.
`redirect=`	Yes	Hands evaluation entirely to another domain's record.	Only used when there is no `all` mechanism.
`all`	No	Matches everything. Always last, with a qualifier.	`-all`, `~all`, `?all` or `+all`.

What to do when you are over ten

Remove services that no longer send for you, which is usually two or three of them. Replace an include with the provider's published ip4 ranges if they are stable. Move a bulk sender onto a dedicated subdomain with its own SPF record, which also gives you cleaner DMARC reporting. Automated SPF flattening works but needs monitoring, because a provider that changes its ranges will break your mail silently.

Recommended records

Popular configurations, with the values to copy

One TXT record on the domain itself. Start each of these on ~all, confirm through DMARC reports that nothing legitimate is failing, then move the final term to -all.

Google Workspace only

Microsoft 365 only

A mail platform plus transactional and marketing senders

Typical

v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net ~all

Around seven lookups depending on what each provider nests. This is the point to start counting rather than adding, because the next vendor may not fit.

Your own mail server

Self-hosted

v=spf1 ip4:203.0.113.10 ip6:2001:db8:10 -all

Address mechanisms cost no lookups, so an all-IP record can never hit the limit. Prefer ip4 and ip6 over a or mx: it is explicit, and it does not silently follow a hostname you later repoint.

A domain that sends no mail

Recommended, and usually missing

v=spf1 -all

Publish this on every parked domain, brand-defensive registration and web-only hostname, together with a null MX (0 .) and p=reject. Unwatched domains are the easy target.

Over the lookup limit

Repair pattern

Before   v=spf1 include:a.net include:b.net include:c.net include:d.net include:e.net ~all   (13 lookups)
After    v=spf1 include:a.net include:b.net ip4:198.51.100.0/24 ip4:203.0.113.0/24 ~all      (6 lookups)

Keep includes for providers whose ranges change often, and substitute published IP ranges for the ones that are stable. If you automate this, monitor DMARC reports: a provider that adds an address will start failing with no other warning.

Not sure what an include names? The fingerprint reference decodes the common ones, including which are marketing platforms, which are phishing-simulation vendors, and which reveal the finance system.

Results

The eight SPF results, and what each one means

A receiving server does not get a yes or no from SPF. It gets one of eight outcomes defined in RFC 7208 §2.6, and how it treats each is its own decision.

SPF evaluation results
Result	Caused by	Typical handling
pass	A mechanism matched with a `+` qualifier.	Delivered, and can align for DMARC.
fail	Matched `-all` or an explicit `-` mechanism.	Rejected or filtered, depending on DMARC policy.
softfail	Matched `~all`.	Accepted but marked. The usual production setting.
neutral	Matched `?all`, or no `all` at all.	Treated as no policy. Provides no protection.
none	No SPF record, or no valid domain.	No SPF signal. DMARC then depends entirely on DKIM.
permerror	Two SPF records, over ten lookups, or invalid syntax.	SPF cannot pass. Usually the real cause of a sudden deliverability drop.
temperror	Transient DNS failure during evaluation.	Deferred; the sender retries.
(void lookups)	More than two lookups returning NXDOMAIN.	Permitted cause of permerror in RFC 7208 §4.6.4.

Playbook

Publishing SPF correctly, in order

Inventory every sender. Mail platform, CRM, invoicing, helpdesk, marketing tool, monitoring alerts, the ecommerce plugin. Anything absent from the record will fail.
Write one record. One v=spf1 TXT record on the domain itself, includes for each provider, then ~all while you verify.
Check the lookup count. Run it here. If you are near eight, prune before adding anything else.
Turn on DMARC reporting. Aggregate reports name every IP sending as you, which is the only reliable way to find the sender you forgot.
Harden to -all. Once reports are clean, and only then. Keep the record under ten lookups permanently.
Add DKIM. SPF breaks on forwarding, DKIM does not. DMARC passes if either aligns, so publish both.

FAQ

SPF questions, answered

How does the SPF rating work, and is -all penalised?

Each lookup returns a score out of 100 and a band from Missing through Weak, Low, Normal and Strong to Excellent. The score is driven by the things that decide whether SPF actually works: the number of published records, how close the evaluation is to the RFC 7208 ten-lookup ceiling, which qualifier ends the record, void includes, and deprecated mechanisms. A record ending in -all is not penalised: it is flagged as strict by design, because hardfail is the goal state but also refuses forwarded mail and any sender you forget. Whether that trade-off suits your business is stated as a judgement call rather than scored as an error.

What is an SPF record?

SPF (Sender Policy Framework, defined in RFC 7208) is a DNS TXT record listing which mail servers are allowed to send email using your domain. A receiving server looks up the record for the envelope sender's domain and evaluates its mechanisms left to right against the connecting IP address; the first mechanism that matches determines the result.

What is the SPF 10 DNS lookup limit?

RFC 7208 §4.6.4 limits an SPF evaluation to 10 DNS-querying mechanisms. include, a, mx, exists, ptr and redirect all count, and so do the lookups inside every included record. Cross the limit and receivers must return permerror, which means SPF cannot pass at all. This is the most common cause of SPF failing on a record that looks correct.

What is the difference between -all and ~all?

Both are the final catch-all mechanism. -all is a hard fail: the domain states that any unlisted server is unauthorised, and receivers may reject the message outright. ~all is a soft fail: unlisted senders are marked as suspicious but usually still delivered. Start on ~all while you confirm your sender inventory, then move to -all. Never publish +all, which authorises every server on the internet to send as your domain.

Can I have two SPF records?

No. RFC 7208 requires exactly one v=spf1 TXT record per domain. Two records produce a permerror and SPF fails for all of your mail. If you need to authorise an additional provider, add an include or an ip4 range to the record you already have.

Does SPF stop email spoofing?

Only partly. SPF validates the envelope sender (the MAIL FROM address), not the From header the recipient sees. A message can pass SPF while displaying a completely forged From address. Closing that gap requires DMARC, which insists the authenticated domain aligns with the visible From domain.

Why does SPF fail when my email is forwarded?

Forwarding preserves your From address but relays the message from the forwarder's server, which is not in your SPF record, so SPF fails at the final destination. DKIM signatures survive forwarding intact, which is why DMARC passes when either SPF or DKIM aligns. Publishing both is what makes forwarding survivable.

What is SPF flattening, and should I use it?

Flattening replaces include mechanisms with the literal ip4 and ip6 ranges they resolve to, cutting the lookup count. It works, but the ranges become your responsibility: when a provider adds a sending IP, your mail from that provider starts failing SPF with no warning. If you flatten, automate it and monitor DMARC aggregate reports.

Does this SPF checker store the domains I look up?

No. The lookup runs in your browser: the domain is sent to a public DNS-over-HTTPS resolver (Cloudflare, with Google as a fallback) to obtain the answer, and nothing is logged on our side. Your last five lookups are kept in your browser's local storage only, on your own device.

Key terms

Glossary

SPF (Sender Policy Framework): RFC 7208. A DNS TXT record listing the servers authorised to send mail for a domain.
Mechanism: One term in an SPF record (ip4, include, a, mx, all…) evaluated left to right against the sending IP.
Qualifier: The prefix on a mechanism: + pass, - fail, ~ softfail, ? neutral. + is the default when omitted.
DNS lookup limit: At most 10 DNS-querying mechanisms per evaluation, counted across all nested includes. Exceeding it forces a permerror.
permerror: A permanent SPF evaluation error: multiple records, invalid syntax, or too many lookups. SPF cannot pass.
Envelope sender: The MAIL FROM address used during the SMTP transaction. SPF checks this, not the visible From header.
SPF flattening: Replacing includes with the literal IP ranges they resolve to, to stay under the lookup limit.
Void lookup: A lookup returning NXDOMAIN. More than two in one evaluation may be treated as a permerror.

Sources & methodology

How this tool gets its answers

Lookups run from your browser over DNS-over-HTTPS against Cloudflare's resolver at cloudflare-dns.com, falling back to Google's at dns.google. The tool queries TXT on the domain, selects records beginning v=spf1, and counts include, a, mx, exists, ptr and redirect= terms. Each include is then queried once and its own DNS-querying terms counted, so the reported total covers two levels. Deeper nesting is not followed, so the real count can be higher than shown, treat the number as a floor, not a ceiling.

Rules and thresholds cite RFC 7208 throughout: §3.2 on a single record per domain, §4.6.4 on the ten-lookup and void-lookup limits, §5.5 on ptr, and §2.6 on the eight results. We publish no invented ratings, review counts or certifications.

SPF is one of three. Check the other two.

SPF authorises your servers, DKIM signs your messages, DMARC tells receivers what to do when either fails. All three are lookups away.

Verify an email address → Run the full MX & TLS check