SPF CheckerAn SPF record is a DNS TXT record starting with v=spf1 that lists which IPs may send mail for a domain. Learn more →
Check a domain's SPF record — syntax, lookup count, and common issues. Instant, no signup, plain English.
Quick answer: SPF tells receivers which servers are allowed to send mail using your domain. This tool fetches your SPF TXT record, parses it, counts the DNS lookups it triggers, and flags syntax errors, missing records, dangerous fail-open qualifiers, and the 10-lookup limit. A broken SPF record means your mail is treated as 'permerror' — receivers ignore SPF entirely.
What this checksinclude: delegates SPF authorization to another domain's SPF record and counts as one lookup. Learn more →
SPF (Sender Policy Framework) is a DNS TXT record published by a domain owner that lists which IP addresses or other domains are authorized to send mail on behalf of the domain. Relaymetry queries the apex TXT records, identifies the SPF record (the one starting v=spf1), parses its mechanisms, expands include: chains to count flat DNS lookups against the RFC 7208 limit of 10, counts void lookups against the limit of 2, and flags syntax issues, dangerous fail-open qualifiers (+all, ?all), the deprecated ptr mechanism, redirect-with-all conflicts, and include: cycles. We do not verify whether your actual sending IPs are in the authorized list — that requires real message inspection.
How to read the resultRFC 7208 s.4.6.4 caps SPF evaluation at 10 DNS lookups. Exceeding the limit triggers permerror. Learn more →
The result shows your SPF record verbatim, the count of DNS lookups it triggers (out of 10), and any flagged warnings. The all mechanism at the end of the record is the catch-all: -all (hard fail) instructs receivers to reject mail from unauthorized senders, ~all (soft fail) marks it as suspicious, ?all (neutral) takes no position, and +all (pass) authorizes everyone — almost never what you want. include:_spf.google.com delegates SPF authorization to Google's published mechanisms; ip4:1.2.3.4 authorizes a specific IP; mx authorizes whatever your MX records resolve to. The lookup-count visualizer shows where you stand against the RFC 7208 §4.6.4 hard limit of 10 — include: chains are the most common cause of approaching the cap. If your record exceeds 10 lookups, receivers must abort SPF evaluation and return permerror, which most treat as authentication failure.
Common failures
No SPF record published: receivers fall back to local heuristics, often unfavorable. Add a TXT record starting with v=spf1 listing your sender IPs and provider includes. Multiple SPF records at the same domain: RFC 7208 §3.2 requires exactly one. Multiple records produce permerror. Merge them into a single record. Lookup-count overflow (>10): each include:, mx, a, redirect=, or exists: mechanism is one lookup. Deep include: chains compound. Use SPF flattening services or remove obsolete includes. Dangerous fail-open qualifier: +all authorizes any sender to send as your domain — a spoofing wide-open. ?all is nearly as bad. Use -all (strict) or ~all (soft) per your tolerance for false positives. Deprecated ptr mechanism: RFC 7208 §5.5 deprecates ptr. Receivers may ignore it or fail. Replace with ip4: / ip6: / include: mechanisms. Sending IP not authorized: SPF only describes what the record says — receivers comparing the actual sending IP against the record can still fail SPF if the IP is not listed. If your provider rotates IPs, use their official include: directive instead of literal IPs. Sending platform signs DKIM with a different domain, so SPF passes for the envelope domain but DMARC alignment fails — see the DMARC checker for that scenario.
What this does not prove
An SPF record passing all our checks does not mean your mail will be accepted. Receivers also weigh DKIM, DMARC alignment, IP reputation, content scoring, and engagement history — SPF is one signal among many. We do not test whether your specific sending IP is authorized by the record (that requires the IP). We do not detect SPF flattening services that have rewritten the record or check whether include: targets are themselves valid. End-to-end deliverability requires sending a real test message and checking the receiver's headers.
Common questions
How to fix SPF permerror?RFC 7208 s.4.6.4 caps SPF evaluation at 10 DNS lookups. Exceeding the limit triggers permerror. Learn more →
permerror means the receiver could not evaluate SPF because the record is broken — typically duplicate SPF records, syntax errors, or more than 10 DNS lookups per RFC 7208 §4.6.4. Audit the TXT records, merge duplicates into one, and reduce include: chains until lookups are 10 or fewer.
What is 550 SPF permanent error?
550 5.7.1 with SPF reason is a hard rejection from a receiver enforcing SPF — usually because your sending IP is not authorized by the published SPF record. Either add the IP to your SPF (via ip4: or the provider's include: directive) or relay through an authorized sender.
Can I have multiple SPF records?
No. RFC 7208 §3.2 requires exactly one SPF record per domain. Multiple v=spf1 TXT records cause permerror and SPF is ignored entirely. Merge all authorized senders into a single record.
What is the SPF 10 DNS lookup limit?RFC 7208 s.4.6.4 caps SPF evaluation at 10 DNS lookups. Exceeding the limit triggers permerror. Learn more →
RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups (each include:, mx, a, redirect=, or exists: counts as one). Records that exceed this trigger permerror regardless of sender legitimacy. Compound include: chains are the usual culprit; use SPF flattening or prune obsolete includes.