Free SPF Record Checker & Syntax Validator

SPF — Sender Policy Framework — is one of the three pillars of modern email authentication, alongside DKIM and DMARC. At its core, an SPF record is a DNS TXT entry that answers a simple question: which mail servers are permitted to send email on behalf of this domain?

When a receiving mail server gets an email claiming to be from you@yourcompany.com, one of the first things it does is look up the DNS records for yourcompany.com and check whether the IP address that actually delivered the message is listed as an authorized sender. If it's not listed, the email fails SPF. What happens next depends on the SPF qualifier and whether a DMARC policy is in place.

Here's what a real-world SPF record looks like:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.10 ~all

Breaking it down piece by piece:

The include: mechanism is the most commonly used — it tells the receiving server to also check the SPF records of a third-party sender like Google, Microsoft, or Mailchimp. Each include: statement triggers an additional DNS lookup. And this is where one of SPF's most notorious constraints comes in: the 10-lookup limit.

RFC 7208 — the specification that defines SPF — limits the total number of DNS lookups during SPF evaluation to 10. This isn't an arbitrary restriction; it was designed to prevent SPF from being weaponized as an amplification vector for DNS-based denial-of-service attacks. But in practice, it creates real headaches for any domain that sends email through multiple platforms.

Think about a typical modern business. You might send through Google Workspace, use Mailchimp for newsletters, SendGrid for transactional emails, HubSpot for marketing automation, and Zendesk for support responses. Each platform needs its own SPF include: entry. Each of those includes may resolve to further nested includes. It adds up quickly, and exceeding 10 lookups causes a PermError — receiving servers will skip SPF authentication entirely, effectively treating all your email as unauthenticated.

Here's what contributes to the lookup count:

• Each include: mechanism counts as one lookup (plus any further lookups within it)
• The a, mx, and exists mechanisms each count as one lookup
• The redirect= modifier counts as one lookup
• The ptr mechanism is deprecated and should never be used
• Literal ip4: and ip6: mechanisms do not consume a lookup

Our SPF checker above counts your domain's actual lookup depth and flags if you're approaching or exceeding the limit. If you are, here are your options:

Option 1: SPF Flattening

Flattening resolves all nested include: mechanisms into their underlying IP addresses and writes them directly into your SPF record as ip4: entries. This eliminates the need for DNS lookups during evaluation. The downside is maintenance: whenever a provider (like Mailchimp or SendGrid) adds or rotates their sending IPs, your flattened record becomes outdated and must be re-flattened. Some services offer automated flattening to handle this continuously.

Option 2: Consolidate senders

Audit which platforms are actually sending mail as your domain. You may be including SPF entries for tools you no longer use. Remove any include: statements for inactive senders — this is the cleanest fix when it applies.

Option 3: Use subdomain routing

If different services use different reply-to addresses, you can split them across subdomains. For example, marketing.yourdomain.com can have its own SPF record specifically for Mailchimp, completely separate from yourdomain.com's record. This keeps each record within the lookup limit.

The most common reason people use an SPF checker is to verify that they've correctly authorized their email service providers. Here's exactly what to include for the platforms your domain is most likely sending through — and where to add these records in popular DNS providers.

Google Workspace / Gmail

Add include:_spf.google.com to your SPF record. Your complete record might look like: v=spf1 include:_spf.google.com ~all

Microsoft 365 / Outlook

Add include:spf.protection.outlook.com. Note: if you're migrating from on-premises Exchange, your old IP addresses may still be in your SPF record — remove them once migration is complete.

Mailchimp

Add include:servers.mcsv.net. Mailchimp also recommends setting up DKIM authentication through their domain verification workflow, which provides better alignment for DMARC purposes.

SendGrid

SendGrid's domain authentication uses CNAME records for DKIM rather than a traditional SPF include:. If you set up SendGrid's domain authentication, their CNAME-based setup handles both DKIM and SPF alignment automatically.

Amazon SES

Add include:amazonses.com if using custom MAIL FROM, or let SES use its own domain. Amazon's DKIM signing through SES is highly recommended alongside SPF.

Zoho Mail

Add include:zoho.com. Zoho also has region-specific SPF records (e.g., include:zoho.eu for EU data centers) — check your Zoho dashboard for the correct one for your account.

Where to add the record in your DNS provider

After adding your record, wait for DNS propagation (usually 5–30 minutes on Cloudflare, up to 48 hours on some registrars) and then re-run our SPF checker to confirm the record is live and valid.

A surprising number of email delivery problems trace back to a broken or misconfigured SPF record. These are the mistakes our SPF checker most frequently catches, and what to do about each one.

Having two SPF records

This is the number-one mistake. You must have exactly one TXT record beginning with v=spf1 on your domain. If you have two, receiving servers return a PermError and may reject or ignore SPF entirely. This often happens when someone adds a new provider's SPF record instead of updating the existing one. Always edit your existing SPF record to add new includes — never create a second one.

Using +all (PassAll) — a critical security error

The qualifier +all means "authorize every mail server on the internet to send email as my domain." It completely negates the purpose of SPF. If you see +all in your record, change it to -all or at minimum ~all immediately. This is an open invitation for anyone to spoof your domain.

Forgetting to include all sending services

If your CRM, helpdesk software, or invoicing platform sends emails as your domain, it must be in your SPF record. Forgotten third-party senders are a common cause of legitimate emails going to spam. When you add a new tool to your stack, ask immediately: "Does this send email as our domain? Does it need SPF?" and update accordingly.

Old IP addresses still in the record

After migrating from an old email hosting provider, IT teams often forget to remove the old provider's SPF includes. This wastes lookup budget and can cause confusion. After any email infrastructure migration, audit your SPF record within 30 days to remove outdated entries.

SPF working but DMARC still failing

SPF passing is not the same as DMARC passing. DMARC requires alignment — the domain authenticated by SPF (the MAIL FROM / envelope sender) must match the domain in the visible From header. If your email service provider sends from their own return-path domain, SPF may pass their domain but still fail alignment for your domain. The solution is DKIM signing with your domain, which aligns more reliably for third-party senders.