Skip to main content

What is SPF?

SPF (Sender Policy Framework) is an email authentication protocol that lets domain owners specify which mail servers are authorized to send email on behalf of their domain, preventing spoofing and improving deliverability.

SPF at a Glance

Sender Verification

Confirms that emails come from mail servers you have explicitly authorized to send on your behalf

IP Authorization

Publishes a list of approved sending IP addresses in DNS so receivers can verify legitimacy

Spoofing Prevention

Stops attackers from forging your domain in the envelope sender address of outbound email

How SPF Works

1

Email Sent

A mail server sends an email claiming to be from your domain. The sending server's IP address is recorded in the email envelope.

2

DNS Lookup

The receiving mail server queries DNS for the SPF record of the sender's domain to retrieve the list of authorized sending IPs.

3

IP Check

The receiver compares the sending server's IP address against the authorized IPs and ranges listed in the SPF record.

4

Result Returned

The SPF check returns a result — pass, fail, softfail, or neutral — which the receiver uses to decide what to do with the message.

SPF Qualifiers

+ (Pass)
Authorized — accept the email
- (Fail)
Not authorized — reject the email
~ (SoftFail)
Probably not authorized — accept but mark
? (Neutral)
No assertion — treat as if no SPF record exists

History Timeline

2003

SPF Concept Introduced

Meng Weng Wong proposed the Sender Policy Framework concept to combat email spoofing by allowing domain owners to declare which IP addresses are permitted to send mail for their domain.

2006

RFC 4408 Published

SPF was published as an Experimental RFC (RFC 4408), establishing a formal specification for domain-based email authentication via DNS TXT records.

View RFC 4408
2014

RFC 7208 — Proposed Standard

SPF was elevated from Experimental to Proposed Standard with RFC 7208, superseding RFC 4408. This update clarified ambiguities and deprecated the dedicated SPF DNS record type in favor of TXT records.

View RFC 7208
2024

Google & Yahoo Mandate SPF

Google and Yahoo began requiring SPF authentication for all bulk senders, making SPF a practical requirement for email deliverability rather than an optional best practice.

2026

Universal Requirement

SPF is now universally required by major email providers. Domains without a valid SPF record face significantly reduced deliverability and are flagged as potential spoofing sources.

Record Mechanisms & Syntax

IP-Based Mechanisms

These mechanisms match the sending server's IP address directly against authorized addresses or ranges.

ip4
Match an IPv4 address or CIDR range
ip4:192.168.1.0/24
ip6
Match an IPv6 address or CIDR range
ip6:2001:db8::/32

Domain-Based Mechanisms

These mechanisms resolve a domain name to IP addresses and check against the sender's IP.

include
Include another domain's SPF record
include:_spf.google.com
a
Match the domain's A/AAAA record IPs
a:mail.example.com
mx
Match the domain's MX record IPs
mx

Special Mechanisms & Modifiers

Advanced mechanisms for delegation, conditional checks, and deprecated features.

redirect
Delegate evaluation to another domain's record entirely
exists
Match if a DNS A record lookup succeeds for the specified domain
ptr
Deprecated — reverse DNS lookup, slow and unreliable

Example Record

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

Version identifier (required)

ip4:192.0.2.0/24

Authorized IP range

include:...

Third-party senders

~all

SoftFail everything else

Why Your Domain Needs Sender Policy Framework

Prevent Spoofing

Stop attackers from sending fraudulent emails that appear to come from your domain.

Improve Deliverability

Emails from domains with valid SPF records are far less likely to land in spam folders.

DMARC Foundation

SPF is one of two authentication protocols required for DMARC alignment and enforcement.

Industry Compliance

Meet Google, Yahoo, and Microsoft bulk-sender requirements that mandate SPF authentication.

Brand Protection

Protect your brand reputation by ensuring only authorized servers send email as your domain.

Simple Setup

A single DNS TXT record is all it takes — no changes to your mail server software required.

Common Mistakes to Avoid

Exceeding the 10-Lookup Limit

SPF records are limited to 10 DNS lookups. Each include, a, mx, and redirect mechanism counts toward this limit. Exceeding it causes a permanent error (PermError), effectively disabling SPF.

Using +all

Setting +all authorizes every server on the internet to send as your domain, completely defeating the purpose of SPF. Use -all or ~all instead.

Multiple SPF Records

A domain must have exactly one SPF record. Publishing two or more TXT records that start with v=spf1 causes a PermError and both are ignored. Merge all mechanisms into a single record.

Using the Deprecated ptr Mechanism

The ptr mechanism is deprecated in RFC 7208 because it is slow, unreliable, and places a heavy load on DNS infrastructure. Use ip4/ip6 or include instead.

Implementation Steps

1

Inventory Your Sending Sources

List every service and server that sends email for your domain — your mail server, marketing platforms, CRM, transactional email providers, and any third-party applications.

2

Build Your SPF Record

Create a single DNS TXT record starting with v=spf1, followed by mechanisms for each authorized sender, and ending with ~all or -all.

3

Publish and Validate

Add the TXT record in your DNS provider, then use our SPF Checker to verify syntax, lookup count, and overall record validity.

4

Combine with DKIM and DMARC

SPF works best alongside DKIM and DMARC. Together, these three protocols provide comprehensive email authentication and domain protection.

Check Your SPF Record

Use our free SPF checker to validate your domain's SPF record and identify issues before they impact deliverability.