SPF Record Checker

What is SPF?

Sender Policy Framework is a DNS TXT record that declares which servers are authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to come from you@example.com, it looks up example.com's SPF record and checks whether the connecting server's IP is on the allowed list. If yes, the message passes the SPF check. If no, the server uses your policy to decide what to do — usually reject, quarantine, or mark as suspicious.

SPF lives alongside DKIM (cryptographic signing of message contents) and DMARC (a policy that says what to do when SPF or DKIM fail). All three are commonly required by mailbox providers like Gmail and Microsoft before they'll deliver your mail to the inbox at scale.

How to read an SPF record

An SPF record always starts with v=spf1 and ends with an all mechanism. Everything in between is a list of mechanisms that match sending IPs, each optionally prefixed with a qualifier:

• + (pass — the default if omitted) — this mechanism authorizes the sender
• - (fail) — this mechanism explicitly rejects the sender
• ~ (softfail) — this mechanism says the sender is probably not authorized; receivers may accept but flag
• ? (neutral) — no opinion; receivers treat as if SPF wasn't there

Common mechanisms: ip4:1.2.3.0/24 matches an IP range, include:_spf.google.com pulls in Google's record (and recurses), a matches the domain's own A records, mx matches the domain's MX servers, and all at the end is the catch-all. A typical record looks like v=spf1 include:_spf.google.com -all: "Google's servers are authorized; everyone else is not."

The 10-DNS-lookup limit

RFC 7208 caps SPF evaluation at 10 DNS-consuming lookups per check. The mechanisms include, a, mx, ptr, exists, and the redirect= modifier each cost one lookup. ip4 and ip6 cost nothing.

The catch is that each include: brings in that domain's SPF record, which counts its own lookups recursively. Use Google (5+ includes internally) plus Mailchimp plus Salesforce plus HubSpot plus one custom include: and you're already over the limit. When you exceed 10, the SPF check returns permerror and fails for every sender — your legitimate Google mail starts going to spam because the limit got tripped by something else in the record. This tool counts the total for you so you can see where you stand.

Common mistakes

• Using +all — authorizes every sender on the internet to use your domain. Always a misconfiguration.
• Too many includes — exceeding the 10-lookup limit causes permerror. Use ip4/ip6 ranges directly where possible, or flatten chains.
• Using ptr — deprecated since RFC 7208 §5.5. Most receivers ignore it.
• Multiple SPF records on one domain — RFC 7208 §3.2 says only one is allowed. Receivers will fail the check.
• Forgetting the trailing all — leaves the policy ambiguous. Default to -all (strict) or ~all (softfail) for new deployments.

SPF alone isn't enough

SPF only checks the envelope sender (the address used in the MAIL FROM SMTP command). Mailing lists, forwarding, and many legitimate use cases break SPF on their own. DKIM signs the message itself and survives forwarding. DMARC sits on top, says "fail unless SPF or DKIM passes for the From: header domain," and tells receivers what to do on failure (none / quarantine / reject).

For a deeper look at your domain's DNS, the DNS records tool shows every record type in one place. The DNS propagation checker is useful right after you update an SPF record to confirm the new value has reached resolvers worldwide.