SPF Records: How to Set One Up Correctly and Avoid the Mistakes That Break Deliverability

SPF — Sender Policy Framework — is one of the first email authentication standards to check when something goes wrong with deliverability. It's also one of the most common sources of configuration errors. A record that looks correct can still quietly fail for a subset of your email, and those failures often go unnoticed until a significant portion of mail starts landing in spam.

This guide covers how SPF works, how to set up your SPF record correctly, and the specific mistakes that most often break it in practice.

What SPF Actually Does

SPF lets you publish a list of IP addresses and mail servers that are authorized to send email from your domain. When a receiving server accepts a message, it checks the sending IP against your published SPF record. If the IP is listed, SPF passes. If it's not, SPF fails — and the message gets a strike against it.

The check happens against the domain in the envelope sender (the "Return-Path" or "Mail From" address), not necessarily the domain in the From header. This distinction matters because services like ESPs and transactional email providers often send using their own Return-Path domain, not yours.

SPF Record Syntax

An SPF record is a TXT record published in DNS at your root domain:

v=spf1 ip4:203.0.113.0/24 include:mailprovider.com ~all

Breaking that down:

• v=spf1 — required prefix identifying this as an SPF record
• ip4:203.0.113.0/24 — authorizes a range of IPv4 addresses
• include:mailprovider.com — includes the SPF record from another domain (your ESP, for example)
• ~all — softfail for anything not matched; use -all for hard fail

The 10-Lookup Limit

This is where most SPF records break. The SPF specification limits DNS lookups to 10 per evaluation. Every include:, a, mx, or redirect mechanism triggers at least one lookup. Nested includes compound quickly.

Exceeding 10 lookups causes a "PermError," which many receiving servers treat as a hard failure. You can exceed the limit without realizing it because the count includes nested lookups from your included domains.

To audit your lookup count, use an SPF checker tool that traces each include recursively. If you're over 10, flatten your record by replacing include: references with the actual IP addresses they resolve to.

The ~all vs -all Decision

~all (softfail) marks unauthorized senders as suspicious but still delivers the message. -all (hardfail) explicitly rejects unauthorized senders. Use ~all while discovering all your sending sources, then move to -all once your DMARC reports confirm every legitimate source is passing SPF.

Common SPF Mistakes

Multiple SPF records

You can only have one SPF record per domain. If your DNS has two TXT records starting with v=spf1, you have a PermError that breaks SPF for your entire domain. Merge them into a single record.

Forgetting sending services

Every service that sends email from your domain — marketing platform, CRM, helpdesk, billing software, transactional email provider — needs to be in your SPF record. The most common oversight: adding a new service and forgetting to update SPF.

Listing your own IP when you send through a relay

If you route outbound mail through an SMTP relay, the relay's IP is what the receiving server sees — not your internal server's IP. Include the relay's IP range or their SPF include mechanism, not your internal network. Using MailDog's SMTP relay typically means adding a single include: line to your record.

Subdomains aren't covered automatically

An SPF record at example.com does not cover mail.example.com or news.example.com. Each subdomain that sends email needs its own SPF record. Subdomains that don't send should publish v=spf1 -all to explicitly block sending.

Testing Your SPF Record

After publishing, test before declaring it done:

1. Use an SPF checker to verify the record parses and stays under 10 lookups
2. Send a test email through each sending source and check the headers for an SPF result
3. Review DMARC aggregate reports after 24–48 hours to confirm all sources pass SPF

In the email headers, a passing record looks like:

Received-SPF: pass (domain of sender@example.com designates
198.51.100.1 as permitted sender)

SPF as One Part of the Authentication Stack

SPF alone isn't enough. It breaks when email is forwarded, and it only covers the envelope sender — not the From header. DKIM signing and DMARC policy work alongside SPF to build a complete authentication posture.

For teams reviewing their full DNS configuration, MailDog's DNS security tools show SPF, DKIM, and DMARC status for your domain. Full configuration reference is in the documentation. Questions about your specific setup can go to the contact page.

Revisit your SPF record whenever you add a new sending service. Getting it right from the start means far fewer deliverability surprises later.