SPF record checker

What an SPF record does

SPF (Sender Policy Framework) lets a domain publish, in DNS, the list of servers that are allowed to send email for it. When a message arrives, the receiving server looks at the domain in the envelope sender (the Return-Path, also called MAIL FROM) and reads that domain's SPF record. If the connecting IP address is on the list, SPF passes. If not, the record says what the receiver should do about it.

SPF does not look at the From address your recipients see. That is why a message can pass SPF and still fail DMARC: the two domains have to line up, and SPF alone does not make them.

How to read the record

An SPF record is a single line of text that starts with v=spf1 and is made of terms read from left to right. The first term that matches the sending IP decides the result.

The 10 DNS lookup limit

The SPF standard (RFC 7208) lets a receiver spend at most ten DNS lookups evaluating a record. The terms include, a, mx, ptr, exists and redirect each count, and so does every lookup inside an included record. Go past ten and the result is a permanent error, which receivers treat as a failure.

Stacking several email services is the usual cause: a marketing platform, a helpdesk, a CRM and a mail provider can use most of the budget between them. The checker follows every include the way a receiver does and shows the count against the limit, so you can see which branch is expensive.

The standard also limits "void" lookups (names that return nothing) to two. An include that points at a domain with no SPF record is counted as a problem for that reason.

Fixes that work: remove services you no longer use, replace a, mx and include terms with ip4 and ip6 ranges where the provider publishes stable ones, and send different kinds of mail from different subdomains so each has its own record.

Mistakes the checker flags

These are the problems we see most often, and the checker reports each one with a plain-language fix.

• More than one SPF record on the same domain. Receivers treat this as an error, so merge the records into one.
• A record that ends in +all, or ?all on a domain that sends real mail. +all authorises every server on the internet.
• No all term at all, which leaves the result for unlisted servers undefined.
• A typo in a mechanism name or an IP address, which makes the whole record invalid.
• An include pointing at a domain that has no SPF record, or a loop where two records include each other.
• The ptr mechanism, which is slow, unreliable and deprecated.
• A record longer than 255 characters that was pasted as one string, or one that no longer fits in a single DNS response.

What passing SPF does not tell you

A clean record means the policy is well formed. It does not prove a particular message passed. To test a real message, open its headers and read the Authentication-Results line, or paste them into our email header analyzer.

SPF also breaks when mail is forwarded, because the forwarding server's IP is not in your record. That is one reason DMARC accepts either SPF or DKIM, and why you should sign your mail with DKIM as well.

Soft fail or hard fail?

Both ~all (soft fail) and -all (hard fail) tell the receiver the sender was not authorised. In practice most receivers use SPF as one signal among several and apply their own judgement, and DMARC is what decides what happens to failing mail. Many organisations publish ~all while they are still discovering all their senders and move to -all when the list is complete. Either is acceptable; +all and a missing all are not.