Free SPF Record Checker

What is SPF and Why It Matters in 2026

Sender Policy Framework (SPF) is one of the three pillars of modern email authentication, alongside DKIM and DMARC. Defined in RFC 7208, it lets a domain owner publish a list of authorized sending servers in DNS so receiving mail providers can verify that incoming messages actually come from where they claim. Without SPF, anyone can send email pretending to be your domain — and modern providers like Gmail and Yahoo will quietly drop unauthenticated mail straight into spam.

In 2026, SPF is no longer optional. Gmail and Yahoo's bulk sender requirements (rolled out in 2024 and tightened since) mandate SPF and DKIM for any domain sending more than 5,000 messages per day. Microsoft 365 and Apple Mail enforce similar standards. A misconfigured or missing SPF record now translates directly into spam folder placement, lost revenue, and brand damage. The good news: SPF is one of the cheapest, fastest deliverability wins available — a single TXT record correctly configured can lift inbox placement by 20–40% overnight.

Anatomy of an SPF Record

Every SPF record is a single DNS TXT record containing space-separated mechanisms. Here's a typical example for a domain using Google Workspace and Mailgun:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all

• v=spf1 — the version tag. Every SPF record must start with this. There is no v=spf2; the protocol has not changed in over a decade.
• ip4: / ip6: — explicit allowed IP addresses or CIDR ranges. ip4:203.0.113.0/24 authorizes an entire subnet. These are the cheapest mechanisms because they trigger zero DNS lookups.
• include: — pulls in another domain's SPF record. include:_spf.google.com tells receivers to also accept mail from any server Google authorizes for its tenants. Each include counts as one DNS lookup, and any nested includes count too.
• a / mx — authorize the IP addresses of the domain's A record (the website's server) or MX records (the inbound mail servers). Use sparingly: many domains have web servers that should not be sending mail.
• Qualifiers control the result. ~all (soft fail) marks unmatched mail as suspicious but accepts it — useful while testing. -all (hard fail) rejects unmatched mail outright — the recommended production setting. ?all (neutral) does nothing and is useless. +all explicitly authorizes every IP on the internet — never use this; it is the equivalent of leaving your front door open with a sign that says "please impersonate me."

5 Common SPF Errors and How to Fix Them

Too many DNS lookups (RFC 7208 limit: 10)

SPF allows a maximum of 10 DNS lookups per evaluation. Each include:, a:, mx:, exists:, and redirect= counts. Nested includes count too — if include:_spf.google.com itself contains four includes, that's five lookups for that one mechanism. Exceeding the limit triggers a PermError and most receivers treat it as a hard fail. Fix: audit every include with our SPF checker above, remove unused vendors, replace include: with ip4: blocks where the vendor publishes static ranges, or use a flattening service.

PermError: SPF record syntax invalid

Common syntax mistakes include missing the v=spf1 prefix, using semicolons instead of spaces, leaving stray characters from copy-paste, or putting the qualifier (~all) in the middle of the record instead of at the end. Receivers see this as a configuration failure and fail SPF outright. Fix: paste the exact record into a validator, look for hidden Unicode characters, and ensure mechanisms are space-separated with the all qualifier last.

Multiple SPF records (must merge)

RFC 7208 explicitly forbids more than one v=spf1 TXT record on the same domain. This usually happens when one team adds Google Workspace and another adds SendGrid without coordinating. Receivers seeing two records throw a PermError. Fix: combine into a single record. v=spf1 include:_spf.google.com include:sendgrid.net ~all replaces both individual records.

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Forwarding breaks SPF

When a recipient forwards your message to another address, the connecting IP changes but the Return-Path stays yours — and SPF fails at the forwarding hop. This is by design but causes false negatives. Fix: rely on DKIM for alignment (DKIM survives forwarding), implement SRS on outbound forwarders you control, and accept that SPF alone is not sufficient — which is exactly why DMARC requires SPF or DKIM, not both.

Subdomain inheritance confusion

SPF is not inherited. mail.example.com and example.com are separate hosts and need separate SPF records. A common bug: company publishes SPF on the apex but a marketing tool sends from updates.example.com — receivers see no SPF record on the subdomain and your mail fails alignment. Fix: publish v=spf1 -all on every subdomain that should never send mail, and a real policy on every subdomain that does.

Step-by-Step SPF Setup

1. Inventory all sending services

List every system that sends mail using your domain: marketing platforms (Mailchimp, HubSpot), transactional providers (SendGrid, Postmark, Resend), CRMs, support desks (Zendesk, Intercom), payroll, payment processors, and your own application servers. Missing even one means legitimate mail will be rejected after you publish your record.

2. Choose a fail policy (~all vs -all)

Start with ~all (soft fail) for the first 1–2 weeks while you monitor DMARC reports for unexpected sources. Once you've confirmed every legitimate sender is in the record and DMARC reports show 100% pass rates, switch to -all for maximum protection.

3. Construct the record

Use vendor-published include: mechanisms wherever possible (e.g., include:_spf.google.com). For services without an include, use ip4: with their published IP ranges. Keep the record under the 10-lookup limit by counting every include and its nested lookups. End with a single qualifier — ~all or -all — never both.

4. Add the TXT record to DNS

In your DNS provider's control panel, create a new TXT record with host = @ (or your domain's apex) and value = the full SPF string in quotes. TTL of 3600 (1 hour) is a good default. If your DNS provider auto-quotes, do not double-quote.

5. Validate and monitor

Use the checker above to verify the record parses cleanly, lookup count is under 10, and policy is correctly set. Then send test emails to mail-tester.com and to your own Gmail/Outlook accounts. Set up DMARC with rua= reports to catch any sources you missed. Monitor continuously — vendor IPs change, includes get added, and an SPF record that was clean six months ago can quietly break.

How to Stay Under the 10 DNS Lookup Limit

The 10-lookup limit is the single most common cause of SPF failures at scale. Each include: triggers a DNS query, and any include that itself contains includes triggers more — Salesforce's SPF, for example, can resolve to 8+ lookups on its own. Three strategies keep you under the limit. First, audit ruthlessly: any vendor you no longer use must come out of the record. Run our checker monthly and remove dead includes.

Second, replace include: with ip4: where vendors publish stable IP ranges. SendGrid, Mailgun, and Amazon SES all publish static blocks; using ip4:198.61.254.0/24 instead of include:sendgrid.net costs zero lookups instead of two. The tradeoff is maintenance — when the vendor adds new IPs you must update manually.

Third, use SPF flattening services (e.g., easydmarc.com, dmarcian) for unavoidable nested includes. These services resolve all your includes into a flat list of ip4: blocks and republish them as a single hosted SPF record you reference with one include. The downside is operational dependency on a third party — vet them carefully and monitor for outages.

SPF, DKIM, and DMARC: How They Work Together

SPF alone is not enough. The three protocols form a layered defense: SPF authenticates the sending server's IP, DKIM cryptographically signs the message contents, and DMARC ties the two to the visible From address and tells receivers what to do when authentication fails. SPF breaks under forwarding; DKIM survives forwarding but is harder to deploy because it requires generating a key pair and adding the public key to DNS. Together, DMARC alignment passes if either SPF or DKIM passes — so deploying both gives you redundancy and full coverage in real-world delivery scenarios where forwarding, mailing lists, and ARC trust chains are common. Without DMARC, SPF and DKIM are diagnostic tools only; receivers may use the results loosely or ignore them. With DMARC at p=reject, you publicly commit to your authentication policy and instruct every receiver on the planet to drop spoofed mail outright. This is the modern email security standard, and it starts with a clean SPF record. The recommended deployment order is: SPF first (one TXT record, immediate impact), then DKIM (key generation plus DNS), then DMARC at p=none with rua= reports for two weeks of monitoring, then progressively tighten to p=quarantine and finally p=reject. Skipping monitoring is the most common cause of legitimate mail being dropped during DMARC rollout.

Gmail and Yahoo 2026 Requirements

Since February 2024, Gmail and Yahoo require all bulk senders (5,000+ messages per day to their users) to publish SPF, DKIM, and DMARC, maintain a one-click unsubscribe header (List-Unsubscribe with Post URL), and keep spam complaint rates below 0.3% as measured in Postmaster Tools. Microsoft 365 enforces similar rules through SmartScreen, and Apple Mail follows DMARC strictly across iCloud and managed Apple IDs. In 2026, these standards have tightened further: DMARC must be at p=quarantine or stricter for unauthenticated bulk traffic, ARC trust has been added to the evaluation chain for forwarded mail, and complaint rates above 0.1% trigger reduced delivery even before the 0.3% hard cap. Failure is not a soft warning — your mail goes to spam or is rejected outright at the SMTP layer. Even non-bulk senders are increasingly affected because filters generalize: a B2B sender with 200 emails per day still benefits from clean SPF, DKIM, and DMARC because Gmail's machine-learning classifiers reuse the same authentication signals to score every message. The bottom line: SPF is no longer a best-practice — it is a deliverability prerequisite. Run the checker above today to confirm your SPF passes, then move on to DKIM and DMARC to complete the stack.

Related Guides

• DMARC Policy Setup Guide — How SPF fits into the full email authentication stack