What is SPF? Email Authentication and Deliverability Explained

What is an SPF Record? The Email Sender's Identity Card

Imagine receiving a letter that claims to be from your bank. The envelope has your bank's logo, the return address is your bank's headquarters, and the letter looks official. But how do you know it's really from your bank? Anyone could print a fake letterhead and use your bank's address.

Sender Policy Framework (SPF) is the email world's solution to this problem. It's a simple DNS TXT record that lets domain owners publish an official list of servers authorized to send email on their behalf. When an email arrives at a receiving server, that server can check SPF to verify whether the email actually came from an authorized sender.

SPF is one of the three pillars of email authentication, alongside DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance). Together, these protocols help prevent email spoofing, phishing, and spam while improving deliverability for legitimate senders.

A Quick History of SPF

SPF was first proposed in 2003 as a response to the growing problem of email spoofing. Before SPF, anyone with basic technical knowledge could send emails claiming to be from any domain—including banks, government agencies, and major corporations. Phishing attacks exploded.

The original SPF specification (RFC 4408) was published in 2006 and later updated by RFC 7208 in 2014. Today, SPF is supported by every major email provider, including Gmail, Outlook, Yahoo, and Apple Mail. Major providers like Google and Microsoft require SPF (along with DKIM and DMARC) for bulk senders to ensure inbox placement.

How SPF Works: The Step-by-Step Verification Process

Understanding how SPF verification works helps you troubleshoot issues and configure your records correctly. Here's what happens when someone sends an email to a recipient at a server that supports SPF.

Step-by-Step SPF Verification

1. Email is sent: A sender composes an email from sender@yourdomain.com. Their email client passes the message to their configured SMTP server (e.g., Google Workspace's smtp.gmail.com).
2. SMTP handshake: The SMTP server connects to the recipient's mail server (e.g., Gmail's incoming server). During the SMTP conversation, the sending server identifies itself and provides the "MAIL FROM" address (also called the envelope sender or return-path).
3. SPF lookup: The recipient's server extracts the domain from the MAIL FROM address. It performs a DNS query for a TXT record at that domain starting with v=spf1.
4. Record retrieval: If the domain has an SPF record, the recipient's server receives a string like: v=spf1 include:_spf.google.com ip4:192.168.1.100 -all
5. Mechanism evaluation: The recipient's server evaluates each mechanism in the SPF record from left to right, checking whether the sending server's IP address matches any of the authorized sources.
6. Result determination: Based on the evaluation, the recipient's server returns one of several possible results (Pass, Fail, SoftFail, Neutral, None, PermError, TempError).
7. Action taken: The recipient's server applies the policy defined by the SPF record (or the receiving server's own rules). A Pass result typically allows delivery; a Fail or SoftFail result may trigger spam filtering or rejection.

SPF Results Explained

• Pass: The sending server's IP is authorized. Email is trusted. (Best outcome)
• Fail (-all): The sending server's IP is explicitly unauthorized. Email is rejected or sent to spam.
• SoftFail (~all): The sending server's IP is likely unauthorized. Email is accepted but marked as suspicious.
• Neutral (?all): The SPF record doesn't state whether the IP is authorized. Rarely used.
• None: No SPF record exists for the domain. No authentication performed.
• PermError: The SPF record is malformed or exceeds the 10-DNS-lookup limit. Emails may be rejected.
• TempError: A temporary DNS error occurred. Receiving server may retry later.

Understanding SPF Record Syntax: Breaking Down the Code

SPF records look intimidating at first, but they follow a simple, logical structure. Once you understand the components, you can read and write SPF records confidently.

The Basic Structure

v=spf1 mechanism1 mechanism2 mechanism3 ... modifier

v=spf1: Every SPF record must start with this version identifier. It tells the receiving server that this TXT record is an SPF record using version 1 of the specification.

Common Mechanisms

Mechanisms define which servers are authorized to send email. They are evaluated from left to right.

• include: Includes the SPF record from another domain. Most common with email providers. Example: include:_spf.google.com includes Google Workspace's authorized sending IPs.
• ip4: Authorizes a specific IPv4 address or range using CIDR notation. Example: ip4:192.168.1.100 or ip4:192.168.0.0/16
• ip6: Authorizes a specific IPv6 address or range. Example: ip6:2001:db8::/32
• a: Authorizes the IP address(es) of the domain's A record. Example: a:mail.yourdomain.com
• mx: Authorizes the IP addresses of the domain's MX records. Example: mx or mx:mail.yourdomain.com
• ptr: (Deprecated, not recommended) Authorizes if the IP's reverse DNS matches the domain.
• exists: Performs a DNS lookup and authorizes if the lookup returns any result. Advanced use cases only.

Qualifiers (How to Handle Matching Mechanisms)

Each mechanism can be prefixed with a qualifier that tells the receiving server what to do when that mechanism matches.

• + (Pass - Default): The email is authorized. If no qualifier is specified, + is assumed.
• - (Fail): The email is explicitly unauthorized. Reject or spam.
• ~ (SoftFail): The email is likely unauthorized but accept it anyway (mark as suspicious).
• ? (Neutral): No statement about authorization. Rarely used.

The All Mechanism (The Policy Default)

The all mechanism appears at the end of most SPF records. It acts as a catch-all for IP addresses not matched by earlier mechanisms.

• +all - EVERY server is authorized. NEVER use this—it completely disables SPF protection.
• -all - Hard Fail: Unauthorized emails are rejected. Use when you're confident all senders are listed.
• ~all - SoftFail: Unauthorized emails are accepted but marked suspicious. Recommended for most domains.
• ?all - Neutral: No policy. Not helpful. Avoid.

Modifiers

Modifiers appear after mechanisms and provide additional instructions.

• redirect=domain.com - Redirects SPF evaluation to another domain's SPF record. The redirect domain's SPF record is evaluated instead.
• exp=some.domain - Specifies an explanation string to display when an email fails SPF.

Example SPF Record Walkthrough

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 ~all

This record:

• Authorizes all IPs in Google Workspace's SPF record (via include:_spf.google.com)
• Authorizes the IP range 203.0.113.0-255 (via ip4:203.0.113.0/24)
• All other IPs get SoftFail (~all)

Why Your Domain Needs SPF: The Cost of Doing Nothing

Without an SPF record (or with a misconfigured one), your domain is vulnerable to spoofing, phishing, and deliverability problems. Here's what's at stake.

1. Email Spoofing and Phishing Attacks

Without SPF, anyone can send emails that appear to come from your domain. Attackers can spoof your CEO's email address to request wire transfers, impersonate your support team to steal customer credentials, or send phishing emails to your partners and vendors.

Real-world impact: The FBI's Internet Crime Complaint Center (IC3) reports that business email compromise (BEC) attacks—many enabled by spoofed emails—have caused over $50 billion in losses since 2013. SPF, DKIM, and DMARC are the primary defenses against these attacks.

2. Poor Email Deliverability

Major email providers like Gmail, Microsoft 365, and Yahoo use SPF as a key signal in their spam filtering algorithms. Domains without SPF (or with failing SPF) are more likely to have emails sent to spam folders or rejected outright.

Data point: According to industry studies, emails from domains with valid SPF are 30-40% less likely to be marked as spam compared to domains without SPF.

3. Brand Reputation Damage

When recipients see a spoofed email from your domain, they may not realize it's fake. They may blame your company for the phishing attempt, lose trust in your brand, or unsubscribe from legitimate communications.

4. Inability to Enforce DMARC

DMARC (Domain-based Message Authentication, Reporting & Conformance) requires either SPF or DKIM to pass and align with the From domain. Without a valid SPF record, you cannot enforce a DMARC policy of quarantine or reject—leaving your domain vulnerable to spoofing.

How to Create and Publish an SPF Record: A Step-by-Step Guide

Creating an SPF record requires identifying all servers that send email for your domain and formatting them correctly. Here's how to do it.

Step 1: Identify All Email Sending Sources

Make a list of every service, platform, or server that sends email from your domain. Common sources include:

• Your primary email provider (Google Workspace, Microsoft 365, Exchange, etc.)
• Marketing platforms (Mailchimp, Klaviyo, HubSpot, Salesforce Marketing Cloud)
• Transactional email services (SendGrid, Amazon SES, Postmark, Mailgun)
• CRM systems (Salesforce, Zoho, HubSpot CRM)
• Support ticketing systems (Zendesk, Intercom, Freshdesk)
• E-commerce platforms (Shopify, WooCommerce, Magento)
• Your own web server (if it sends contact form emails or notifications)

Step 2: Find Each Provider's SPF Include Value

Most email providers publish their SPF include values in their documentation. Common ones include:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• SendGrid: include:sendgrid.net
• Mailchimp: include:servers.mcsv.net
• Amazon SES: Varies by region (e.g., include:amazonses.com)
• Zendesk: include:mail.zendesk.com

Step 3: Add Your Own IP Addresses

If you send email from your own servers (e.g., a web server sending contact form emails), find your server's public IP address and add it using the ip4: or ip6: mechanism.

Step 4: Construct Your SPF Record

Combine all mechanisms in a single string, starting with v=spf1, then each include or IP mechanism, then the all policy.

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 ~all

Step 5: Add the Record to Your DNS

1. Log into your DNS management panel (Cloudflare, GoDaddy, AWS Route53, etc.)
2. Navigate to the DNS records section.
3. Add a new TXT record.
4. For the Name/Host field, enter @ (for the root domain) or leave blank (depending on your provider).
5. For the Value/Text field, paste your SPF record.
6. Set TTL to 3600 (1 hour) or lower.
7. Save the record.

Step 6: Verify Your SPF Record

Use our SPF Checker to validate your record. The tool will check:

• Syntax correctness
• DNS lookup count (must be ≤ 10)
• Whether all includes resolve correctly
• Policy qualifier (should be ~all or -all)

SPF vs DKIM vs DMARC: The Email Authentication Trinity

SPF is powerful, but it's not complete on its own. For full protection, you need all three pillars of email authentication.

SPF (Sender Policy Framework)

What it does: Authorizes which IP addresses can send email for your domain.

What it checks: The envelope sender (MAIL FROM address).

Limitation: SPF breaks when email is forwarded. The forwarding server's IP may not be authorized, causing legitimate forwarded emails to fail SPF.

DKIM (DomainKeys Identified Mail)

What it does: Cryptographically signs email with your domain's private key.

What it checks: The email headers and body (not the envelope sender).

Advantage: DKIM survives forwarding because the signature travels with the email.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

What it does: Tells receiving servers what to do when SPF or DKIM fails, and provides reporting.

What it checks: Domain alignment between the From header and SPF/DKIM domains.

Advantage: DMARC closes the gaps in SPF and DKIM, providing a unified policy and visibility into authentication failures.

How They Work Together

Think of it like airport security:

• SPF is like checking your ID against the flight manifest (authorized list).
• DKIM is like a tamper-evident seal on your luggage (cryptographic signature).
• DMARC is the security policy telling agents what to do if something's wrong (reject, quarantine, or report).

The Complete Protection Strategy

1. Set up SPF with ~all (SoftFail) initially
2. Set up DKIM signing for all email sources
3. Create a DMARC policy at p=none (monitor only) to start
4. Analyze DMARC reports to identify any missing email sources
5. Update SPF to include any missing sources
6. Once confident, move DMARC to p=quarantine and then p=reject
7. Change SPF to -all (Hard Fail) for maximum protection