Back to Deliverability Checker
Fix Guide

How to Fix SPF Records

SPF (Sender Policy Framework) specifies which mail servers are authorized to send email on behalf of your domain. A properly configured SPF record is essential for email deliverability and preventing spoofing.

No SPF Record Found

If your domain has no SPF record, receiving mail servers cannot verify that emails claiming to be from your domain are actually authorized. This makes your domain vulnerable to spoofing and can hurt deliverability.

How to add an SPF record

Add a TXT record to your domain's DNS with your SPF policy. The exact steps depend on your DNS provider:

Cloudflare

  1. Go to DNS → Records
  2. Click "Add record"
  3. Type: TXT, Name: @, Content: your SPF record

Google Domains / Squarespace

  1. Go to DNS → Custom records
  2. Add a TXT record with host "@"
  3. Paste your SPF record as the value

AWS Route 53

  1. Go to Hosted zones → your domain
  2. Create record → Simple routing
  3. Record type: TXT, Value: your SPF record

Example SPF records

If you use Google Workspace:

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

If you use Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

If you use multiple email services (e.g., Google + Mailchimp):

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
Tip: Ask your email service provider for the correct include: value to use.

Multiple SPF Records

This breaks SPF entirely. According to RFC 7208, having multiple SPF records causes SPF to return a permanent error (PermError), meaning all SPF checks will fail.

You can only have one SPF record per domain. If you need to authorize multiple email services, combine them into a single record using multiple include: statements.

How to fix

  1. Identify all your SPF records in DNS
  2. Combine the mechanisms from each into a single record
  3. Delete all but one TXT record starting with v=spf1

Before (broken):

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

After (fixed):

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

Critical: +all Vulnerability

CRITICAL SECURITY ISSUE: Using +all allows anyone on the internet to send email as your domain. This is a severe security vulnerability that must be fixed immediately.

The +all mechanism tells receiving servers to accept email from any IP address as legitimate mail from your domain. This completely defeats the purpose of SPF.

How to fix

Replace +all with ~all (soft fail) or -all (hard fail):

Before (dangerous):

v=spf1 include:_spf.google.com +all

After (secure):

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

Understanding SPF qualifiers

  • -all — Hard fail: Reject unauthorized senders (most strict)
  • ~all — Soft fail: Mark as suspicious but accept (recommended)
  • ?all — Neutral: No policy (not recommended)
  • +all — Pass: Accept everyone (never use this)

Missing ~all or -all Termination

Every SPF record should end with an "all" mechanism that specifies what to do with senders not explicitly listed. Without this, the behavior is undefined and may vary between mail servers.

How to fix

Add ~all or -all to the end of your SPF record:

Before (incomplete):

v=spf1 include:_spf.google.com

After (complete):

v=spf1 include:_spf.google.com ~all
Recommendation: Start with ~all (soft fail) while testing. Once you've confirmed all legitimate mail is passing, consider switching to -all (hard fail) for stricter protection.

Too Many DNS Lookups

SPF has a limit of 10 DNS lookups per check. Mechanisms like include:, a, mx, ptr, and exists each count as a lookup. Exceeding this limit causes SPF to fail with a PermError.

Note: ip4: and ip6: do NOT count toward the lookup limit since they don't require DNS queries.

How to fix

  1. Flatten your SPF record: Replace include: statements with the actual IP addresses they resolve to. Use tools like SPF Lookup to see what IPs an include resolves to.
  2. Remove unnecessary mechanisms: Audit which services actually send email for you and remove any that are no longer used.
  3. Use an SPF flattening service: Services like AutoSPF or SPF Proxy automatically flatten and maintain your SPF record.

Example of flattening:

Before (with many lookups):

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

After (flattened with IPs):

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 include:sendgrid.net ~all
Warning: Flattened records need maintenance. If Google changes their IP ranges, your flattened record becomes outdated. Consider using an automated flattening service for large SPF records.

Null SPF Record

A null SPF record (v=spf1 -all) explicitly states that no servers are authorized to send email from your domain. This is intentional when a domain should never send email.

When this is correct

A null SPF is appropriate for:

  • Parked domains that don't send email
  • Redirect-only domains
  • Domains used only for websites (not email)

When this needs fixing

If your domain does send email (transactional emails, newsletters, etc.), a null SPF will cause all your emails to fail authentication.

Add your email service providers to the SPF record:

Before (null record):

v=spf1 -all

After (with authorized senders):

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

Related Guides

Fix DMARC Records

Configure DMARC policies for protection

Set Up DKIM

Add digital signatures to your emails

Verify your changes

After making changes, use our checker to confirm everything is configured correctly.

Check Your Domain