SPF Records: How to Set Up Sender Policy Framework Without Breaking Your Email

What SPF Does and Why It Matters

SPF — Sender Policy Framework — is a DNS record that lists the mail servers and IP addresses authorized to send email on behalf of your domain. When a receiving server gets a message claiming to be from yourdomain.com, it checks your SPF record to see if the sending IP is on the approved list. If it is, SPF passes. If it isn't, the message fails SPF and gets treated with suspicion.

Without an SPF record, receiving servers have no way to verify that your domain authorized the sender. Spammers can freely forge your domain as the envelope sender — the address visible during SMTP delivery — and your legitimate mail gets no authentication credit. Both problems hurt deliverability. SPF is also the foundation DMARC builds on: you need a valid SPF record before DMARC enforcement has any practical effect for your domain.

Anatomy of an SPF Record

SPF is published as a TXT record at your domain root. A typical record looks like this:

v=spf1 ip4:203.0.113.0/24 include:smtp.maildog.io include:_spf.google.com ~all

Breaking this down:

• v=spf1 — Required prefix that identifies this as an SPF record.
• ip4:203.0.113.0/24 — Authorizes the IP range 203.0.113.0–203.0.113.255.
• include:smtp.maildog.io — Includes the IPs authorized in MailDog's SPF record.
• include:_spf.google.com — Includes Google Workspace's authorized sending IPs.
• ~all — The "softfail" qualifier: mail from unlisted sources is flagged but not rejected outright.

Choosing the Right "all" Qualifier

The all mechanism at the end of your record is the catch-all for any source not explicitly listed. There are four options:

• +all — Authorize everything. Never use this — it defeats the entire purpose of SPF.
• ?all — Neutral. Provides no real signal either way. Avoid this too.
• ~all — Softfail. Messages from unlisted sources are accepted but flagged. Good for initial deployment.
• -all — Hardfail. Messages from unlisted sources should be rejected. The right long-term choice once you've confirmed all legitimate sources are listed.

Start with ~all when first deploying SPF. Monitor your DMARC reports for a couple of weeks to confirm every legitimate source is covered, then switch to -all for proper enforcement.

The 10-Lookup Limit: SPF's Most Annoying Constraint

SPF has a hard limit of 10 DNS lookups per evaluation. Every include:, a:, and mx: mechanism triggers a lookup, and each of those can trigger further lookups recursively. Exceed 10 and the result is a permerror — SPF permanently fails for every message, as if you had no record at all.

This surprises a lot of organizations. You add a CRM, then a marketing platform, then a ticketing system, and suddenly you're over the limit without realizing it. Strategies to stay under 10:

• Replace include: mechanisms with flat ip4: or ip6: ranges where possible. IP addresses don't trigger additional lookups.
• Use an SPF flattening tool to resolve all include chains into a single set of IPs in one record.
• Audit regularly — as vendors update their own SPF records, the sub-lookup count can change without any action on your part.

SPF and Forwarding: A Known Limitation

SPF checks the envelope sender's domain — the address used during SMTP delivery, not the visible From: header address. When someone forwards your email to another address, the forwarding server relays the message from its own IP, which isn't in your SPF record. The message fails SPF at the final destination.

This is expected behavior, not a misconfiguration. The solution is DKIM, which survives forwarding as long as the message body and signed headers aren't modified. When SPF and DKIM are both in place, a forwarded message that fails SPF can still pass DMARC via DKIM alignment. This is exactly why both are always recommended together rather than either alone. The email forwarding best practices guide covers what to expect and how DKIM changes the picture.

Multiple SPF Records: Don't Do It

A domain can only have one SPF record. If you have more than one TXT record starting with v=spf1, the result is a permanent error and SPF fails for all messages. This is a common problem on domains where different people or tools have added SPF records independently. If you've inherited a domain with multiple SPF records, merging them into one is the first thing to fix.

Testing Your SPF Record

After publishing, verify it before relying on it for real mail:

• Query the record: dig TXT yourdomain.com | grep spf
• Use MXToolbox's SPF checker to validate syntax and count your DNS lookups.
• Send a test message to a Gmail address and open the original headers — look for Received-SPF: pass.
• If DMARC monitoring is already active, your aggregate reports will show SPF pass and fail rates per sending source within 24 hours.

Putting SPF in Context

SPF is the starting point for email authentication — but it's not the complete solution on its own. Pair it with DKIM to cover forwarded mail and add cryptographic message integrity, then add DMARC to gain policy control and reporting visibility. If you're using MailDog as your SMTP relay, the documentation includes the exact SPF include mechanism to add to your record alongside any other authorized senders.

For a broader view of how authentication fits into your deliverability picture, the email deliverability audit checklist covers SPF, DKIM, and DMARC alongside the sending reputation factors that sit on top of them. The DNS security page explains how MailDog approaches authentication record management as part of your overall email setup.