SPF Record Checker

Enter a domain to fetch its SPF record, expand every include: it references, and count the DNS lookups the whole tree requires. The lookup count is the part that matters most — and the part almost no one checks until mail starts failing.

You also get the parsed record term by term, with any syntax errors, deprecated mechanisms and dangerous settings called out explicitly.

How it works

SPF (Sender Policy Framework) is a DNS TXT record listing which servers may send mail using your domain. A receiving server looks it up, checks whether the connecting server is authorised, and uses the answer as one input to its spam decision.

The 10-lookup limit is where most SPF records break. RFC 7208 §4.6.4 caps evaluation at ten DNS-querying terms, counted across the entire recursive tree — every include, a, mx, ptr, exists and redirect, including those inside the records you include. Exceed it and the result is permerror: receivers may treat SPF as failing entirely, and your legitimate mail starts landing in spam.

The trap is that this happens gradually. Each new service — a CRM, a helpdesk, a newsletter tool — adds one more include:, and each of those may itself contain several lookups. A record that reads as five includes can easily cost twelve lookups. Nothing warns you; mail simply starts failing.

The other decision is how the record ends:

• -all (hardfail) — anything not listed is unauthorised. The strongest setting, and the goal.
• ~all (softfail) — treat unlisted senders as suspicious but accept. The safe default while you confirm every legitimate sender is listed.
• ?all (neutral) — no opinion, and therefore no protection.
• +all — authorises the entire internet to send as your domain. Strictly worse than publishing nothing.

One more rule that catches people: a domain may publish exactly one SPF record. Two records is a permanent error, and receivers will not pick one for you.

Frequently asked questions