SPF checker

What an SPF record does

SPF (Sender Policy Framework, RFC 7208) is a list of the servers allowed to send mail for your domain, published as one TXT record at the root of the domain. When a message arrives, the receiving server takes the domain from the envelope sender (the Return-Path, which people never see), fetches that domain’s SPF record, and checks whether the connecting server’s IP address is on the list.

A record looks like this:

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

It reads left to right. include: pulls in another domain’s SPF list (how email services publish their servers), ip4: and ip6: list addresses directly, a and mx authorize the domain’s own web or mail servers, and the final all says what to do about everything else.

How to read the results

The checker finds every TXT record at the domain that begins with v=spf1, then:

• confirms there’s exactly one;
• checks each term’s syntax, catching unknown mechanisms, bad IP ranges and the common include= typo;
• looks at the final all rule;
• follows every include: and redirect= to count DNS lookups the way a receiver would, showing the tree of nested records. It stops at loops and caps how deep and how many records it follows.

A fail means receivers will return a permanent error (permerror) or SPF gives no protection at all. A warning means SPF works but is fragile or weak. When the problem can be fixed mechanically (a missing or weak all, a ptr term, entries after all, or several records that need merging), you get a corrected record to copy.

The 10-lookup limit

This is where most SPF records break. To stop SPF being used to flood DNS, RFC 7208 (section 4.6.4) caps the number of terms that need a DNS lookup at 10 per check. The terms that count are include, a, mx, ptr, exists and the redirect modifier, and the count includes everything nested inside your includes. ip4, ip6 and all are free. Go over 10 and the receiver stops with a permanent error, so SPF fails for every message, including the legitimate ones.

The trap is that you can’t see nested lookups by reading your own record. One include: for a large provider can cost three or four lookups by itself. The checker counts all of them and shows the tree, so you can see which include is expensive. It also counts “void” lookups: includes that point at a name with no SPF record. RFC 7208 recommends failing after two of those, and an include with no SPF record behind it fails anyway.

The checker counts lookups exactly for include and redirect, which it follows. For mx, it counts the term itself but doesn’t also count the address lookups for each mail server, which RFC 7208 limits separately to 10 per mx term.

SPF checks the Return-Path, not the From address

Receivers check SPF on the domain in the envelope sender, also called the Return-Path, which isn’t always the domain your customers see. Many sending services, including Postmark (which InboxNest uses), give each domain a custom Return-Path: a subdomain such as pm-bounces.yourdomain, set up as a CNAME to pm.mtasv.net. SPF for that mail is checked on pm-bounces.yourdomain, whose record already authorizes Postmark’s servers. Because the subdomain belongs to your domain, it also aligns for DMARC (Postmark: custom Return-Path).

So a domain can send perfectly authenticated mail through Postmark without any SPF record at its root. Postmark says so directly: “The Return-Path domain is now used by receiving email domains to check for SPF alignment” (Postmark: why Postmark isn’t needed in your SPF record). When the checker finds a Postmark Return-Path at pm-bounces, it checks SPF there. It only asks for a root SPF record if your mailboxes are at a provider, such as Google Workspace or Microsoft 365, that sends with the root domain as the envelope sender.

~all, -all, ?all and +all

• -all (hard fail): unlisted servers fail SPF. Microsoft recommends it for Microsoft 365 domains that also use DKIM and DMARC (Microsoft: set up SPF).
• ~all (soft fail): unlisted servers are “probably not authorized”. It’s what Google recommends for Workspace (Google: set up SPF). With DMARC in place, either works, because DMARC decides what happens to the failure.
• ?all (neutral): says nothing, so it protects nothing. The checker warns about it.
• +all: authorizes every server on the internet. Always a mistake, and a fail.
• No all and no redirect=: the result defaults to neutral, the same as ?all.

Common mistakes, and how to fix each

• Two SPF records. It happens when a new service tells you to “add this TXT record” and you add it alongside the old one. RFC 7208 allows one, and with two, receivers return permerror. Merge them: keep one v=spf1, combine the includes and addresses, and end with a single all. The checker builds the merged record for you; check it before publishing.
• Over 10 lookups. Remove services you’ve stopped using, then move bulk or marketing tools to a subdomain (for example news.yourdomain) with its own SPF record and its own budget of 10. Replacing an include with ip4: ranges (“flattening”) also works, but only for providers that publish stable addresses; you have to maintain it by hand.
• An include with no SPF behind it. A typo, or a provider that changed its include name. SPF fails with a permanent error. Check the exact value in the provider’s documentation.
• Using ptr. RFC 7208 says it shouldn’t be used: it’s slow and some receivers skip it. Replace it with the addresses or includes it was standing in for.
• Entries after all. Evaluation stops at all, so anything after it is ignored. Move them before it.
• Assuming SPF covers subdomains. It doesn’t. Every hostname that sends mail needs its own record.
• Syntax slips. include= instead of include:, a space after the colon, or a stray trailing dot. Each one can break the whole record.

Why SPF matters for support email

SPF is one of the two checks every major mailbox provider asks for. Gmail requires SPF or DKIM from all senders and both from those sending more than 5,000 messages a day (Gmail sender guidelines). Yahoo asks for the same (Yahoo best practices). Outlook.com requires SPF to pass for domains sending over 5,000 a day (Microsoft).

For a support team, the risk is usually a quiet one. Someone adds a new helpdesk or billing tool, its replies go out from your domain, and nobody updates SPF, or the update pushes the record past 10 lookups. Everything still looks fine from the sending side. Run the checker after every new tool you connect to your domain.

On its own, SPF only covers the hidden envelope sender. To protect the From address your customers read, pair it with DKIM and DMARC.