SPF checker for all your domains

An SPF record is a TXT record that starts with v=spf1 and lists the servers allowed to send mail for a hostname. Each hostname gets one. Receivers check it against the envelope sender (the Return-Path, also called MAIL FROM) and the server's HELO name, not the From line you see, as RFC 7208 sections 2.3 and 2.4 describe.

SPF is looked up per hostname, so updates.yourdomain.com needs its own record if mail goes out with that Return-Path, and the record at yourdomain.com does nothing for it. That's why this SPF record checker takes subdomains as well as domains. Our guide to SPF on a subdomain sets it up on a live domain.

Each domain gets one verdict pill:

• Valid (green): one SPF record, 7 or fewer DNS lookups, nothing to fix.
• Valid, with a warning (amber): SPF works, but something needs a look, like 8 to 10 lookups, ?all or no all term, terms after all, an include listed twice, or an SPF record over 450 bytes.
• SPF fails (red): receivers return a permanent error (permerror), from two SPF records, more than 10 lookups, more than 2 void lookups, a syntax error, a loop, or an include with no SPF record.
• Any server passes (red): the record ends in +all, so every server on the internet passes SPF as you. SPF technically passes, which is the problem.
• No SPF record (amber): no TXT record starting with v=spf1 at that name, or a name that doesn't exist.
• Couldn't check (grey): DNS didn't answer in time. Try again in a minute.

Next to the pill you get the lookup meter ("7 of 10 DNS lookups", green up to 7, amber from 8 to 10, red past 10), the qualifier pill, and a one-line verdict that names the heaviest include. Open a domain to see the raw record, the include tree (every include and redirect with its own record, how many of the 10 lookups it uses, and how deep it sits) and each finding with its fix. Each SPF lookup reads live public DNS, so you see what receivers see right now.

The qualifier pill shows how the record ends (RFC 7208 section 4.6.2):

• -all (fail): servers you haven't listed aren't allowed.
• ~all (softfail): not allowed, but the domain isn't making a strong statement. Section 8.5 says receivers should not reject mail on softfail alone.
• ?all (neutral): no opinion. A record with no all term ends with an implied ?all (section 4.7).
• +all (pass): every server on the internet may send as you. Always red.

Our take: with DMARC at quarantine or reject, ~all and -all behave much the same for DMARC, because DMARC decides on SPF or DKIM passing and aligning.

RFC 7208 section 4.6.4 caps the terms that make a receiver query DNS at 10 per SPF check, counted through every nested include. Past 10, receivers return permerror.

Separately, RFC 7208 recommends at most 2 void lookups: lookups that return no records, or a name that doesn't exist. Past 2, receivers return permerror as well.

Permerror means SPF doesn't pass for any of your mail, so DMARC rests on DKIM alone.

Each of these is a check the tool runs:

• Two SPF records. Every message gets permerror (section 4.5). Merge them into one record with every include and one all. v=spf1 include:_spf.google.com ~all and v=spf1 include:zohomail.com ~all become v=spf1 include:_spf.google.com include:zohomail.com ~all. The checker suggests the merged record with its lookup count, and our guide to merging Cloudflare's include with an existing record shows it on a live domain.
• Over 10 lookups. Remove includes for services you no longer use, replace a and mx with the ip4 and ip6 addresses behind them, and drop ptr. Flattening (replacing includes with the IPs they resolve to) works too, but it goes stale when the sender changes IPs, so check it again after any change.
• More than 2 void lookups. Usually an include for a service you left, whose record is gone. Delete it.
• +all. Change it to ~all or -all.
• No all term, or terms after all. Terms after all are never tested (section 5.1), so move them before it, and end the record with ~all or -all.
• Record too long. Section 3.4 suggests keeping the name plus every TXT record at it under 450 bytes, so the DNS answer fits in one 512-byte UDP packet. Long records are split into 255-character strings in DNS (section 3.3), which is fine. The checker warns when the SPF record itself is over 450 bytes, and only adds a note when other TXT records, like site verification codes, push the total past it, since most receivers handle larger answers.

The includes come from Google's SPF setup page and Microsoft's SPF guide, and the lookup counts were measured over public DNS on October 24, 2026. Senders can change what sits behind an include, so run your own domain through the checker for today's count.

Some senders don't need your root record at all. Postmark, and Mailyond, which sends through it, check SPF on a Return-Path subdomain that is a CNAME to the sender, so connecting a domain adds no lookup to your root SPF.

Every domain you send from needs its own SPF record, or a Return-Path that has one. It's normal for one domain to be fine and another to sit at 11 lookups after someone added a new tool, so paste them all in one go. If you're sending from several domains, run the list again after each new sender you add.

SPF passing isn't the whole story: DMARC also needs the passing domain to align with the From. Run the same domains through the DMARC checker, which checks the policy and alignment settings on the same domains.