SPF Record Checker

Validate your SPF record, see every include, count DNS lookups against the limit of 10, and test whether a sending IP is authorised.

Enter the domain in your "From" address. Add a sending server's IP to see whether SPF would pass for it.

What this SPF record checker does

SPF (Sender Policy Framework) is a TXT record that lists the servers allowed to send email for your domain. This SPF record checker reads your record and checks it the way receiving mail servers do:

  • Syntax and count: exactly one SPF record must exist. Two or more cause a permanent error, and SPF fails.
  • Full include tree: every include: and redirect= is followed, so you can see what each email service you use adds to your record.
  • DNS lookup limit: mechanisms that need DNS lookups (include, a, mx, exists, ptr, redirect) are counted across the whole tree against the limit of 10 in RFC 7208.
  • Void lookups: lookups that return nothing are counted against the limit of 2.
  • Default policy: how the record ends (-all, ~all, ?all or +all).
  • Risky settings: very broad IP ranges, the deprecated ptr mechanism and unknown terms are flagged.

Enter a sending IP address as well to run a full SPF evaluation for it. You'll see whether a message from that server would get Pass, Fail, SoftFail or Neutral, and which part of the record decided it.

The 10-lookup limit, explained

Each include costs one lookup, plus every lookup inside the included record. Popular services use several: an include for Google Workspace or Microsoft 365 typically costs 1–4 lookups once its nested includes are counted. Add a marketing platform, a help desk and a CRM, and it's easy to pass 10 without noticing. When that happens, receivers return PermError and SPF fails for every message, including legitimate ones.

To get back under the limit:

  • Remove includes for services you no longer use.
  • Replace a and mx with the actual ip4:/ip6: ranges, which cost no lookups, if those addresses rarely change.
  • Send marketing or bulk email from a subdomain (for example news.example.com) with its own SPF record.

Reading the result: qualifiers

QualifierResultWhat receivers usually do
+ (default)PassAccept: the sender is authorised.
-FailReject or treat as spam, especially with DMARC.
~SoftFailAccept but mark as suspicious. The most common ending.
?NeutralNo opinion: offers no protection.

With a DMARC policy in place, ~all and -all protect equally well in practice, because DMARC makes the final decision. Never use +all: it authorises every server on the internet.

SPF on its own is not enough

SPF checks the hidden "envelope" sender, not the From address people see, and it breaks when mail is forwarded. That's why receivers combine it with DKIM signatures and a DMARC policy. Use all three, and check them together with the DNS Health Checker.

Frequently asked questions

Can I have two SPF records?

No. A domain must publish exactly one TXT record starting with v=spf1. If you use several services, combine them in one record, e.g. v=spf1 include:_spf.google.com include:sendgrid.net ~all.

What is a void lookup?

A DNS lookup in your SPF evaluation that returns no records, such as an include pointing at a name with no SPF record. RFC 7208 allows at most two, after which receivers return PermError.

Why does a macro show "can only be evaluated for a specific sender"?

Macros like %{i} insert details of each message (such as the sending IP) into a lookup, so their result can't be known in advance. They're shown but not followed.

My domain doesn't send email. Do I need SPF?

Yes. Publish v=spf1 -all to tell receivers that no server may send mail as your domain. This stops spammers using it.