SPF Record Checker

About the SPF Record Checker

An SPF record is a TXT record that lists the servers allowed to send e-mail for your domain (RFC 7208). Receivers check it for every message, and a broken one quietly sends your mail to spam. This checker reads your record the way a receiving server does: it validates every term, follows each include and redirect to build the full tree, and counts the DNS lookups against the hard limit of 10 and the “void lookup” limit of 2 — the two most common reasons a record that looks fine returns permerror.

Enter a sending server’s IP address to see the exact result a receiver would get — pass, fail, softfail or neutral — and the mechanism that decided it, with every step of the evaluation. If you are close to or over the limit (8 lookups or more), you also get a flattened version that lists the IP networks directly.

Common uses

• Fixing “SPF permerror: too many DNS lookups” after adding another e-mail service.
• Checking a new provider’s include before switching your marketing or ticketing mail to it.
• Finding out why mail from one server lands in spam: test its IP and see which rule it falls through to.
• Auditing a domain before tightening DMARC — every legitimate sender must pass SPF or DKIM.

The two limits that break most records

• 10 DNS lookups. The terms include, a, mx, ptr, exists and the redirect modifier each cost one lookup, including those inside included records. More than 10 and the check stops with permerror (RFC 7208 §4.6.4). ip4, ip6 and all cost nothing.
• 2 void lookups. A lookup that finds nothing (the name does not exist, or has no records of that type) is a void lookup; RFC 7208 says receivers should stop after two. Old a: or include: entries for retired servers are the usual cause.
• An mx mechanism may also resolve at most 10 mail servers.

What the all at the end means

• -all (fail): servers you did not list are not authorized; receivers may reject the message.
• ~all (softfail): probably not authorized; receivers should not reject on SPF alone but may treat the message with suspicion (§8.5). A common, safe choice while you rely on DMARC.
• ?all (neutral) or no all at all: no statement — SPF then gives no protection.
• +all: every server on the internet passes. Never use it.

Flattening, and why it needs care

Flattening replaces includes with the IP networks they currently list, so the record needs fewer lookups. The checker builds it from the live tree when the record is close to or over the limit (8 lookups or more); it keeps the order of the terms, leaves any include whose rules are more than a list of networks in its place, and counts the lookups those still need. But providers change their servers without notice, and a flattened record does not follow them — mail from their new servers then fails until you update it. Prefer removing services you no longer use, or moving some mail to a subdomain with its own SPF record. A long flattened record must be published as several strings of at most 255 characters, which receivers join without spaces (§3.3).

What mailbox providers expect

Gmail requires every sender to set up SPF or DKIM, and senders of more than 5,000 messages a day to Gmail accounts to set up SPF and DKIM plus a DMARC record (Google’s email sender guidelines). SPF checks the envelope sender (the bounce address), not the From address people see — that link is made by DMARC.

Limitations

• The lookup count assumes a receiver evaluates every term. A real check stops at the first match, so a server listed early uses fewer lookups — but any server that is not listed reaches the end.
• Terms with macros (for example exists:%{i}._spf.example.com) depend on the message; they are evaluated only in the IP test.
• The checker sees DNS as Cloudflare’s resolver does right now; a record you just changed may still be cached elsewhere for up to its TTL.
• It checks SPF only. Whether a message is delivered also depends on DKIM, DMARC, content and the sender’s reputation.

Privacy

The domain, and every domain in its include tree, is looked up from your browser through Cloudflare’s DNS-over-HTTPS resolver (Google’s as a fallback). The IP address, sender and HELO name you test are only used in your browser to evaluate the record; they appear in DNS queries only if the record uses macros that put them there, as a real receiver would. MySmartCoPilot’s servers store nothing.