SPF Record Lookup

SPF (Sender Policy Framework) is a standard that uses a DNS TXT record to declare which mail servers are allowed to send email for your domain. This tool looks up a domain's SPF record in real time, shows the raw value, and breaks down each mechanism — include, ip4, ip6, a, mx, redirect and all — so you can see at a glance which senders are authorized and how the final all policy is set.

A missing or misconfigured SPF record lets legitimate mail land in spam, or makes it easier for someone to spoof your domain. In particular, having more than one SPF record is a standards violation that can fail validation outright, so this tool flags that case with a warning. Just enter a domain — no protocol or path needed.

SPF mechanisms at a glance

• ip4 / ip6: an IPv4/IPv6 address or range (CIDR) allowed to send
• a / mx: authorize the domain's A record or MX servers as senders
• include: pull in another domain's SPF policy (e.g. an email SaaS)
• redirect: delegate SPF evaluation to another domain
• all: the policy for any sender not matched above

The all policy is what matters

SPF usually ends with all, and the qualifier in front of it decides the policy. -all (hard fail) tells receivers to reject unauthorized senders, while ~all (soft fail) is a lenient policy that lets suspicious mail through but marks it. ?all (neutral) and +all (pass all) offer essentially no protection and are not recommended. Once operations are stable, tightening from ~all to -all is a good move.

Things to watch out for

SPF allows at most 10 DNS lookups in total (include, a, mx, redirect, etc.); exceeding this causes a permerror that invalidates SPF. Avoid deeply nesting too many includes — see how many lookups you currently use with SPF Lookup Counter. Also, a domain must have exactly one SPF record — combine multiple sending services into a single SPF using include rather than adding separate records. SPF works best alongside DKIM (DKIM Record Lookup) and DMARC (DMARC Record Lookup); to assess all three at once, use Email Deliverability Check.

Qualifiers apply to every mechanism, not just all

The -all / ~all prefixes above are actually qualifiers that can sit in front of any mechanism. Omitting the sign defaults to + (Pass), so include:_spf.google.com is internally the same as +include:_spf.google.com. Evaluation runs left to right, and the qualifier of the first mechanism that matches becomes the result.

Walking through a record

Say a lookup returns this:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all

The tool breaks it into four parts. ip4:203.0.113.10 passes mail from that single IP. include:_spf.google.com and include:sendgrid.net pull in the SPF policies of Google Workspace and SendGrid, so every sending range those services publish is also authorized (each include adds a DNS lookup). The trailing ~all is the catch-all: "soft fail anything not matched above." If the sending IP is 203.0.113.10 it passes immediately at the first mechanism; an unrelated IP falls all the way through to SoftFail. When an include target nests further includes, the lookup count adds up fast — check the 10-lookup budget with SPF Lookup Counter.

Common pitfall

• Adding a sending service by publishing a second SPF TXT record like v=spf1 include:sendgrid.net ~all — now the domain has two records, which is a permerror that voids SPF entirely. Always add the include inside your existing single record.
• Leaving a, mx, or ptr in out of habit — if that host never actually sends mail, you're burning DNS lookups for nothing (ptr is also discouraged by the spec).
• Ending with +all — it authorizes every IP on the internet and effectively disables SPF, so treat it as a must-fix the moment a lookup shows it.