Security Diagnostic Tool

SPF Analyzer.

Verify your Sender Policy Framework records in real-time. Detect lookup overflows, syntax errors, and IP misconfigurations before they impact your deliverability.

Check live DNS records and review lookup pressure before delivery breaks.

security

Status

Awaiting analysis

DNS Lookups Run a live SPF check

Remediation Guide

Based on your record analysis, follow these steps to secure your domain reputation and ensure consistent email delivery.

Example SPF records

Three real-world SPF records covering the three patterns you will see on production domains: a single-provider record, a record that uses include= to authorize multiple sending services, and a tightly-scoped IP-based record. The hard rule on every one of these is the 10-DNS-lookup limit — go past it and SPF returns PermError.

Single-provider (Google Workspace)

example.com  TXT  v=spf1 include:_spf.google.com -all

The minimum viable SPF for a domain that sends mail only through Google Workspace. Hard-fails any sender outside the include= chain.

Multi-provider (M365 + marketing)

example.com  TXT  v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com include:sendgrid.net -all

Authorizes M365 transactional mail plus two SaaS senders. Watch the DNS lookup count — each include= burns one lookup plus whatever the target chain costs.

Tight scope (specific IPs only)

example.com  TXT  v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 ~all

No DNS lookups at all — every authorized sender is on a known CIDR. Soft-fails unknown senders (the recommended posture when DMARC is at p=reject).

Every SPF mechanism and qualifier, explained

include Authorize another SPF chain: Defers authorization to another domain's SPF record. The most common mechanism for SaaS senders. Every include= burns one of your 10 DNS lookups — and the included chain may burn more. include:_spf.google.com
ip4 Authorize an IPv4 range: Authorizes a specific IPv4 address or CIDR block. Costs zero DNS lookups, so prefer this over include= when you know the sender's static IPs. ip4:192.0.2.0/24
ip6 Authorize an IPv6 range: IPv6 equivalent of ip4. Also zero DNS lookups. Cloud providers (Azure, GCP) increasingly send over IPv6 — include both ip4 and ip6 for the same range when possible. ip6:2001:db8::/32
a Authorize the A records: Authorizes whatever IPs the host's A record currently points at. Costs one DNS lookup. Useful for domains whose web server also sends transactional mail. a:mail.example.com
mx Authorize the MX records: Authorizes the host's MX records as senders. Costs one DNS lookup plus one for each MX returned. Largely a legacy mechanism — modern SaaS senders publish via include= instead. mx
exists Conditional authorization: Authorizes the connecting IP if a specific DNS query returns ANY answer. Used for IP-block-based whitelists. Rarely seen in production. exists:%{i}.spf.example.com
redirect Replace the whole record: Delegates the entire SPF evaluation to another domain. The redirect target supplies the final qualifier. Used by managed SPF services to keep your apex record short and let the vendor manage the chain. redirect=spf.vendor.com
-all Hard fail (qualifier): Hard-fails any sender not authorized by the mechanisms above. Best at SMTP-time rejection, but breaks legitimate forwarded mail (Mailman, fwd-as-attachment). -all
~all Soft fail (qualifier): Soft-fails (treats as suspicious) any unauthorized sender. Recommended when DMARC is at p=reject — DMARC enforces alignment, SPF stays safe for legitimate forwarders. ~all
?all Neutral (qualifier): No opinion on unauthorized senders. Effectively the same as having no SPF record at all from the receiver's perspective. Do not use in production. ?all
+all Pass everything (qualifier): Authorizes every sender on the internet. A configuration mistake, almost always — it means anyone can spoof your domain via SPF. The checker flags this as an error. +all

Common SPF mistakes and how to fix them

These are the six failure modes the SPF analyzer catches most often. Every one silently breaks deliverability or, worse, leaves the domain wide open to spoofing.

Issue	What it means	How to fix it
Too many DNS lookups (>10)	SPF burns DNS lookups for every include=, a, mx, ptr, exists and redirect=. RFC 7208 caps the total at 10. Past that, receivers return PermError and SPF effectively fails.	Collapse include= chains, switch to ip4: / ip6: where IPs are known, or use a flattening service.
Multiple SPF records	More than one TXT record starting with v=spf1 exists at the apex. Receivers return PermError and ignore both.	Merge them into one. Every authorized sender must be in a single v=spf1 record.
Permanent +all qualifier	The record ends with +all, authorizing every sender on the internet. The domain is fully spoofable from an SPF perspective.	Change to -all (strict) or ~all (soft-fail). Only specific apex SPF records (e.g. SaaS vendor lists) should ever use +all.
Void lookups	An include= or a mechanism points at a host with no SPF record. RFC 7208 caps void lookups at 2 — past that, evaluation fails.	Remove the offending include= or update the target host so it publishes SPF.
Missing sending service	A legitimate sender (marketing platform, transactional service, support desk) is not authorized. Mail from that sender fails SPF and may fail DMARC alignment too.	Add the vendor's recommended include= to your SPF record. Watch the lookup count.
No final qualifier	The record ends with neither -all, ~all, nor ?all. Receivers default to neutral.	Append -all or ~all to the end of the record. Without it, SPF effectively does nothing for unauthorized senders.

Too many DNS lookups (>10)

What it means: SPF burns DNS lookups for every include=, a, mx, ptr, exists and redirect=. RFC 7208 caps the total at 10. Past that, receivers return PermError and SPF effectively fails.
How to fix it: Collapse include= chains, switch to ip4: / ip6: where IPs are known, or use a flattening service.

Multiple SPF records

What it means: More than one TXT record starting with v=spf1 exists at the apex. Receivers return PermError and ignore both.
How to fix it: Merge them into one. Every authorized sender must be in a single v=spf1 record.

Permanent +all qualifier

What it means: The record ends with +all, authorizing every sender on the internet. The domain is fully spoofable from an SPF perspective.
How to fix it: Change to -all (strict) or ~all (soft-fail). Only specific apex SPF records (e.g. SaaS vendor lists) should ever use +all.

Void lookups

What it means: An include= or a mechanism points at a host with no SPF record. RFC 7208 caps void lookups at 2 — past that, evaluation fails.
How to fix it: Remove the offending include= or update the target host so it publishes SPF.

Missing sending service

What it means: A legitimate sender (marketing platform, transactional service, support desk) is not authorized. Mail from that sender fails SPF and may fail DMARC alignment too.
How to fix it: Add the vendor's recommended include= to your SPF record. Watch the lookup count.

No final qualifier

What it means: The record ends with neither -all, ~all, nor ?all. Receivers default to neutral.
How to fix it: Append -all or ~all to the end of the record. Without it, SPF effectively does nothing for unauthorized senders.

For MSPs

How MSPs use this checker during client onboarding

Walking into a new client engagement, the SPF inventory is almost always one of the first three things you need to fix. Two patterns recur: the client has been adding include= chains for years without removing dead ones (and the lookup count is at 14, with PermError downstream), or the client has tightly-scoped ip4: ranges that haven't been updated since the office moved hosting providers and half the legitimate mail now fails.

The SPF analyzer above is the fastest way to make that diagnosis visible. Run it on the apex and each sending subdomain (marketing, support, billing). The output gives you a one-page artifact for the kick-off call: "your marketing subdomain is at 12 lookups — that's why your Mailchimp campaigns have been bouncing on Outlook," or "you have +all on the apex — that's an open spoofing vector and the urgent fix."

Once you've made the changes, run the same checker the next week to confirm DNS propagation. After that, the right place for the data is a dashboard you can check daily — SaaS adoption keeps adding senders that aren't in the SPF, and the new ones are the ones that break deliverability.

See how DMARC AI works for MSPs

From manual to managed

From one-off SPF check to continuous monitoring

An SPF checker reads the record in DNS the moment you press Analyze. What it cannot see is the SPF record that was correct yesterday but broke last night when a SaaS vendor rotated their sending host.

DMARC AI watches every client SPF record and the include= chains they depend on, flagging new lookups, void lookups, and qualifier changes as soon as they appear. The same checker you use for onboarding becomes the daily watchtower — without you running anything manually.

Start a free trial

Continuous monitoring of every apex + subdomain SPF
Alerts when lookup count crosses 8, 9, and 10
New-sender detection from DMARC aggregate reports
Cross-tenant view: every client SPF in one dashboard
Webhook + API for ticketing-system integration

Related tools

Validate the rest of your email-authentication stack alongside SPF.

verified_user

DMARC Checker

Verify your DMARC record, policy, alignment, and aggregate-report destinations.

Open tool key

DKIM Validator

Fetch a DKIM public key by selector and domain, verify the record structure and key length.

Open tool palette

BIMI Generator

Build a valid BIMI DNS record, check your SVG logo, attach a VMC certificate URL.

Open tool lock

MTA-STS Checker

Verify your domain's MTA-STS policy — TLS mode, allowed MX hosts, max_age — in one HTTPS probe.

Open tool

Continue learning

Deeper Academy reading on SPF and adjacent protocols.

SPF (Sender Policy Framework) — Complete guide

Every mechanism, qualifier, void-lookup rule, and the include= chain that breaks most production SPF records.

7 min read

DMARC explained — Complete guide

Why SPF without DMARC is fragile, how DMARC enforces alignment, and how the two protocols work together to actually stop spoofing.

8 min read

DKIM — Complete guide

The third leg of the authentication tripod. DKIM signatures survive forwarding when SPF does not, which is why DMARC alignment usually leans on DKIM.

6 min read

BIMI — Display your verified brand logo

BIMI prerequisites, SVG Tiny PS logo specs, VMC certificates, and the deliverability story that justifies the project budget.

5 min read

SPF FAQ for Professionals

What is an SPF checker? expand_more

An SPF checker reads the v=spf1 TXT record published at your apex domain (or sending subdomain) and reports the authorized senders, the DNS lookup count against the RFC 7208 limit of 10, the final qualifier, and any syntax issues. It tells you what receivers like Gmail, Microsoft, and Yahoo see when they evaluate mail from your domain.

What is the SPF 10 DNS lookup limit? expand_more

RFC 7208 caps the number of DNS lookups an SPF record can trigger at 10. Each include=, a, mx, ptr, exists, and redirect= burns one — and the chain of records they target may burn more. Past 10, receivers return PermError and treat the SPF check as failed. The analyzer above counts the lookups for you.

Can a domain have multiple SPF records? expand_more

No. RFC 7208 says exactly one v=spf1 TXT record may exist per domain. When receivers find two, they return PermError and treat SPF as failed. Merge every authorized sender into a single record.

What does SPF PermError mean? expand_more

PermError is a permanent failure in evaluating the SPF record — either the syntax is broken, the lookup count is over 10, void lookups are over 2, or there are multiple v=spf1 records. Receivers treat PermError the same as a missing SPF record from a DMARC perspective: SPF cannot align.

Is ~all or -all better? expand_more

It depends on the DMARC policy. If you are at p=reject, soft-fail (~all) is the recommended posture — DMARC enforces alignment and SPF stays safe for legitimate forwarded mail (Mailman lists, fwd-as-attachment, etc). If you are not yet at p=reject, hard-fail (-all) de-risks the rollout. Both score equally on the analyzer above when paired with p=reject.

Why does SPF fail after forwarding? expand_more

SPF authenticates the connecting IP, not the message. When mail is forwarded (a corporate distribution list, a fwd-as-attachment to a personal address), the forwarder's IP is what the receiver sees — and that IP is not in your SPF record. DKIM signatures, by contrast, survive forwarding when the body and signed headers are preserved. This is why DMARC alignment usually leans on DKIM rather than SPF in the wild.

Why do MSPs need continuous SPF monitoring? expand_more

SPF records drift. Marketing rotates a sender, IT procures a SaaS tool without checking DNS, the SPF chain quietly creeps past 10 lookups, the vendor at the end of an include= rotates their sending host. A point-in-time check catches the snapshot you take today. Continuous monitoring catches the changes that happen next week before they affect deliverability or DMARC alignment.

Stay Secure. Automate Monitoring.

Manual SPF checks are a thing of the past. DMARC Intelligence monitors your DNS 24/7 and alerts you the moment a change is detected.

Start Free Monitoring Talk to Security Expert