SPF Record Best Practices

Setting up an SPF record is straightforward. Keeping it correct over time is where most domains fail. Services get added and never removed. Lookup limits get exceeded silently. Policies stay too permissive years after they should have been tightened.

This guide covers the practices that keep your SPF record effective -- from the day you create it through every quarterly audit after that.

1. Start With Softfail, Migrate to Hardfail

When you first create your SPF record, use ~all (softfail) instead of -all (hardfail). Softfail tells receiving servers that unauthorized IPs are "probably not legitimate" but doesn't instruct them to reject the message outright.

# Starting out — softfail while you verify everything works
v=spf1 include:_spf.google.com include:sendgrid.net ~all

This gives you a safety net. If you missed a legitimate sending source, those emails will still be delivered (though potentially flagged) rather than rejected.

Once you've confirmed that all legitimate sources pass SPF -- typically after 2-4 weeks of monitoring DMARC aggregate reports -- switch to -all:

# After confirming all senders pass — hardfail for maximum protection
v=spf1 include:_spf.google.com include:sendgrid.net -all

2. Audit All Sending Sources First

Before writing a single line of your SPF record, make a complete inventory of everything that sends email as your domain. This is the step people skip, and it's why they end up with incomplete records.

Check every category:

Talk to every department. Marketing knows about Mailchimp. Finance knows about QuickBooks. Support knows about Zendesk. IT usually doesn't know about all of them unless they ask.

3. Only One SPF Record Per Domain

This is the most common SPF mistake. You can only have one TXT record starting with v=spf1 per domain. If you have two, both fail -- SPF returns permerror and every email from your domain fails authentication.

# WRONG — two separate SPF records
v=spf1 include:_spf.google.com -all
v=spf1 include:sendgrid.net -all

# CORRECT — one record with both includes
v=spf1 include:_spf.google.com include:sendgrid.net -all

This usually happens when a new service's setup guide says "add an SPF record" and someone creates a new one instead of updating the existing one. Always check your DNS for an existing SPF record before adding a new service.

Use SPF Record Check to verify you have exactly one SPF record.

4. Stay Under 10 DNS Lookups

The SPF specification limits evaluation to 10 DNS lookups. Every include, a, mx, exists, and redirect mechanism counts. Exceed the limit and SPF returns permerror -- completely broken.

What Counts and What Doesn't

The key insight: ip4 and ip6 are free. If you have a service with dedicated, stable IPs, using ip4 instead of include saves you a lookup (or more).

5. Remove Unused Includes

This is the maintenance practice most domains neglect. You added include:old-crm-vendor.com two years ago. You switched CRMs a year ago. The old include is still in your SPF record, burning a DNS lookup for a service you no longer use.

Make it a habit: when you decommission an email-sending service, remove its include from your SPF record at the same time. Don't leave it for later. Later never comes.

6. Use ip4 for Dedicated IPs

If a service gives you dedicated sending IPs (common with higher-tier plans on SendGrid, Postmark, Amazon SES, etc.), use ip4 mechanisms instead of include:

# Before: uses 1+ lookups
include:sendgrid.net

# After: uses 0 lookups
ip4:167.89.123.45 ip4:167.89.123.46

The trade-off: if the service changes your IPs, you need to update your SPF record manually. This works best for services where you control or are notified of IP changes.

For services on shared IP pools (where IPs change frequently), keep the include. The automatic updates are worth the lookup cost.

7. Set an Appropriate TTL

Your SPF record's DNS TTL (Time to Live) controls how long resolvers cache it. The recommended value is 3600 seconds (1 hour).

• Too low (60-300s): Increases DNS query volume. The receiving server queries your DNS on nearly every email, adding latency. Not useful unless you're actively making changes.
• Too high (86400s+): Changes take a full day or more to propagate. If you need to add a sending source urgently, you're stuck waiting.
• Just right (3600s): Changes propagate within an hour. DNS caching stays effective. This is the standard recommendation.

When you're actively making changes to your SPF record, temporarily lower the TTL to 300 seconds (5 minutes). Once the changes are confirmed working, set it back to 3600.

8. Don't Use the ptr Mechanism

The ptr mechanism does a reverse DNS lookup on the connecting IP and checks if the resulting hostname matches the authorized domain. It's deprecated in RFC 7208 for good reasons:

• Slow: Requires a reverse DNS lookup followed by a forward lookup to verify, adding significant latency
• Unreliable: Many IPs don't have proper reverse DNS configured
• Resource-intensive: Puts unnecessary load on receiving servers

# DON'T use this
v=spf1 ptr:example.com -all

# DO use explicit mechanisms instead
v=spf1 ip4:203.0.113.0/24 -all

If you see ptr in your SPF record, replace it with ip4 or ip6 mechanisms for the same IP ranges.

9. Never Use +all

Using +all (or bare all without a qualifier) tells the world that every IP address is authorized to send email as your domain. This is worse than having no SPF record.

# EXTREMELY DANGEROUS — authorizes the entire internet
v=spf1 +all

# ALSO DANGEROUS — + is the default qualifier
v=spf1 include:_spf.google.com all

There is no legitimate use case for +all. If you find it in your record, change it to -all or ~all immediately.

10. Audit Your SPF Record Quarterly

SPF records decay. Services change their IP infrastructure. Teams add tools without updating DNS. Former employees' test environments keep sending email. A record that was perfect six months ago may have problems today.

Set a quarterly reminder to:

Good vs. Bad Practices at a Glance

11. Complete the Trio: SPF + DKIM + DMARC

SPF alone doesn't fully protect your domain. It checks the envelope sender (the Return-Path), but it doesn't protect the From header that recipients actually see. And without DMARC, there's no policy telling receiving servers what to do when SPF fails.

The three protocols are designed to work together:

• SPF authorizes which servers can send email for your domain
• DKIM adds a cryptographic signature proving the message wasn't altered in transit
• DMARC ties SPF and DKIM together, aligns them with the From header, and sets a policy for failures

Setting up SPF without DKIM and DMARC is like locking your front door but leaving the windows open. Each protocol covers gaps the others can't.

12. Use Monitoring to Catch Issues Early

SPF problems are invisible until your email starts bouncing or landing in spam. By then, the damage is done -- missed customer emails, failed password resets, lost sales.

Proactive monitoring catches issues before they affect deliverability:

• Lookup count creep -- A provider adds a nested include, pushing you from 9 to 11 lookups
• Record changes -- Someone on your team modifies the SPF record without telling you
• Provider IP changes -- If you use ip4 mechanisms and the service rotates IPs, your record goes stale
• Duplicate records -- A new team member creates a second SPF record during setup

Don't wait for deliverability problems to tell you something's wrong. Check your records regularly with SPF Record Check and set up continuous monitoring.

Monitor Your New SPF Record

You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.