SPF Record Validator

SPF Record Validator: Check Your Sender Policy Framework Configuration

SPF (Sender Policy Framework) is an email authentication standard that allows domain owners to specify which mail servers are authorized to send email on their behalf. An SPF TXT record in your DNS tells receiving servers: "Only accept mail claiming to be from my domain if it comes from these IPs or servers." This validator checks your SPF record for syntax errors, DNS lookup count violations, and mechanism correctness — the most common causes of SPF failures that silently hurt deliverability.

SPF Record Syntax: How It Works

An SPF record is a TXT record at your domain root (e.g. yourdomain.com) that starts with v=spf1 and contains a space-separated list of mechanisms followed by an "all" qualifier. A typical record looks like:

Each mechanism is evaluated left-to-right. include: delegates to another domain's SPF record. ip4: and ip6: authorize specific IP addresses or ranges. a authorizes the domain's A record. mx authorizes the domain's MX servers. The final ~all or -all handles mail from unauthorized sources.

The 10 DNS Lookup Limit: SPF's Most Common Failure

RFC 7208 limits SPF evaluation to 10 DNS lookups. Each include:, a, mx, and ptr mechanism triggers a DNS query. Nested includes count too — if you include Google (1 lookup) and Google's SPF includes two more domains (2 more lookups), that's 3 lookups just for Google Workspace. A typical sender using Google + Outlook + Salesforce + Klaviyo + SendGrid can easily exceed 10 lookups.

When SPF evaluation exceeds 10 lookups, receiving servers return permerror. Under DMARC, permerror is treated as SPF failure — meaning mail from legitimate servers can be quarantined or rejected. The fix: use our SPF Record Builder to stay within the limit, or use SPF flattening to replace includes with explicit IP ranges.

~all vs -all vs ?all: Choosing the Right Qualifier

• -all (hardfail) — Unauthorized mail should be rejected. Maximum enforcement, but risky if your SPF record is incomplete. Any legitimate sending source not in your SPF will be rejected.
• ~all (softfail) — Unauthorized mail should be accepted but marked as suspicious. This is the recommended starting point — less risk of accidentally rejecting legitimate mail.
• ?all (neutral) — No policy on unauthorized senders. Effectively says "I can't vouch for who sends from my domain." Provides no spam protection benefit. Avoid unless you're in a transition period.
• +all — Authorizes all IPs. This is the same as having no SPF at all, and opens your domain to spoofing. Never use +all.

SPF, DKIM, and DMARC: Why All Three Matter

SPF alone is not enough. SPF checks the envelope sender (the Return-Path or MAIL FROM address in the SMTP envelope) — not the From address visible to recipients. This means a spammer can pass SPF for a legitimate-looking From address while setting a different Return-Path. DMARC closes this gap by requiring either SPF or DKIM to align with the From domain. Without DMARC, a passing SPF result provides minimal anti-spoofing protection from a user-visible perspective.