Sender Policy Framework (SPF) is an email authentication protocol that helps prevent email spoofing by validating the sender's IP address against authorized mail servers. The SPF record is published in your domain's DNS as a TXT record.
The basic SPF record structure includes mechanisms and qualifiers:
"v=spf1 a mx ip4:192.0.2.0/24 include:thirdparty.com ~all"
Key mechanisms:
- a: Authorizes domain's A record IPs
- mx: Authorizes domain's MX record IPs
- ip4/ip6: Specifies IP ranges directly
- include: References another domain's SPF policy
- all: Default match for everything else
For your scenario with multiple computers sharing one IP:
"v=spf1 ip4:203.0.113.1/32 include:_spf.google.com ~all"
This authorizes your office IP (203.0.113.1) and includes Gmail's SPF policy if you use Google Workspace.
Additional Sending Domains
If you use third-party email services (like Mailchimp or SendGrid), add their domains:
include:servers.mcsv.net include:_spf.salesforce.com
IP Address Ranges
For your office network with dynamic IP:
ip4:203.0.113.0/24
Stringency Level
Recommended qualifiers:
- -all (Hard fail): Strictest, reject unauthorized mail
- ~all (Soft fail): Mark as suspicious but deliver
- ?all (Neutral): No policy assertion
For complex environments with multiple mail servers:
"v=spf1 mx ip4:192.168.1.1/28 ip6:2001:db8::/32
include:spf.protection.outlook.com
include:_spf.example.net
-all"
Use these tools to verify your SPF record:
- dig TXT yourdomain.com
- SPF validators (like MXToolbox or Kitterman)
- Email header analysis
Avoid these mistakes:
- Exceeding 10 DNS lookups (SPF limit)
- Using PTR records (deprecated in SPF)
- Incorrect CIDR notation
- Missing updates when changing email providers
Remember that SPF should be combined with DKIM and DMARC for comprehensive email security. The recommended deployment order is: SPF → DKIM → DMARC.
Sender Policy Framework (SPF) is a DNS TXT record that specifies which mail servers are permitted to send email on behalf of your domain. It's a critical email authentication mechanism that helps prevent spammers from sending messages with forged From addresses.
The basic SPF record structure follows this pattern:
v=spf1 [mechanisms] [modifiers]
Key mechanisms include:
ip4:
for IPv4 addressesip6:
for IPv6 addressesa:
for hostnames that resolve to A recordsmx:
for mail exchangersinclude:
to reference other domains' SPF records
Given your office environment with multiple computers sharing one external IP and mobile clients, here's a recommended SPF structure:
v=spf1 ip4:203.0.113.5 include:_spf.google.com ~all
Breaking this down:
ip4:203.0.113.5
- Your office's external IP (replace with actual IP)include:_spf.google.com
- If using Google Workspace for mobile email~all
- SoftFail policy for unmatched senders
1. Additional sending domains:
List any third-party services sending email for your domain:
include:servers.mailchimpapp.com include:amazonses.com
2. Additional IP ranges:
Specify CIDR ranges if you have multiple office locations or cloud servers:
ip4:203.0.113.0/24 ip4:198.51.100.16/28
3. Additional sending hosts:
List any mail servers or SMTP relays by hostname:
a:mail.example.com a:relay.backupmx.com
4. SPF strictness level:
Choose between:
-all
(Fail) - Reject non-compliant mail~all
(SoftFail) - Accept but mark suspicious?all
(Neutral) - No policy
Here's a complete SPF record for a typical business scenario:
v=spf1 ip4:203.0.113.5 ip4:198.51.100.32/28 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org a:mail.example.com mx ~all
Add this as a TXT record in your domain's DNS zone file:
example.com. IN TXT "v=spf1 ip4:203.0.113.5 include:_spf.google.com ~all"
After implementation, verify with:
dig TXT example.com
(command line)- MXToolbox SPF Checker
- SPF Validator
- Exceeding the 10 DNS lookup limit
- Incorrect CIDR notation in IP ranges
- Missing updates when infrastructure changes
- Conflicts with DMARC policies