SPF Record Configuration Guide: Best Practices for Email Authentication and Anti-Spoofing


2 views

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 addresses
  • ip6: for IPv6 addresses
  • a: for hostnames that resolve to A records
  • mx: for mail exchangers
  • include: 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:

  • Exceeding the 10 DNS lookup limit
  • Incorrect CIDR notation in IP ranges
  • Missing updates when infrastructure changes
  • Conflicts with DMARC policies