---
title: Free SPF Checker
description: Read a domain's SPF record — its all policy, includes, a second-record check and a count of the DNS lookups the record itself makes (includes are counted, not followed).
canonical: https://watchfor.io/spf-record-checker
---

[Back to all free tools](/free-tools)

# SPF Checker

Read a domain's SPF record — its all policy, includes, a second-record check and a count of the DNS lookups the record itself makes (includes are counted, not followed).

[How to use this tool](/blog/how-to-check-an-spf-record)

Result

No result yet

Fill in the form above and run it — the result appears here.

Monitor this 24/7 — get alerted when a failure is confirmed.

[Start free](/auth/sign-up)

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms).

## What is SPF Checker ?

SPF (Sender Policy Framework, RFC 7208) is the DNS record that says "these servers are allowed to send mail for my domain." Mail receivers query it during SMTP delivery: if the connecting IP isn't on the list, the mail is treated as suspicious or rejected. SPF is the oldest of the email authentication trio (SPF, DKIM, DMARC) and the most commonly misconfigured.

This tool fetches your SPF record and shows it with its all policy, the number of include: terms, whether a redirect= is present, and a count of the DNS lookups the record itself makes (RFC 7208 caps evaluation at 10; go over and SPF fails). It flags a second v=spf1 record, which breaks SPF. The count covers the top-level record only: includes are counted, not followed, so the lookups nested inside them aren't added. Check what each include costs before you add one.

## How it works

SPF evaluation is recursive DNS plus a tiny pattern language. Here is what receivers do, and what this tool shows:

- 1 Fetch the SPF record — Query TXT <domain> . SPF lives in a TXT record starting with v=spf1 . Multiple TXT records may exist for other purposes (DMARC at _dmarc , verification records); we filter for the SPF one.
- 2 Parse mechanisms — Each space-separated token is a mechanism. ip4:1.2.3.4 authorises an IP. ip6:2001:db8::/32 authorises an IPv6 range. a: and mx: authorise the domain's A/MX records. include:other.com recursively checks other.com 's SPF. redirect=other.com replaces the lookup entirely.
- 3 Count the lookups — A receiver fetches each include: and evaluates it, and every lookup inside it counts toward the 10. This tool counts the lookup terms in your own record ( include: , a , mx , ptr , exists: , redirect= ) and doesn't follow includes, so treat its number as a floor: include:mailgun.org shows as 1 but costs more once its own includes are resolved. dig TXT on the included name shows what it adds.
- 4 Apply the terminating mechanism — ~all = soft fail (mail from unlisted IPs is marked suspicious). -all = hard fail (mail rejected). ?all = neutral (no opinion). +all = pass everyone (always wrong, never use). The terminating mechanism is what receivers apply when an inbound IP doesn't match any other mechanism.

## When you'd use it

### Adding a new ESP / sender

Onboarding SendGrid, Mailchimp, Postmark, etc. They give you an include: to add. Run an SPF check before AND after to confirm the new include resolved correctly, the total DNS lookup count is still ≤10, and you didn't accidentally end up with two SPF records.

### Investigating an SPF "PermError"

Receiver bounces with "SPF PermError" — your SPF is invalid. Most common cause: >10 DNS lookups. Run the check, count the lookups, flatten or remove unnecessary includes to get under the limit.

### Auditing what your domain currently authorises

Run the check and read the record. Surprise entries (an old ESP you stopped using years ago, a third party with a broad include) are technical debt: each one lets that provider's servers send as you. Removing them tightens your security posture.

### Pre-DMARC p=reject deployment

Before moving DMARC to p=reject , confirm SPF (or DKIM) covers every legitimate sender you have. Compare the record's includes and IP ranges with your actual sending services and your DMARC aggregate reports. Anything sending from outside them will start bouncing under p=reject .

### Brand spoofing investigation

Phishing campaign using your domain. Check your SPF — does it have ~all (soft fail, receivers may still deliver to spam) or -all (hard fail, receivers reject)? Move from ~all to -all for stricter protection.

## Reading the result

### Record

The SPF record as published. Each ip4: , ip6: , a , mx , include: is one mechanism. The order matters — SPF evaluation stops at the first matching mechanism. So ip4:1.2.3.4 -all means: if you're 1.2.3.4 you pass, anything else hard-fails.

### Includes and redirect

How many include: terms the record has, and whether it hands off to another domain with redirect= . The tool doesn't expand them into IP ranges; to see what an include authorises, look it up with dig TXT <included-name> .

### DNS lookup count

RFC 7208 limit is 10. Each include: , a , mx , ptr , exists: and redirect= counts as one; ip4: / ip6: are free. The number here counts your record's own terms only. Nested lookups inside includes also count at the receiver, so the real total can be higher — amber from 9, red above 10. Exceed 10 and your SPF returns PermError.

### Terminator ( all mechanism)

-all = strict (reject unauthorised). ~all = soft fail (mark suspicious). ?all = no opinion. +all = always pass (misconfiguration). Without a terminator, your SPF is incomplete and behaviour for unauthorised senders is undefined.

## Common pitfalls

### More than 10 DNS lookups

Most common SPF failure mode, and the one a top-level count hides: each include: adds 1 plus whatever its own includes cost (Mailgun's adds several). This tool doesn't count the nested ones, so a record showing 8 can already be at 10. Audit and flatten: drop unused includes, replace heavy ones with literal ip4: ranges, or use an SPF flattening service.

### Multiple SPF records on one domain

Only ONE TXT record starting with v=spf1 is allowed per domain. Two = PermError, mail fails. Common when adding a new ESP — admins add a new record instead of merging into the existing one. Consolidate to a single record with all include: mechanisms.

### include: for an ESP you no longer use

Each unused include: is an authorised sender (any IP they own can send as you), a DNS lookup against your limit, and an audit-trail mess. Periodically prune.

### +all set during testing and never removed

+all authorises every sender on the internet to send as your domain. Effectively no SPF protection. Remove immediately; replace with ~all or -all .

## Run SPF Checker on every change, not just once.

Get alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card.

[Start free](/auth/sign-up)

## Frequently asked questions

What's the SPF DNS lookup limit and why does it exist? RFC 7208 caps SPF evaluation at 10 DNS lookups to prevent SPF being used as an amplification attack on DNS infrastructure. Each include: , a: , mx: , ptr: , exists: adds one lookup. Exceed 10 and receivers MUST return PermError (treat as if SPF doesn't exist).

Does SPF protect against email spoofing? Partially. SPF authorises sending servers — receivers can check if mail came from an authorised IP. But SPF doesn't protect against modification, and it fails when mail is legitimately forwarded (forwarder's IP isn't in original SPF). DMARC is needed for full anti-spoofing.

Can I have multiple SPF records? Multiple TXT records on the same name are allowed by DNS, but SPF specifies only ONE may start with v=spf1 . If you have two, receivers will reject SPF evaluation entirely (PermError). Consolidate into one record.

What does ~all vs -all mean for actual delivery? With DMARC p=reject in place, both behave similarly — DMARC enforces. Without DMARC, ~all is a softer signal (receivers may quarantine to spam) and -all is stricter (receivers should reject). Modern recommendation: -all + DMARC p=reject .

Why does my SPF show +a or +mx mechanisms? +a authorises the domain's own A records as senders (i.e. if example.com resolves to 1.2.3.4, then 1.2.3.4 can send for example.com ). +mx authorises the domain's MX records. + is the default qualifier — a and +a are equivalent.

How do I flatten my SPF record? Take each include: reference, resolve its full IP range list, then write those IPs directly in your SPF as ip4: / ip6: mechanisms. This avoids the DNS lookups but means your SPF is now a snapshot — if the ESP changes their IPs, you have to re-flatten. SPF flattening services automate this.

Will failing SPF send my mail to spam? Depends on the receiver's policy and whether DMARC is in play. With DMARC at p=quarantine or p=reject , SPF failure typically means spam folder or bounce. Without DMARC, receivers vary — Gmail is strict, others lenient. Don't rely on lenient receivers.

What's the difference between SPF and DKIM? SPF validates the connecting IP. DKIM cryptographically signs the message content. SPF doesn't survive forwarding (the forwarder's IP isn't in your SPF); DKIM does (the signature is on the content, regardless of who sent it). Use both.

## Related email tools

- [Email HealthCheck a domain's SPF and DMARC records in one run, with a letter grade. DKIM needs a selector, so it shows as not checked here; use the DKIM Checker for the key.](/email-policy-checker)
- [DKIM CheckerCheck the DKIM key published for a selector — the record, key type and key size, and whether the key is live or revoked.](/dkim-record-checker)
- [DMARC CheckerRead a domain's DMARC record — policy, subdomain policy, pct, alignment modes and whether aggregate and failure reports are requested.](/dmarc-record-checker)
- [SMTP Server TestConnect to any mail server on port 25, 465 or 587 from a real probe location and see what a sending server sees — the banner, whether STARTTLS is offered, whether reverse DNS matches, and whether it relays for strangers. Verify a new mail host before you route production mail through it.](/smtp-test)

---

Canonical page: https://watchfor.io/spf-record-checker · Site guide: https://watchfor.io/llms.txt
