SPF Record Best Practices for Modern Email Security

Introduction

SPF best practices have evolved as the sending landscape has fragmented. A clean SPF record in 2026 looks different from one in 2018 — fewer includes, tighter scope, and more reliance on DKIM for senders that don't fit the IP-allowlist model. This article covers the practices that hold up at scale.

Why this topic matters

Most SPF problems trace back to records that grew organically without governance. Each new SaaS sender adds an include; eventually the record hits the 10-lookup limit and silently breaks. Knowing the practices that prevent this is how you avoid the rebuild later.

The principles

One SPF record per domain. Multiple v=spf1 records cause receivers to fail all of them. Merge when in doubt.

Stay well below 10 lookups. Budget for 7-8 to leave headroom. Each include: and each chained include inside it counts.

Prefer specific over broad. ip4:198.51.100.0/24 is one lookup (actually zero — it's resolved inline); include:largesender.example could be ten.

Use DKIM for SaaS where possible. SaaS senders supporting custom DKIM don't need SPF includes. This is the cleanest way to keep the lookup count down.

End with ~all first, -all after stabilization. Soft fail forgives mistakes during rollout; hard fail is the post-rollout posture.

Step-by-step approach to a clean SPF

1. List every sender. Marketing platforms, transactional, CRM, support, internal mail servers.
2. For each sender, choose SPF or DKIM-only. Custom DKIM available → DKIM-only. No custom DKIM → SPF include.
3. Compose the record. Group includes; lead with the highest-volume.
4. Count lookups. Use a free SPF checker.
5. If over limit, flatten or restructure. SPF flattening is the standard workaround.
6. Publish, validate, monitor via DMARC reports.

Best practices

• Document the record. Each include should have a known business reason.
• Audit quarterly. Senders are added without notice.
• Use subdomain isolation for problem senders. A sender that won't authenticate cleanly can be moved to a subdomain with its own SPF.
• Keep TTL moderate. 3600 seconds during stable state.
• Avoid ptr mechanisms. Deprecated and slow.
• Avoid +all. Catastrophic — accepts all senders.

When to consider SPF flattening

When you're at 9+ DNS lookups and growing, flattening — replacing include: with the resolved IPs directly — buys headroom but introduces ongoing maintenance (IPs change). Use a DMARC platform that maintains the flattened record automatically, or migrate senders to DKIM where possible.

Recommended next step

Pull your current SPF: dig +short TXT yourdomain.com | grep spf. Run it through a checker. Count lookups. If above 8, plan the cleanup; if below, monitor for growth.

FAQ

Can I have SPF on a subdomain only?

Yes — publish SPF at the subdomain's TXT record. Useful when a subdomain has different senders than the parent.

Should I include my email provider's SPF for inbound?

No. SPF is for outbound only. Inbound mail flow isn't authenticated via SPF.

What about mx and a mechanisms?

mx allows mail from the domain's MX hosts; a allows mail from A-record IPs. Useful for simple setups; don't combine with many includes or you'll hit the lookup limit.

Does redirect= count differently from include:?

redirect= replaces the current SPF entirely with the target's; include: adds the target's mechanisms. Use redirect for delegating SPF to a managed provider.

Can SPF be longer than 255 characters?

Yes. The TXT record value can be split into multiple quoted strings within one record. DNS providers usually handle this automatically.

Final thoughts

SPF best practices in 2026 are mostly about restraint. Fewer includes, more DKIM, deliberate hygiene. Get the principles right and the record stays under the lookup limit for years; ignore them and you'll be rebuilding it under deadline pressure.

The cleanest SPF records are the ones nobody had to fight to keep clean. That's the goal.