Enter a domain to fetch its live SPF record, expand every nested include and redirect, and see the true DNS lookup cost — plus a prioritized list of what to fix first.
Enter a domain to look up its live SPF record, expand nested includes, and measure the real DNS lookup cost.
We query public DNS for the domain you enter and show the result. The domain and its records are not stored or logged beyond the rate limiter.
We query DNS for the domain you enter, join multi-string TXT answers exactly as RFC 7208 requires, and isolate the record starting with v=spf1. Two SPF records is a permanent error, and the checker says so.
Each mechanism and modifier is validated: qualifiers, ip4/ip6 addresses and CIDR ranges, macros, duplicate or unknown modifiers, the deprecated ptr mechanism, and the terminal all policy.
The checker recursively expands include and redirect targets with cycle detection and safety caps — the same path a receiving server would walk — and counts void lookups along the way.
RFC 7208 allows 10 DNS-querying terms across the whole chain. You see the real total, how close you are to the limit, and which terms to flatten or remove.
Findings are ordered by severity — critical problems like +all, multiple records, or lookup-limit overruns first — each with plain-language remediation.
Build a correct SPF record from your sending sources and policy choice, then publish it as one TXT record.
Open toolPaste SPF record text and validate its syntax, mechanisms, and policy — no DNS lookup required.
Open toolVerify a DKIM public key record for a selector and check key type, size, and flags.
Open toolCheck your DMARC policy, alignment modes, and reporting destinations against RFC 9989.
Open toolIt queries your domain’s DNS for the TXT record starting with v=spf1, parses every mechanism and modifier, follows include and redirect chains the way a receiving mail server would, and reports the total DNS lookup cost. You see the raw record, a term-by-term breakdown, and a prioritized list of problems and fixes.
RFC 7208 caps SPF evaluation at 10 DNS-querying mechanisms and modifiers (include, a, mx, ptr, exists, and redirect). Once a message crosses that limit, receivers stop and return a permanent error — which can make legitimate mail fail authentication. Nested includes spend the budget too, which is why this checker expands the full chain instead of counting only the top-level record.
A void lookup is an include, a, mx, ptr, or exists term whose target returns no DNS answer. RFC 7208 recommends staying under two of them; some receivers treat excessive void lookups as a permanent error because the pattern is typical of abuse. Remove terms that point at domains you no longer use.
Not necessarily. This tool performs static analysis: it confirms the record is published once, parses correctly, and stays within protocol limits. Whether a specific message passes SPF depends on the sending IP, the MAIL FROM/HELO identity used at send time, and the evaluation path — none of which a DNS lookup alone can determine.
+all authorizes every server on the internet to send as your domain, which removes all spoofing protection — treat it as a critical misconfiguration. A record with no all mechanism and no redirect ends neutral, so receivers learn nothing about unlisted senders. End the record with ~all while testing and -all once your sender list is complete.
The ptr mechanism is deprecated by RFC 7208 (section 5.5) because it is slow and expensive to evaluate, and some receivers skip it entirely. Replace ptr entries with explicit ip4/ip6 mechanisms or an include.
Automate Sales Outreach & Get Booked!
Start Free Trial(14 Day Free Trial, No CC Required)