SPF Record Checker — Validate and Troubleshoot Your SPF Configuration
Validate your Sender Policy Framework (SPF) record to ensure email deliverability and authorized sending.
What Is SPF and How Does It Work?
Sender Policy Framework (SPF) is an email authentication method defined in RFC 7208. It allows domain owners to publish a DNS TXT record listing which IP addresses, mail servers, and third-party services are authorized to send email on behalf of their domain. When a receiving server gets an email, it checks the envelope sender (Return-Path) domain's SPF record and compares the sending server's IP against the authorized list. If the IP is listed, SPF passes; if not, the result depends on the record's 'all' qualifier — hard fail (-all), soft fail (~all), or neutral (?all).
What Does Our SPF Checker Validate?
Our tool performs a comprehensive SPF analysis. It retrieves the SPF TXT record from DNS, recursively resolves every include, a, mx, and redirect mechanism, and counts the total DNS lookups. The RFC limits SPF to 10 DNS lookups — exceeding this causes a permanent error (permerror), which many receivers treat as a hard fail, meaning your legitimate email may be rejected. The tool also checks for: multiple SPF records on the same domain (invalid per RFC), use of the deprecated ptr mechanism, overly broad IP ranges using CIDR notation, missing or incorrect 'all' qualifier, void lookups (mechanisms resolving to empty results), and overall record length relative to DNS TXT record size limits.
Understanding the 10 DNS Lookup Limit
The 10-lookup limit is the most common SPF issue for organizations using multiple SaaS platforms. Each 'include' mechanism triggers at least one DNS lookup, and nested includes within those services add more. For example, if your SPF includes Google Workspace, Microsoft 365, Mailchimp, and SendGrid, each of those includes may themselves include additional domains — quickly exhausting the 10-lookup budget. When the limit is exceeded, the entire SPF evaluation terminates with a permerror, and the receiving server cannot determine whether the sender is authorized. Our checker counts every lookup and clearly shows where your budget is being consumed.
How to Fix Common SPF Issues
If your lookup count exceeds 10, consider SPF flattening — replacing include mechanisms with their resolved IP addresses. This reduces lookup counts but requires ongoing maintenance as provider IP ranges change. SimpleDMARC's hosted SPF (SimpleSPF) automates flattening and keeps your record up to date. If you have multiple SPF records, consolidate them into one. Replace any deprecated ptr mechanisms with explicit IP or include entries. Ensure your record ends with -all (hard fail) once all legitimate senders are accounted for, rather than the less secure ~all (soft fail) or the completely open +all.
Tag Reference
The following tags/parameters are checked or generated by this tool:
Tag | Description |
v=spf1 | SPF version identifier. Must be the first token in the record. Required. |
ip4: | Authorize a specific IPv4 address or CIDR range (e.g., ip4:203.0.113.0/24). |
ip6: | Authorize a specific IPv6 address or CIDR range. |
include: | Include the SPF record of another domain (e.g., include:_spf.google.com). Counts as a DNS lookup. |
a | Authorize the IP addresses in the domain's A/AAAA DNS records. Counts as a DNS lookup. |
mx | Authorize the IP addresses of the domain's MX servers. Counts as a DNS lookup. |
redirect= | Redirect SPF evaluation to another domain's SPF record. Replaces the current record entirely. |
-all | Hard fail: reject email from sources not listed in the record. Recommended for enforced domains. |
~all | Soft fail: accept but mark email from unlisted sources. Common during SPF deployment phase. |
?all | Neutral: no assertion about unlisted sources. Provides no protection. |