Skip to main content
Start free

Free · no signup

SPF Record Checker & Lookup Counter

Fetch a domain's SPF record, expand every include into a tree and count all DNS lookups against RFC 7208's hard limit of 10 — before a permerror junks your mail.

The 10-lookup limit that quietly breaks SPF

An SPF record answers one question for every mail server on earth: which machines are allowed to send mail as your domain? It is a single TXT record starting v=spf1, listing IP ranges and — far more often — include: pointers at the SPF records of the services that send for you: Google Workspace, your marketing platform, your helpdesk, your invoicing tool. Receivers fetch it, expand it and compare the connecting IP. SPF is one third of the email-authentication stack alongside DKIM and DMARC.

The catch is that expansion costs DNS queries, and the receiver pays for them — on every single inbound message. That is why RFC 7208 caps evaluation at 10 DNS-querying mechanisms: without the cap, a hostile record with deeply nested includes would turn every mail server into a DNS flood machine, so the limit is denial-of-service protection, not pedantry. Each include, a, mx, ptr and exists costs one lookup, redirect= costs one, and the count is recursive — an include costs one lookup itself plus everything inside the record it points at.

Cross the limit and receivers return permerror — which they treat exactly as if you had no SPF record at all. That is expensive now that Gmail and Yahoo's bulk-sender rules require passing authentication before your mail is accepted. And the failure mode is sneaky: includes accumulate silently. Each SaaS tool you onboard says "just add our include", each of those includes contains its own lookups, and one day a vendor restructures their record and your total ticks from 10 to 11 without anyone touching your DNS. The common fix, SPF flattening, replaces includes with the raw IPs behind them — it works, but flattened records rot as vendors move IPs, so it only holds up when the re-flattening is automated. While you're here, check your DMARC and DKIM too — SPF alone stops nothing without a DMARC policy on top.

A lookup count you checked once is a snapshot; the tree underneath it belongs to your vendors and changes without notice. A CompleteStatus email security monitor re-counts your SPF lookups as often as twice a day, flags a record over the limit on your dashboard, and alerts you if your SPF or DMARC record disappears — start monitoring free.

Frequently asked questions

An SPF (Sender Policy Framework, RFC 7208) record is a TXT record at your domain starting with v=spf1 that lists which servers are allowed to send mail as your domain. Receiving servers look it up on every inbound message and compare the connecting IP against the list — mail from a server you never authorized can then be rejected or junked instead of landing in inboxes with your name on it.

RFC 7208 §4.6.4 caps evaluation at 10 DNS-querying mechanisms because the RECEIVER does those lookups live, on every single inbound message. Without a cap, a hostile record with deeply nested includes could turn every receiving mail server into a DNS flood machine — the limit is denial-of-service protection. Go over it and evaluation stops with a permerror.

The mechanisms include, a, mx, ptr and exists cost one lookup each, and the redirect= modifier costs one too. ip4, ip6, all and exp= are free — they need no DNS. Crucially the count is recursive: every include costs one lookup itself PLUS whatever its record contains, which is how a tidy-looking record with four vendor includes quietly reaches 12.

A permanent evaluation error: more than 10 DNS lookups, more than 2 void lookups (queries that come back with no records), an include or redirect pointing at a domain with no SPF record, multiple v=spf1 records, or broken syntax such as an unknown mechanism. Receivers treat a permerror as if you published no SPF at all — and under DMARC the SPF pass disappears, so a domain relying on SPF alignment starts failing DMARC across the board.

First remove includes for services you no longer use and duplicate includes — those are free wins. Replace a and mx with explicit ip4/ip6 blocks where the IPs are stable, and drop ptr entirely. The last resort is SPF flattening: replacing includes with the raw IPs behind them. It works, but honestly: vendors change their IPs without notice, so a flattened record silently rots unless you re-flatten it automatically and continuously.