Look up, validate, and debug the SPF record on any domain. Counts the full DNS lookup chain against the 10-limit, flags multiple records, and gives specific fixes.
This tool resolves the SPF TXT record on any domain, parses every mechanism, and recursively walks the include chain to count total DNS lookups against the RFC 7208 limit of 10. It also flags the most common SPF configuration errors that silently break authentication and route legitimate mail to spam.
When a receiving mail server evaluates your SPF, it has to resolve every include: and a/mx/exists: mechanism by making DNS queries. RFC 7208 caps the total number of lookups at 10 to prevent SPF evaluation from being a DoS vector. Exceed 10 and the receiver returns PermError - most modern receivers treat this as outright SPF failure.
The trap is that lookups compound recursively. include:_spf.google.com alone burns 3 lookups (one for the include, two more inside Google's resolved record). Add Mailchimp, SendGrid, and your own a/mx and you're at the limit before you notice.
Three ways to fix: (1) Audit what's actually sending and remove unused services. (2) Use SPF flattening - services like EasyDMARC or Valimail resolve the chain and republish as a static list of IPs (re-flatten quarterly because IPs change). (3) Split sending across subdomains, each with its own SPF.
Read our complete email authentication guide - alignment rules, multi-provider setup, the 30-day rollout, and how to verify each record.
SPF, DKIM, and DMARC ExplainedSPF (Sender Policy Framework) is a DNS TXT record that lists the IP addresses and hostnames authorized to send email on behalf of your domain. Receiving mail servers check it when an email arrives and either pass, fail, or neutral the message based on whether the sending IP appears in the list.
Two most common causes: (1) you have more than one v=spf1 TXT record on the same domain (RFC violation), or (2) your SPF exceeds 10 DNS lookups when fully evaluated. This checker detects both.
No. When a recipient forwards your email, the new sending IP is the forwarder's, not yours - so your SPF won't authorize it. This is why DKIM matters: the cryptographic signature travels with the email and survives forwarding. Always set up both SPF and DKIM, with DMARC requiring at least one to align.
Audit quarterly and after any change to your sending stack (new ESP, new transactional service, new monitoring tool). ESPs add and remove IP ranges from their published SPF records over time - what was 8 lookups can drift to 11 silently. Set a quarterly calendar reminder to re-check.