SPF Records Explained: Set Up Sender Policy Framework the Right Way

SPF — Sender Policy Framework — is one of the three core email authentication standards alongside DKIM and DMARC. It lets you publish a list of servers that are 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 that approved list. If it isn't, the message fails SPF, which damages your sender reputation and can lead to delivery failures.

SPF has been around long enough that most experienced email operators treat it as table stakes. But it's also one of the most commonly misconfigured DNS records — either because the record is missing entirely, because it hasn't been updated when infrastructure changes, or because it hits the lookup limit and silently stops working.

How SPF Works

The SPF check happens at the SMTP level, before the message body is ever evaluated. Here's the sequence:

1. Your server connects to the receiving mail server and announces a sender domain in the SMTP envelope (the MAIL FROM field).
2. The receiving server looks up the TXT record on your domain: example.com TXT "v=spf1 ..."
3. It checks whether the connecting IP address is authorized by that record.
4. Depending on the result — pass, fail, softfail, or neutral — it applies the corresponding policy.

Note that SPF checks the envelope sender, not the From: header that recipients see. This is an important distinction that trips people up, especially when dealing with email forwarding. More on that below.

Reading an SPF Record

A typical SPF record looks like this:

v=spf1 include:maildog.io ip4:203.0.113.10 -all

Breaking it down:

• v=spf1 — declares this is an SPF record (version 1, the only version in use)
• include:maildog.io — authorizes any IPs listed in MailDog's own SPF record
• ip4:203.0.113.10 — explicitly authorizes a single IP address
• -all — fails anything not matched by the above (hard fail)

The all qualifier matters a lot:

• -all (hard fail): reject everything not explicitly listed
• ~all (soft fail): mark as suspicious but don't reject
• ?all (neutral): no policy; treat as if no SPF exists

For production sending, use -all or ~all. Using ?all or omitting the all mechanism gives spammers a free pass to send from your domain without SPF interference.

Setting Up SPF for the First Time

To create an SPF record, add a TXT record to your domain's DNS:

Name: @ (or your domain root)
Type: TXT
Value: v=spf1 include:[your-smtp-provider] -all

If you're using MailDog as your SMTP relay, the exact include mechanism value is provided during account setup. The MailDog documentation has copy-paste-ready SPF records for each configuration type.

If you send from multiple services — a transactional email provider, a marketing platform, and your own mail server — you need to authorize all of them in a single SPF record. This is where setups get complicated, and where the 10-lookup limit becomes a real constraint.

The 10-Lookup Limit

SPF has a rule that limits DNS lookups to 10 per evaluation. Every include:, redirect=, a:, and mx: mechanism in your record counts as a lookup — and each included record may contain additional lookups of its own.

If your SPF record causes more than 10 DNS lookups, evaluation fails with a permerror result. This doesn't just mean the extra servers aren't authorized — it means the entire SPF check fails, and your email is at risk across the board.

Large organizations that have accumulated many senders over the years are especially prone to this. The fix usually involves consolidating include: statements, replacing some with explicit IP ranges, or using a flattening service that resolves the includes and writes out the IPs directly into a single flat record.

SPF and Email Forwarding

SPF breaks with email forwarding. When someone forwards your email to another address, the forwarding server sends it onward using its own IP but keeps your original domain in the envelope sender. The receiving server then checks SPF against the forwarding server's IP, which isn't in your SPF record — and the check fails.

This is a known, inherent limitation of SPF, and it's part of why DKIM and DMARC exist. DKIM signatures survive forwarding because they're attached to the message headers rather than being IP-based. DMARC can be configured to use DKIM alignment instead of SPF alignment, which handles forwarded mail more gracefully. Setting up all three together is the right approach — SPF alone isn't sufficient for a complete authentication posture.

Common SPF Mistakes

• Having multiple SPF records. You can only have one TXT record with SPF content per domain. Multiple records cause a permerror. Combine everything into one record.
• Forgetting to include new sending services. Every time you add a tool that sends email from your domain, update your SPF record. Marketing automation platforms, helpdesk tools, and notification services all need to be authorized.
• Not setting SPF on subdomains. If you send from mail.yourdomain.com, that subdomain needs its own SPF record. Parent domain records don't automatically cover subdomains.
• Using overly permissive qualifiers. +all (the implied default if you omit the qualifier) authorizes any server to send from your domain, which completely defeats the purpose of SPF.

Verifying Your SPF Record

Check your SPF record from the command line:

dig TXT yourdomain.com | grep spf

For a more detailed analysis, use an SPF validation tool that will count your lookups, flag syntax errors, and show which IPs are authorized. After any DNS change, send a test message and check the email headers for the Authentication-Results field. A passing result looks like:

spf=pass (domain of sender@yourdomain.com designates 203.0.113.10 as permitted sender)

If you see spf=fail or spf=softfail, the sending IP isn't listed in your record. If you see spf=permerror, check your lookup count — you've almost certainly exceeded 10.

Getting SPF right is the first step toward a complete email authentication setup. Pair it with DKIM and DMARC to form the three-layer system that receiving servers expect from any legitimate sender. For a full walkthrough of the DNS configuration your domain needs, check out the MailDog DNS security guide or explore the MailDog blog for articles covering DKIM and DMARC setup as well.