An SPF (Sender Policy Framework) record lists which servers can send email for your domain. The record acts as a guest list — if a server isn’t on it, receiving servers treat the email as suspicious (or reject it outright).
SPF lives in DNS as a TXT record. When someone receives an email claiming to be from your domain, the receiving server checks your SPF. If the sender’s IP matches your authorized list, authentication passes. If not, the email fails.
Microsoft changed the stakes in May 2025. Sending more than 5,000 emails daily without SPF, DKIM, and DMARC now triggers automatic rejection (error code 550 5.7.515). Your messages don’t reach spam — they bounce completely.
What you’ll learn:
- SPF record components and syntax
- Step-by-step setup process
- The 10-lookup limit (and workarounds)
- Common mistakes that break authentication
- Why SPF alone isn’t enough
What are the components of an SPF record?
Every SPF record follows strict syntax defined by RFC 7208. Deviate from the format, and receiving servers ignore your entire record (no partial credit here).
Version tag
Your record must start with v=spf1 — lowercase, no exceptions. A missing or incorrect version tag causes immediate failure.
Mechanisms
Mechanisms define who’s authorized to send email for your domain. Servers check them left to right, stopping at the first match.
| Mechanism | What it does | Counts toward lookup limit? |
| ip4 | Authorizes IPv4 addresses or ranges | No |
| ip6 | Authorizes IPv6 addresses or ranges | No |
| a | Authorizes servers in your A record | Yes |
| mx | Authorizes servers in your MX record | Yes |
| include | References another domain’s SPF record | Yes |
| all | Catches everything not matched earlier | No |
The include mechanism matters most when using third-party services. Sending through SendGrid? You need include:sendgrid.net so their servers can send on your behalf.
Qualifiers
Qualifiers tell receiving servers what action to take when a mechanism matches. A single character prefixes each mechanism.
| Qualifier | Symbol | What happens |
| Pass | + | Email authenticated |
| Fail | – | Email should be rejected |
| Soft Fail | ~ | Email accepted but marked suspicious |
| Neutral | ? | No specific action |
Most records end with either -all (strict rejection) or ~all (soft fail). Never use +all — it authorizes every IP address on the planet to send as your domain. One Reddit thread put it bluntly: “Only with over-permissive SPF records. (i.e. don’t use +all).”
Limits
SPF has two hard constraints that catch people off guard:
- 10 DNS lookups maximum: Each include, a, mx, and exists mechanism counts toward the limit
- One SPF record per domain: Multiple records cause immediate PermError failure
As one r/proofpoint user noted: “The issues occur when it’s more than 10 DNS lookups.” Exceeding the limit doesn’t work at all — authentication breaks entirely.
How do you set up an SPF record?
Setting up SPF takes about 40 minutes (excluding DNS propagation). The process requires listing your senders, building the record, and publishing to DNS.
1. List senders
Make a complete list of every server and service sending email on your domain:
- Internal mail server
- Email platform (Google Workspace, Microsoft 365)
- Marketing tools (Mailchimp, Klaviyo, HubSpot)
- Transactional services (SendGrid, Amazon SES, Postmark)
- CRM systems (Salesforce, Pipedrive)
- Support platforms (Zendesk, Intercom)
Missing even one source means those emails fail authentication. You’ll only discover the problem when customers complain (or worse, never reach out at all).
2. Build record
Create your SPF string using the format: v=spf1 [mechanisms] [qualifier]all
Example:
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net -all
The record above authorizes a specific IP range, Google Workspace, and SendGrid. The -all at the end rejects everything else.
3. Publish to DNS
Log in to your domain registrar (GoDaddy, Cloudflare, Namecheap) and navigate to DNS management. Create a new TXT record:
| Field | Value |
| Host/Name | @ or leave blank |
| Type | TXT |
| Value | Your SPF string |
| TTL | 3600 (or default) |
DNS changes can take up to 48 hours to propagate globally (though most updates complete within hours).
4. Handle subdomains
Publish SPF records on any domain or subdomain that sends email. If marketing.yourcompany.com sends campaigns, create a separate TXT record for that subdomain.
Subdomains that don’t send email can use an empty SPF (v=spf1 -all) to prevent spoofing. The empty record explicitly blocks all senders.
5. Validate record
Use free SPF checking tools to verify your record works:
- MXToolbox SPF Record Lookup
- SPF Checker by EmailWarmup.com
- SPF.guru
- DMARClytics SPF Checker
Run tests after every change. The tools catch syntax errors, multiple-record issues, and lookup limit violations before they tank deliverability.
How do you stay under the 10-lookup limit?
The 10-lookup limit exists to prevent DDoS attacks, but it creates headaches for companies using multiple email services. Each include statement triggers a DNS lookup — and nested includes count too.
Count lookups
Check your current count before adding new services. Tools like MXToolbox or SPF.guru show exactly how many lookups your record uses. Moreover, nested includes (services that include other services) can push you over the limit without warning.
Subdomain strategy
Push some vendors onto subdomains so each manages its own SPF record. Marketing emails from marketing.yourcompany.com get a separate SPF record, freeing up lookups on your main domain.
One r/devops commenter recommended: “A good approach is to push some vendors onto subdomains so they manage their own SPF.”
Central relay
Route all outbound mail through a single relay or provider. Instead of authorizing five different services, you authorize one relay that handles everything. However, the setup adds complexity (and creates a single point of failure).
SPF flattening
SPF flattening converts include statements to direct IP addresses, eliminating DNS lookups. The downside is that IP addresses change without notice.
As one sysadmin warned: “Flattening is possible, but I’d only use it if there’s no other way since it’s hard to keep updated.”
Hosted SPF
Services like Proofpoint’s EFD or Valimail manage your SPF record dynamically.
Hosted SPF solutions bypass the 10-lookup limit through macro expansion. For complex email setups, hosted SPF might be the only practical solution.
One r/proofpoint user claimed: “Hosted SPF with Proofpoint is the only way SPF records should be handled.”
What about the 255-character limit?
SPF records can exceed 255 characters, but DNS TXT records have a 255-character limit per string. For longer records, you must split the value into multiple strings within the same TXT record.
Most DNS hosts with web interfaces handle splitting automatically. As one r/sysadmin user clarified: “SPF records can be longer than 255 characters, but DNS TXT record strings are limited to 255 characters so you have to use multiple strings.”
If your provider doesn’t auto-split, format the record like this:
“v=spf1 include:_spf.google.com include:sendgrid.net ” “include:servers.mcsv.net -all”
The receiving server concatenates the strings before processing. However, the total record length has a practical limit of about 512 bytes — beyond that, UDP truncation can cause issues.
How does SPF work with subdomains?
Subdomains that send email need their own SPF records. The main domain’s SPF doesn’t automatically apply to subdomains (a common misconception).
Sending subdomains
If marketing.yourcompany.com sends campaigns, create a separate TXT record:
| Host | Value |
| marketing | v=spf1 include:servers.mcsv.net -all |
Non-sending subdomains
Subdomains that don’t send email should use an empty SPF to prevent spoofing:
v=spf1 -all
The record explicitly blocks all senders — protecting unused subdomains from abuse.
What mistakes kill SPF authentication?
Six errors account for most SPF failures. Each one can tank your sender reputation overnight.
Multiple records
Your domain can have only one SPF TXT record. Creating two (often by accident when adding a new service) causes PermError. Receiving servers see conflicting records and fail authentication automatically.
Lookup overflow
Exceeding 10 DNS lookups triggers immediate failure. The record doesn’t work partially — it breaks completely. Audit your lookups quarterly, especially after adding new email services.
Syntax errors
A misplaced space, a missing version tag, or an unsupported character breaks everything. The version tag must be exactly v=spf1 (lowercase). SPF syntax either works perfectly or fails completely (no graceful degradation).
Overly permissive
The +all qualifier authorizes every IP address on Earth to send as your domain. Stick with -all or ~all at the end of your record.
Stale references
When you cancel an email service, remove the include from your SPF record. Dead references waste DNS lookups. Most people forget until deliverability tanks.
Dangling domains
When referencing domains via include or CNAME, ensure they remain registered. One security-focused Redditor flagged the risk: “There’s also dangling CNAMEs to consider… a threat actor can take over said unregistered or expired domain… and start sending mail as it, passing SPF.”
If a referenced domain expires, an attacker can register it and start sending authenticated email as your domain.
Why can’t you rely on SPF record alone?
SPF protects only the hidden Return-Path address used for routing, not the visible “From” address recipients see. A sophisticated spammer can pass SPF using their own domain in the Return-Path while forging your brand in the From field.
The alignment gap
Recipients see an email that appears to come from your company, but SPF doesn’t verify the visible From address. Additionally, email forwarding breaks SPF — the forwarding server’s IP won’t match your record.
Complete protection
Running SPF without DKIM and DMARC leaves massive security gaps:
| Protocol | What it verifies | Standalone protection |
| SPF | Sending server IP | Partial |
| DKIM | Message content integrity | Partial |
| DMARC | Alignment + policy enforcement | Complete (with SPF + DKIM) |
DKIM adds cryptographic signatures to verify message content. DMARC ties SPF and DKIM together and tells receiving servers how to handle failures. For Gmail and Yahoo bulk sender requirements, you need all three configured and aligned.
Need help with SPF setup?
SPF mistakes cascade into deliverability problems that damage sender reputation. Getting authentication right the first time saves weeks of troubleshooting.
Our email deliverability consultants handle the complete authentication stack — SPF, DKIM, and DMARC. We audit your email infrastructure, configure records correctly, and monitor authentication health ongoing.
What we handle:
- Lookup limit management
- DKIM and DMARC configuration
- Ongoing authentication monitoring
- SPF record creation and optimization
Book a free consultation and fix your email authentication for good.
Frequently asked questions
Here are some commonly asked questions about SPF record:
No, each domain needs its own SPF TXT record. However, you can use the redirect modifier to point multiple domains to a shared record (only works when you control all domains and they share the same mail infrastructure).
Update immediately when adding or removing email services. Audit quarterly to remove dead references. Stale include statements waste DNS lookups and create security gaps (dangling references can be hijacked).
Split the record into multiple strings within the same TXT record. Most DNS providers handle splitting automatically. The receiving server concatenates strings before processing.
SPF breaks when emails are forwarded. The forwarding server’s IP won’t match your SPF record. DMARC with relaxed alignment and SRS (Sender Rewriting Scheme) helps mitigate forwarding issues.
-all (hard fail) instructs receivers to reject unauthorized senders. ~all (soft fail) marks unauthorized emails as suspicious but still delivers them. Use -all for maximum security once you’ve verified all legitimate senders.
Usually a few hours, but up to 48 hours globally. If changes don’t appear after 48 hours, double-check your record syntax and ensure you’re editing the correct DNS zone.
