SPF Record: What It Is and How to Create One

What Is SPF?

SPF (Sender Policy Framework) is an email authentication protocol defined in RFC 7208. It allows domain owners to specify which mail servers are authorized to send email on behalf of their domain.

When a receiving mail server gets a message, it checks the envelope sender domain (the MAIL FROM address, also known as the Return-Path) and looks up the SPF record in DNS. The record lists authorized IP addresses and domains. If the sending server's IP matches, SPF passes. If not, the result depends on the record's qualifier.

SPF is one of three email authentication protocols (alongside DKIM and DMARC) that work together to prevent email spoofing and improve deliverability.

SPF Record Syntax

An SPF record is a DNS TXT record published at the root of your domain. It starts with v=spf1 and contains a series of mechanisms and qualifiers:

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

Mechanisms

Qualifiers

Each mechanism can be prefixed with a qualifier that determines the result when matched:

The all mechanism at the end of your record is the most important qualifier. Use -all (hardfail) to tell receivers that any IP not explicitly listed is unauthorized.

Creating Your SPF Record

Step 1: Identify All Sending Sources

List every server and service that sends email using your domain. Common sources include:

• Your own mail server (IP address or hostname)
• Google Workspace (include:_spf.google.com)
• Microsoft 365 (include:spf.protection.outlook.com)
• Marketing platforms: Mailchimp (include:servers.mcsv.net), SendGrid (include:sendgrid.net)
• Transactional email: Amazon SES (include:amazonses.com), Postmark (include:spf.mtasv.net)
• CRM and support tools: Salesforce, Zendesk, Freshdesk

Check with each service provider for their specific SPF include domain.

Step 2: Build the Record

Combine all sources into a single record. Example for a company using Google Workspace and SendGrid:

v=spf1 include:_spf.google.com include:sendgrid.net -all

If you also send from your own server at 203.0.113.10:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net -all

Step 3: Publish in DNS

Add a TXT record at your domain root:

• Host/Name: @ (or leave blank — your DNS provider may auto-append the domain)
• Type: TXT
• Value: Your SPF record string
• TTL: 3600

Verify the record is published:

dig TXT example.com +short

Step 4: Test

Send a test email and check the Authentication-Results header for spf=pass. Or use our delivery test tool to check SPF, DKIM, and DMARC in one step.

Common SPF Mistakes

1. Using +all

The record v=spf1 +all authorizes every IP address on the internet to send email as your domain. This is equivalent to having no SPF record and provides zero protection. Always end with -all or at minimum ~all.

2. Multiple SPF Records

A domain must have exactly one SPF TXT record (one record starting with v=spf1). If you have two, the result is a permerror and most receivers treat it as no SPF at all. When adding a new service, add it to your existing record — do not create a second one.

3. Too Many DNS Lookups

SPF has a hard limit of 10 DNS lookups per evaluation. Each include, a, mx, redirect, and exists mechanism counts. Exceeding this limit causes a permerror. See the section below and our detailed fix guide.

4. Missing Sending Sources

Forgetting to include a legitimate sending service is the most common cause of SPF failures. When you add a new email service (marketing tool, CRM, ticketing system), update your SPF record immediately.

5. Using the ptr Mechanism

The ptr mechanism is deprecated in RFC 7208 due to performance issues. It requires reverse DNS lookups for every evaluation, which is slow and unreliable. Use ip4/ip6 or include instead.

The 10 DNS Lookup Limit

RFC 7208 Section 4.6.4 limits SPF evaluation to 10 DNS-querying mechanisms. This prevents SPF from being used as a denial-of-service amplification vector.

Mechanisms that count toward the limit: include, a, mx, redirect, exists. Each include also recursively counts the lookups in the included record.

Mechanisms that do not count: ip4, ip6, all.

There is also a separate limit of 2 "void lookups" (DNS queries that return no records). Exceeding either limit results in a permerror.

If your record exceeds 10 lookups, see our dedicated guide: SPF Record Too Many DNS Lookups — How to Fix.

SPF and Email Forwarding

SPF has a fundamental limitation with email forwarding. When a message is forwarded, the forwarding server's IP is not in the original sender's SPF record, so SPF fails.

Two mechanisms address this:

• SRS (Sender Rewriting Scheme): The forwarding server rewrites the envelope sender to its own domain, so SPF checks against the forwarder's SPF record instead. This preserves SPF but changes the Return-Path.
• ARC (Authenticated Received Chain): Defined in RFC 8617, ARC allows intermediate servers to sign the authentication results they observed. The final receiver can use ARC to trust the original authentication even after forwarding.

This is why DKIM is essential alongside SPF — DKIM signatures survive forwarding because they are attached to the message itself, not the sending IP.

FAQ

Can I have multiple SPF records?

No. A domain must have exactly one SPF TXT record. Multiple SPF records cause a permerror, and most receivers will treat it as no SPF record at all. If you need to authorize additional senders, add them to your existing record using include or ip4/ip6 mechanisms.

What does ~all vs -all mean?

~all (softfail) means messages from unauthorized IPs should be accepted but marked as suspicious. -all (hardfail) means they should be rejected. In practice, most receivers treat both similarly when DMARC is in place. Use -all for the strongest signal.

Does SPF check the From header?

No. SPF checks the envelope sender (MAIL FROM / Return-Path), not the visible From: header. This is why SPF alone cannot prevent spoofing of the From: header — you need DMARC for that, which adds alignment checking between the envelope sender and the From: header.