SPF Checker

What does an SPF check examine?

SPF (Sender Policy Framework, RFC 7208) lets a domain publish, in a single TXT record that starts with v=spf1, the systems allowed to send mail using that domain in the SMTP envelope. A receiving server takes the connecting IP address, looks up the record for the envelope sender domain and evaluates the terms from left to right until one matches.

This tool reads the record, parses each term, and then follows every include: and redirect= into the records they point to. It reports the record text, the number of DNS-querying terms it found, the number of void lookups (queries that returned no data or NXDOMAIN), whether the chain loops, and how the record ends.

• It evaluates the record structurally. It does not take a sending IP address and tell you whether that IP would pass.
• It does not read the message header, so it cannot say what a particular receiver decided for a particular message.

How to read the result

The headline shows the lookup count as a fraction of 10. Only terms that make the receiver query DNS count: include, a, mx, ptr, exists and redirect. The ip4, ip6 and all terms cost nothing. Nested includes count too, so a single include: for a large provider can consume several lookups on its own. When the limit is exceeded the tool lists the top-level terms that contributed most, which tells you where to cut first.

The void-lookup figure matters separately. A lookup that returns no records still counts toward a limit of 2 in RFC 7208, so a typo in an include target or a retired provider can break an otherwise short record. Receivers that enforce the void limit treat the excess as a permanent error.

The ending of the record is assessed too. A -all ending tells receivers to reject unlisted senders, ~all marks them as soft failures, ?all makes no statement, and a bare +all authorises the whole internet and is reported as a high-severity risk. Terms placed after all are never evaluated and are flagged.

Common SPF problems

• More than 10 DNS-querying terms. The receiver stops and returns permerror. Mail may then fail SPF for every message, even from legitimate senders.
• Two SPF records at the same name. RFC 7208 section 4.5 requires exactly one. Several v=spf1 records are a permanent error, usually caused by adding a new provider's record instead of merging it.
• Include targets that do not exist. A removed or misspelled include: domain is a void lookup and, for a missing record at the target, can also fail evaluation.
• Include or redirect loops. A chain that points back at itself never finishes and is a permanent error.
• Syntax faults. An unknown mechanism, a missing colon, or stray spaces break parsing. Receivers treat unparseable terms as permerror.
• Use of ptr. RFC 7208 says it SHOULD NOT be used because it is slow and unreliable; it also spends a lookup.
• Soft or open endings. ~all is a reasonable staging value, ?all and +all give little or no protection.

PermError, TempError and why a DNS failure is not 'no record'

SPF evaluation has two error results. A permerror means the record itself cannot be evaluated: too many lookups, syntax problems, multiple records or a loop. Retrying will not help until the record is changed. A temperror means a transient problem, typically a DNS timeout or SERVFAIL while fetching a record, and a receiver may retry or defer the message.

This tool applies the same discipline to its own queries. If DNS fails while reading the record or one of its includes, the result is reported as unknown and the lookup count is shown as 'at least' a number. A failed query is never presented as proof that a record is absent.

How to fix SPF safely

Prerequisites: a list of every system that sends mail as your domain, such as your mailbox platform, newsletter tools, ticketing systems and application servers, and access to the DNS zone. Operational risk: SPF edits take effect as caches expire, and removing a legitimate sender causes its mail to start failing SPF, which can combine badly with a strict DMARC policy. Record the current value before editing so you can roll back by pasting it back.

1. Copy the existing TXT record text to a safe place as your rollback value.
2. Inventory senders using DMARC aggregate reports or provider documentation, and remove only providers you can confirm are retired.
3. If the count is over 10, replace a, mx and include terms with ip4 or ip6 ranges only where the provider documents stable addresses; never hard-code addresses a provider can change.
4. Keep one v=spf1 record. Merge mechanisms from any duplicates and delete the extras.
5. Prefer ~all while validating and move to -all only after reports show no legitimate sender failing.
6. Re-run this check and confirm one record, a count of 10 or fewer, and no void lookups. Then send a test message and read the SPF result in the received headers.

What this check cannot tell you

SPF only covers the envelope sender (the Return-Path) and the HELO name, not the visible From address. A message can pass SPF and still fail DMARC if the domains are not aligned. The tool also does not expand the address lookups hidden inside an mx term, caps its own work at 90 DNS questions, and cannot see a receiver's cached or locally overridden view. Passing here does not prove mail is delivered or lands in the inbox.

Frequently asked questions

Scope of this tool

• No sending IP is evaluated against the record.

Written by DNS Tools editorial · Last updated 2026-10-09