SPF Record Best Practices for 2026

January 27, 20266 min read

SPF (Sender Policy Framework) is one of the oldest email authentication protocols, and it's deceptively simple: you publish a DNS record listing which servers are allowed to send email for your domain. If an email comes from a server not on the list, it fails the SPF check.

Simple in theory. In practice, SPF records are one of the most common sources of email delivery problems. A single mistake can silently break your email for days or weeks before anyone notices.

The 10-lookup limit

This is the single most common SPF problem we see. The SPF specification limits DNS lookups to 10 per evaluation. Every "include", "a", "mx", and "redirect" mechanism counts as a lookup. Nested includes count too. If you include a domain that itself has 3 includes, that's 4 lookups total.

When you exceed 10 lookups, your SPF record doesn't just generate a warning. It fails entirely. The receiving server treats it as a permanent error (permerror), which means your SPF authentication fails for every single email. And because it's a DNS-level issue, most email sending tools won't alert you about it.

Count your lookups carefully. Run "dig TXT yourdomain.com" and follow every include chain. If you're using Google Workspace, Microsoft 365, and a couple of marketing tools, you may already be close to the limit.

One record, not two

Your domain must have exactly one SPF record. If you publish two TXT records that start with "v=spf1", both are invalid. The SPF check returns permerror.

This happens more often than you'd think, especially when different team members add SPF records for different services without checking what's already there. Always modify your existing SPF record rather than adding a new one.

Stop using the PTR mechanism

The PTR mechanism was deprecated years ago because it's slow, unreliable, and causes extra DNS lookups. Some older documentation still references it, but modern email providers may penalize or ignore PTR-based SPF checks.

If your SPF record contains "ptr" or "ptr:domain.com", remove it and replace it with explicit IP ranges or "include" mechanisms.

~all vs -all

Your SPF record should end with either ~all (softfail) or -all (hardfail). The difference:

~all (softfail): emails from unlisted servers are marked as suspicious but typically still delivered. This is the safer choice while you're still identifying all your senders.
-all (hardfail): emails from unlisted servers should be rejected. This is the stronger policy, but only use it when you're confident your SPF record is complete.

Never use +all or ?all. These effectively disable SPF by allowing anyone to send email as your domain.

Keep your record clean

SPF records accumulate cruft over time. You switch marketing platforms, cancel a SaaS tool, or migrate email providers, but nobody removes the old include from the SPF record. Each unused include wastes one of your precious 10 lookups.

Review your SPF record quarterly. For every "include" in your record, ask: do we still use this service to send email? If not, remove it.

IP4 and IP6 ranges

When possible, use "ip4" and "ip6" mechanisms instead of "include" for servers you control directly. IP mechanisms don't count against the 10-lookup limit.

For example, if you run your own mail server at 203.0.113.10, use "ip4:203.0.113.10" instead of setting up a separate SPF-only domain with an include.

Monitor continuously

The biggest SPF risk isn't a bad initial setup. It's drift. Someone adds an include and pushes you over the 10-lookup limit. A service you rely on changes their SPF record, breaking the chain. A team member publishes a second SPF record by mistake.

MailShield monitors your SPF record continuously, counts your lookups, validates the chain, and alerts you the moment something changes. We catch these issues in minutes, not weeks.