SPF record checker

Check the SPF record of a domain: its syntax, every include as a receiving server follows it, the DNS lookups it costs against the limit of 10, and what happens to mail from the servers it does not list.

The DNS lookups go straight from your browser to public resolvers (Cloudflare, Google): we see nothing.

What the SPF checker verifies

One SPF record, not two: A domain must publish exactly one TXT record that starts with v=spf1. With two, every receiver returns a permanent error (permerror), even if each record is correct on its own.
The syntax of every term: Each mechanism (ip4, ip6, a, mx, include, exists, ptr, all) and modifier (redirect, exp) is read the way a receiver reads it. One mistyped term, such as include; or a hostname after ip4:, breaks the whole record.
DNS lookups, include by include: include, a, mx, ptr, exists and redirect each make the receiver query the DNS, and the includes inside an include count too. RFC 7208 stops at 10: the checker shows what each term costs and the total.
Dead includes and void lookups: An include whose domain has no SPF record makes the whole record fail at once with a permerror, from the first one (RFC 7208, section 5.2). Void lookups are something else: DNS lookups that return no answer or NXDOMAIN, usually from a, mx or exists pointing to names that no longer exist. More than two, and SPF fails with a permerror (section 4.6.4).
The all mechanism: The end of the record decides what happens to every other server: -all refuses, ~all flags, ?all says nothing and +all lets anyone send.
Duplicates and deprecated terms: The same include written twice costs its lookups twice. ptr is deprecated by RFC 7208, slow, and ignored by some receivers.

How to read the result

Green: sound: One valid record, at most 10 lookups, ending in ~all or -all. Mail from the servers it lists passes SPF.
Amber: works, but fragile: Eight to ten lookups, a ptr, a duplicate or ?all. SPF still answers, but the next service you add, or a provider that changes its own record, can push it over the limit.
Red: SPF fails: Two records, a syntax error, more than 10 lookups or an include to a domain without SPF: receivers get a permerror, and DMARC counts it as a failure for every message that relies on SPF.
The lookup table: Each term of the record with the lookups it costs, its nested includes counted. The heaviest line is usually the one to replace with ip4 ranges or to move to a subdomain.

Common SPF errors and how to fix them

The messages below appear in bounces, in the Authentication-Results header of a received message, or in other checkers. Here is what each one means and what to change.

`SPF permerror: too many DNS lookups`

Why. Once every include is followed, the record needs more than 10 DNS lookups. The receiver stops and returns a permanent error, which DMARC treats as an SPF failure.

Fix. Remove the services you no longer use. Replace includes that cover a few fixed addresses with ip4: or ip6:, which cost nothing. Send bulk mail from a subdomain (news.example.com) with its own SPF record.

`SPF permerror: multiple SPF records found`

Why. Two TXT records start with v=spf1, usually because a new provider asked you to "add an SPF record" and the old one stayed.

Fix. Merge them into one: a single v=spf1, every include and address of both, one all at the end. Then delete the other record.

`spf=softfail (domain of … does not designate 192.0.2.1 as permitted sender)`

Why. The server that sent the message is not in the record, which ends in ~all. Most often a service that sends in your name (CRM, invoicing, a website form) was never added.

Fix. Find the sending service from the Received headers and add the include it documents. If the message was not yours, the record did its job.

`550 5.7.23 The message was rejected because of Sender Policy Framework violation`

Why. Microsoft, and other receivers, refused the message because SPF failed on a record ending in -all, or because DMARC enforced the failure.

Fix. Add the missing sender, as for a softfail. Forwarded mail cannot pass SPF: sign your mail with DKIM so that DMARC passes through DKIM instead.

`SPF void lookup limit exceeded`

Why. More than two DNS lookups made while evaluating the record returned no answer or NXDOMAIN, usually a, mx or exists mechanisms that point to names which were deleted or mistyped. The receiver stops with a permerror (RFC 7208, section 4.6.4).

Fix. Remove or correct the mechanisms that point to names that no longer exist. An include to a domain without an SPF record is a separate, stricter error: it fails the record at the first one, so remove it or replace it with the include the provider documents today.

`No SPF record found`

Why. There is no TXT record starting with v=spf1 on the domain itself: it was published on www, in another zone, or never.

Fix. Publish one TXT record on the domain (named @ in most DNS panels). A domain that never sends mail publishes v=spf1 -all.

Questions

How many DNS lookups does SPF allow?

10, counted over the whole record with every nested include (RFC 7208, section 4.6.4). ip4, ip6 and all cost nothing. Beyond 10, the result is a permanent error, and more than two lookups that return nothing also make SPF fail.

Should my SPF record end in ~all or -all?

With DMARC at quarantine or reject, ~all is enough and is kinder to forwarded mail: DMARC makes the final decision. Without DMARC, -all is the only ending that makes receivers refuse forged mail. Never +all, and ?all is the same as having no SPF.

Can I flatten my SPF record to get under 10 lookups?

Replacing includes with the addresses they currently contain lowers the count, but providers change their addresses without notice and a flattened record silently goes out of date. Flatten only what a provider documents as fixed.

Does SPF protect the From address people see?

No. SPF checks the envelope sender (the Return-Path), not the From line. Only DMARC ties SPF or DKIM to the visible From, which is why SPF alone does not stop spoofing.

Do the lookups go through your servers?

No. The checker runs in your browser and queries public DNS-over-HTTPS resolvers (Cloudflare, then Google). Nothing is sent to us or kept.