SPF Checker Verify the existence, syntax, and authorized IP mechanisms of a Sender Policy Framework (SPF) record.

Guide FAQ

live DNS · read-only · no signup

The SPF Checker performs a live DNS TXT lookup for your domain's Sender Policy Framework record, parses every mechanism and modifier, counts DNS lookups, detects dangerous configurations like +all, and returns actionable results in seconds.

What is an SPF Record?

SPF (Sender Policy Framework) is an email authentication standard defined in RFC 7208. It allows domain owners to specify exactly which mail servers are authorized to send email on their behalf.

An SPF record is a DNS TXT record published at the root of your domain (yourdomain.com). When a receiving server gets an email claiming to be from your domain, it checks your SPF record to see if the sending server's IP is listed. If it is not, the email may be marked as spam or rejected.

SPF alone is not sufficient to stop spoofing because it validates the envelope sender (MAIL FROM), not the visible From: header. This is why SPF must be combined with DKIM and DMARC.

Prevents unauthorized servers from sending email as your domain
Validated against the envelope sender (MAIL FROM), not the From: header
Limited to 10 DNS lookups per evaluation (RFC 7208 requirement)
Must be combined with DKIM and DMARC for complete protection
A single TXT record at the root domain — multiple SPF records cause failures

Why SPF is Critical for Email Deliverability

Without an SPF record, your domain is a prime target for email spoofing. Spammers can send emails from any server claiming to be from your domain, harming your reputation and damaging trust with your customers.

Beyond security, SPF directly affects email deliverability. Gmail, Outlook, Yahoo, and other major providers use SPF as a key factor in spam scoring. Domains without SPF, or with invalid SPF records, see significantly higher bounce rates and spam folder placement.

Required by Google and Yahoo for bulk email senders since 2024
Missing SPF = any server can spoof your domain
Invalid SPF (permerror) causes some receivers to reject all your mail
Exceeding 10 DNS lookups causes a permerror that breaks authentication
+all (pass all) effectively disables SPF protection entirely

How This SPF Checker Works

Validates the domain input (no private IPs, no invalid formats)
Queries DNS TXT records at the root domain
Identifies the record starting with "v=spf1"
Parses all mechanisms: include:, a:, mx:, ip4:, ip6:, ptr:, exists:
Counts DNS-lookup mechanisms and warns if the 10-lookup limit is approached or exceeded
Evaluates the final "all" qualifier: -all (fail), ~all (softfail), +all (dangerous)
Returns status with recommendations

How to Use the SPF Checker

Enter your domain name (e.g., example.com) without http://
Click "Check SPF" to run the DNS lookup
Review the parsed mechanisms and modifiers
Check the DNS lookup count — must stay below 10
Review recommendations for the "all" qualifier and any issues found

Understanding SPF Mechanisms and Qualifiers

An SPF record is made up of mechanisms (what to match) and qualifiers (what action to take on a match).

Field / Value	Meaning
`+all`	DANGEROUS — passes ALL servers regardless of whether they are authorized. Effectively disables SPF protection.
`-all`	FAIL — any server not explicitly listed should be rejected. This is the recommended final mechanism for strict enforcement.
`~all`	SOFTFAIL — unlisted servers are marked as suspicious but still delivered. Used during migration or testing.
`?all`	NEUTRAL — no assertion is made. Equivalent to having no SPF record for unlisted senders.
`include:`	Includes another domain's SPF record. Each include= counts as one DNS lookup toward the 10-lookup limit.
`ip4:`	Authorizes a specific IPv4 address or CIDR range. Does not count toward the DNS lookup limit.
`ip6:`	Authorizes a specific IPv6 address or CIDR range. Does not count toward the DNS lookup limit.
`a:`	Authorizes the A/AAAA records of a domain. Counts as one DNS lookup.
`mx:`	Authorizes the MX servers of a domain. Counts as one DNS lookup.
`redirect=`	Replaces the current SPF record with that of another domain. Counts as one DNS lookup.

Common Problems & How to Fix Them

Your domain has no SPF record, meaning any server can send email claiming to be from your domain without any enforcement.

Add a TXT record at your domain root:
Value: v=spf1 include:_spf.google.com -all (adjust for your mail provider)

Common include values:
- Google Workspace: include:_spf.google.com
- Microsoft 365: include:spf.protection.outlook.com
- Mailchimp: include:servers.mcsv.net

+all means every server in the world passes SPF for your domain. This completely defeats the purpose of SPF.

Replace +all with -all (fail) to reject unauthorized senders, or ~all (softfail) as a transitional step.

RFC 7208 limits SPF evaluation to 10 DNS lookups (include:, a:, mx:, exists:, redirect=). Exceeding 10 causes a permerror — receiving servers may reject or ignore your SPF record.

Fix options:
1. Remove unnecessary include: statements
2. Replace include: with ip4: for static IP ranges
3. Use an SPF flattening service to merge all IPs into a single record

Only one SPF record is allowed per domain. Multiple records cause an SPF permerror, which many receivers interpret as a failing result.

Delete all but one SPF record and combine all mechanisms into a single record.

If you use third-party email services (CRMs, marketing tools, ticketing systems), their sending servers must be included in your SPF record.

Common services that need to be added:
- Mailchimp: include:servers.mcsv.net
- SendGrid: include:sendgrid.net
- Mailgun: include:mailgun.org
- Salesforce: include:_spf.salesforce.com

Best Practices

Use -all (hard fail) as your final mechanism once all legitimate senders are included
Keep DNS lookup count below 8 (well under the 10-lookup limit) to leave headroom for nested includes
Prefer ip4: and ip6: for static IP addresses to avoid consuming DNS lookups
Audit your SPF record every time you add or remove an email service provider
Never use +all — it completely disables SPF protection
Combine SPF with DKIM and DMARC for complete email authentication
Test SPF by sending email through all authorized services and checking headers
Use a single SPF record — never publish two TXT records starting with v=spf1

Security Recommendations

Replace ~all (softfail) with -all (fail) once all legitimate senders are confirmed
Remove any include: for services you no longer use to reduce attack surface
Do not authorize entire IP ranges (large /8 or /16 CIDRs) unless strictly necessary
Monitor your DMARC reports to identify senders failing SPF alignment
Consider IP4 flattening to prevent lookup count issues as your provider list grows

Frequently Asked Questions

An SPF record is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. Without one, anyone can send email claiming to be from your domain, which is used in phishing, spam, and business email compromise attacks. It is also required by Google and Yahoo for bulk email senders.

-all (hard fail) tells receiving servers to REJECT emails from servers not listed in your SPF record. ~all (soft fail) tells servers to mark those emails as suspicious but still deliver them. -all provides stronger protection but should only be used once all legitimate senders are confirmed in your SPF record.

RFC 7208 limits SPF evaluation to a maximum of 10 DNS lookups. This includes include:, a:, mx:, ptr:, and exists: mechanisms. If this limit is exceeded, the SPF evaluation returns a permerror, which many receivers treat as a failure. ip4: and ip6: mechanisms do not count toward this limit.

No. Only one SPF record is allowed per domain. If you have multiple TXT records starting with "v=spf1", it causes a permerror and SPF breaks entirely. Combine all mechanisms into a single record.

No. SPF only verifies the envelope sender (MAIL FROM), not the visible From: header that users see in their email client. Attackers can pass SPF while still spoofing the From: header. You need DKIM + DMARC to enforce alignment between the envelope and the visible From: header.

A permerror means the SPF record has a permanent error that cannot be resolved during evaluation — most commonly caused by exceeding 10 DNS lookups, having multiple SPF records, or syntax errors in the record. Receiving servers may treat permerror as a failure and reject or spam-folder your emails.

Add or update your domain's SPF TXT record to include: v=spf1 include:_spf.google.com ~all. If you also use other email services, add their include: values before the final all mechanism: v=spf1 include:_spf.google.com include:sendgrid.net -all

SPF failures are usually caused by: (1) Third-party email services (CRMs, marketing tools) not included in your SPF record. (2) Forwarded emails — SPF breaks when email is forwarded because the forwarding server's IP is not in your original SPF record. (3) DMARC alignment failures where the envelope sender domain does not match the From: header domain.