What SPF Records Do for Your Email Authentication
SPF (Sender Policy Framework) records tell receiving mail servers which IP addresses can send email from your domain. Without proper SPF configuration, your legitimate emails might end up in spam folders, and attackers could easily spoof your domain to send malicious messages.
This tutorial walks you through creating, testing, and troubleshooting SPF records for your domain's email authentication system. You'll learn the syntax, common patterns, and practical setup steps that work with major hosting configurations.
Understanding SPF Record Structure and Syntax
SPF records use TXT records in DNS with a specific format. Every SPF record starts with v=spf1 and ends with a mechanism that defines the default action.
Here's the basic structure:
- v=spf1 - Version identifier (always required)
- Mechanisms - Define which servers can send email
- Qualifiers - Specify what happens when a mechanism matches
- Default action - Usually
~allor-all
Common mechanisms include ip4: for IPv4 addresses, include: for third-party services, and a to authorize your domain's A record IP address.
Step 1: Identify Your Email Sending Sources
Before you configure SPF records, document all servers and services that send email from your domain. Missing a legitimate sender will cause delivery failures.
Check these sources:
- Your primary mail server (often your VPS or dedicated server)
- Website contact forms and application notifications
- Third-party services like MailChimp, SendGrid, or Google Workspace
- Backup or secondary mail servers
- Any scripts or applications that send automated emails
For a Hostperl VPS running your own mail server, you'll typically need your server's IP address and any external services you use for email delivery.
Step 2: Build Your SPF Record
Start with the basic structure and add mechanisms for each email source you identified.
For a simple setup with one mail server:
v=spf1 ip4:192.0.2.100 ~all
For multiple sources, combine mechanisms:
v=spf1 ip4:192.0.2.100 include:_spf.google.com include:servers.mcsv.net ~all
The ~all qualifier means "soft fail" - recipients should accept the email but mark it as suspicious. Use -all for "hard fail" only after thorough testing, as it will cause legitimate emails to bounce if your record is incomplete.
Step 3: Add the SPF Record to Your DNS
How you add DNS records depends on where you manage your domain's DNS. Here's how to set up SPF in common scenarios:
Using cPanel DNS Zone Editor
Log into cPanel and navigate to Zone Editor. Click "Manage" next to your domain, then "Add Record":
- Type: TXT
- Name: @ (represents your root domain)
- TTL: 14400 (4 hours)
- Record: Your complete SPF record starting with v=spf1
Using Command Line on Ubuntu VPS
If you manage DNS directly on your server using BIND, edit the zone file:
sudo nano /var/cache/bind/db.yourdomain.com
Add the SPF record as a TXT entry:
@ IN TXT "v=spf1 ip4:YOUR_SERVER_IP ~all"
Reload the DNS service:
sudo systemctl reload bind9
Step 4: Test Your SPF Record Configuration
After adding the record, wait for DNS propagation (usually 15-30 minutes) and test using command-line tools.
Check if the SPF record exists:
dig yourdomain.com TXT
Look for a line containing your SPF record in the ANSWER section. You can also use specialized SPF testing tools:
nslookup -type=TXT yourdomain.com
Test from a different server to verify external visibility:
host -t TXT yourdomain.com 8.8.8.8
Common SPF Record Patterns for Different Hosting Setups
Your SPF record structure depends on your hosting configuration and email services. Here are tested patterns for different scenarios.
Self-Hosted Mail Server Only
If you run Postfix or another mail server directly on your VPS:
v=spf1 a mx ~all
This authorizes servers listed in your domain's A and MX records to send email.
Mixed Hosting with External Email Service
For websites hosted on your VPS but email through Google Workspace:
v=spf1 include:_spf.google.com ip4:YOUR_VPS_IP ~all
Multiple External Services
When using several third-party email services:
v=spf1 include:_spf.google.com include:servers.mcsv.net include:spf.protection.outlook.com ~all
Remember the 10 DNS lookup limit - SPF processing stops after 10 lookups, so avoid too many include mechanisms.
Troubleshooting SPF Record Issues
SPF problems usually show up as delivery failures or spam classification. Here's how to diagnose and fix the most common issues.
Email Bouncing with SPF Failures
If legitimate emails bounce with SPF-related errors, check the bounce message for the IP address that failed authentication. Add that IP to your SPF record:
v=spf1 ip4:EXISTING_IP ip4:FAILED_IP ~all
Too Many DNS Lookups Error
SPF has a 10 DNS lookup limit. Each include: mechanism counts as one lookup. If you exceed this limit, replace some includes with direct IP addresses:
Instead of: include:_spf.sendgrid.net
Use: ip4:167.89.118.32 ip4:167.89.118.33
Multiple SPF Records
Only one SPF record per domain is allowed. If you have multiple TXT records starting with "v=spf1", combine them into a single record.
Running your own mail server or managing DNS records requires reliable hosting infrastructure. Hostperl's managed VPS hosting includes DNS management tools and support for email server configurations, making SPF setup straightforward for your email authentication needs.
Advanced SPF Configuration Options
Beyond basic IP and include mechanisms, SPF offers additional options for complex email infrastructures.
Using Exists Mechanism for Dynamic Checking
The exists mechanism performs a DNS lookup and passes if any A record exists:
v=spf1 exists:%{i}.whitelist.yourdomain.com ~all
This approach works for dynamic IP validation but adds complexity.
Redirect Modifier for Domain Aliases
When multiple domains share the same email infrastructure, use redirect to point to a master SPF record:
v=spf1 redirect=_spf.maindomain.com
This keeps SPF management centralized while supporting multiple domains.
Monitoring and Maintaining Your SPF Records
SPF records need regular maintenance as your email infrastructure changes. Set up monitoring to catch issues early.
Review your mail logs monthly for SPF-related bounces:
grep -i "spf" /var/log/mail.log | tail -20
When adding new email services, test SPF changes in staging first. Use the soft fail qualifier (~all) during testing, then switch to hard fail (-all) once you're confident the record is complete.
Keep documentation of all authorized email sources. This helps during troubleshooting and prevents accidentally removing legitimate senders during SPF updates.
For related email authentication setup, check our guides on DMARC policy configuration and mail server high availability to complete your email security implementation.
FAQ
Can I have multiple SPF records for one domain?
No, you can only have one SPF record per domain. Multiple SPF records will cause authentication failures. Combine all your email sources into a single SPF record instead.
What's the difference between ~all and -all in SPF records?
The ~all qualifier means "soft fail" - emails that don't match get marked as suspicious but are usually delivered. The -all qualifier means "hard fail" - emails that don't match should be rejected completely.
How long does it take for SPF changes to take effect?
SPF changes follow normal DNS propagation rules, typically taking 15-30 minutes to propagate globally. However, some mail servers cache DNS records longer, so allow up to 24 hours for complete propagation.
Do I need SPF if I use third-party email services like Gmail?
Yes, you should still set up SPF records even when using external email services. Include the service provider's SPF record using the include mechanism, plus any other servers that send email from your domain.
What happens if I don't configure SPF records?
Without SPF records, receiving mail servers can't verify that email claiming to be from your domain is legitimate. This often results in emails being marked as spam and makes your domain vulnerable to email spoofing attacks.

