S
SPF Record Check

How to Audit Your SPF Record for Security Gaps

Learn how to analyse your SPF record for security gaps, unused includes, and misconfigurations. A step-by-step SPF audit checklist for better email security.

Last updated: 2026-05-09

Publishing an SPF record is a good first step. But SPF records are not something you set up once and forget about forever. Over time, your email setup changes. You add new services, cancel old ones, switch providers, or restructure your infrastructure. Each change can leave your SPF record out of date, overly permissive, or dangerously close to breaking.

An SPF audit checks whether your record is still accurate, secure, and efficient. This guide gives you a step-by-step checklist you can follow to analyse your SPF record and catch problems before they affect your email delivery. For a comprehensive overview of SPF, see our complete SPF guide.

Start With Your Current Record

Before you can audit your SPF record, you need to see exactly what is published in DNS right now. Enter your domain in the checker below to get a complete view of your current SPF configuration.

The SPF Audit Checklist

Work through each of these checks in order. If you find an issue at any step, make a note and continue through the rest of the checklist before making changes. This way you can fix everything in a single update rather than making multiple DNS changes.

Check you have exactly one SPF record

Your domain should have exactly one TXT record starting with v=spf1. Zero means no SPF protection at all. Two or more causes a PermError, which means every SPF check fails. This is the single most common SPF misconfiguration, and the free checker above will flag it immediately.

Verify all includes are still in use

List every include: mechanism in your SPF record. For each one, ask: do we still use this email service? If you cancelled Mailchimp six months ago but their include is still in your record, remove it. Every unnecessary include wastes a DNS lookup (and could become a void lookup if the domain stops resolving) and widens your attack surface by authorizing servers you no longer control.

Count your DNS lookups

SPF has a hard limit of 10 DNS lookups per evaluation. Each include, a, mx, and redirect mechanism counts toward this limit, and nested includes count too. If your total is at or near 10, you are at risk of hitting the limit and causing a PermError. Read our guide on the SPF 10 DNS lookup limit for details on counting and reducing lookups.

Check for overly permissive mechanisms

Look for +all in your record. This tells the world that any server is authorized to send email as your domain, which completely defeats the purpose of SPF. This is rare but extremely dangerous. Even ?all (neutral) provides no real protection. Your record should end with ~all (softfail) or -all (hardfail). See our SPF softfail vs hardfail guide for help choosing.

Verify the all qualifier is appropriate

If you are still using ~all (softfail) and your SPF record has been stable for a while, consider moving to -all (hardfail) for stronger protection. If you have a DMARC policy set to reject, pairing it with -all gives you the strongest spoofing protection. Check your DMARC record with DMARC Record Checker.

Look for deprecated mechanisms

The ptr mechanism was deprecated in RFC 7208 because it is slow, unreliable, and puts unnecessary load on DNS. If your record contains ptr or ptr:, replace it with ip4: or include: mechanisms that achieve the same result. Modern email servers may ignore ptr entirely.

Check for unused IP ranges

If your SPF record contains ip4: or ip6: mechanisms, verify that those IP addresses or ranges still belong to servers that send email for your domain. Servers get decommissioned, cloud instances get reassigned, and IP addresses change hands. An old IP range in your SPF record could be authorizing someone else's server today.

Verify subdomain coverage

SPF records only apply to the exact domain they are published on — subdomains do not inherit SPF records from the parent domain. If you send email from subdomains like mail.yourdomain.com or newsletters.yourdomain.com, each subdomain needs its own SPF record. Domains you do not send email from should have v=spf1 -all to prevent spoofing.

Common Issues Found During Audits

Leftover includes from old providers

This is the most common finding. You switched from one email marketing platform to another but never removed the old include. The risk is that the old provider's infrastructure can still pass SPF checks for your domain.

Records approaching the lookup limit

Many businesses start with Google Workspace (1 lookup), add a CRM like HubSpot (1 lookup), then a support tool like Zendesk (1 lookup), then a marketing platform (1 lookup), and suddenly they are at 8 or 9 lookups before counting nested includes. One more service addition pushes them over.

If you need to consolidate your SPF record to stay under the limit, SPF Creator can help you build an optimized record.

No subdomain protection

Attackers often spoof subdomains rather than root domains because many organizations forget to protect them. Even if you do not send email from billing.yourdomain.com, a spoofer can if there is no SPF record there.

When to Audit Your SPF Record

You do not need to audit your SPF record every day, but certain events should trigger a review:

  • After adding or removing an email service. Any time you start or stop using a service that sends email on your behalf.
  • After an email deliverability incident. If emails suddenly start going to spam, your SPF record is one of the first things to check.
  • Quarterly as a routine check. A quick review every three months catches configuration drift before it causes problems.
  • After changing DNS providers or hosting. Moving your domain to a new registrar or DNS host can sometimes reset or alter DNS records.
  • After a security incident. If your domain was compromised or you suspect spoofing, verify your SPF record has not been tampered with.

Beyond SPF: The Full Picture

SPF is one layer of email authentication. A complete audit should also cover:

  • DKIM verifies that email content has not been modified in transit. Test your DKIM records with DKIM Test.
  • DMARC tells receiving servers what to do when SPF or DKIM fails and gives you reporting on authentication results. Check yours with DMARC Record Checker.

For a comprehensive view of your entire email authentication setup, Deliverability Checker evaluates SPF, DKIM, DMARC, and MX records together and monitors them over time.

References

Never miss an SPF issue

Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.

Start Monitoring

Related Articles