SPF Record Syntax & Format [2026]

What Is SPF (Sender Policy Framework)?

SPF (Sender Policy Framework) is an email authentication protocol that lets you declare which mail servers are authorized to send email on behalf of your domain. When a receiver gets an email claiming to be from your domain, it checks your SPF record to verify the sending server is on your approved list. As our 2026 email authentication research shows, SPF adoption continues to grow but misconfiguration remains a leading cause of delivery failures.

Published as a DNS TXT record, SPF helps prevent email spoofing by giving receivers a way to verify that an email’s sending server is legitimate. The protocol is defined in RFC 7208.

SPF answers one critical question: Is this mail server allowed to send email for this domain?

How SPF Works

Here’s what happens when an email is sent from your domain:

1. You publish an SPF record as a DNS TXT record on your domain (e.g., v=spf1 ip4:203.0.113.5 -all)
2. A receiver gets an email claiming to be from your domain
3. The receiver extracts the envelope sender (the MAIL FROM address, also called Return-Path)
4. The receiver looks up your SPF record by querying DNS for a TXT record at your domain
5. The receiver checks the sending server’s IP against the authorized IPs/mechanisms in your SPF record
6. SPF returns a result: pass, fail, softfail, neutral, none, temperror, or permerror

SPF validates the envelope sender (MAIL FROM), not the visible From: header users see. This is why SPF must be used with DMARC to fully prevent spoofing.

SPF Record Syntax: Mechanisms, Qualifiers, and Modifiers

SPF record syntax follows a structured format. Every SPF record starts with v=spf1 and contains one or more mechanisms that define which servers are authorized to send email. If you need to build one quickly, our SPF record generator walks you through each mechanism step by step.

Basic SPF Record Format

v=spf1 <mechanism> <mechanism> <qualifier><all>

SPF Mechanisms

Mechanisms specify which IPs or domains are authorized to send email. Each mechanism can optionally include a qualifier (+, -, ~, ?).

The include Mechanism

The include mechanism is the most common way to authorize third-party email services. When you use include:example.com, the receiver performs a DNS lookup on example.com and processes that domain’s SPF record.

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

This authorizes all IPs listed in Google Workspace’s SPF record (_spf.google.com). Each include counts as one DNS lookup toward the 10-lookup limit.

SPF Qualifiers

Qualifiers define what action the receiver should take when a mechanism matches. If no qualifier is specified, + (pass) is assumed.

Examples:

• +ip4:203.0.113.5 (pass — authorized)
• -ip4:192.0.2.1 (fail — reject)
• ~all (softfail — not authorized, but accept anyway)

SPF Record Examples

Google Workspace

v=spf1 include:_spf.google.com ~all

This authorizes Google’s mail servers to send email on behalf of your domain. The ~all softfail is recommended by Google during initial setup.

Microsoft 365

v=spf1 include:spf.protection.outlook.com ~all

This authorizes Microsoft 365’s mail servers. Replace ~all with -all once you’ve verified all legitimate senders are covered.

SendGrid

v=spf1 include:sendgrid.net ~all

SendGrid publishes its sending IPs at sendgrid.net. If you use SendGrid as your only email service, this is all you need.

Mailgun

v=spf1 include:mailgun.org ~all

Mailgun’s SPF record is published at mailgun.org.

Amazon SES

v=spf1 include:amazonses.com ~all

Amazon SES publishes its sending IPs at amazonses.com.

Multiple Services

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

This record authorizes Google Workspace, SendGrid, and a custom mail server at 203.0.113.5. The -all hardfail rejects all other senders.

Custom Mail Server Only

v=spf1 ip4:203.0.113.5 ip4:203.0.113.6 -all

If you run your own mail servers and don’t use third-party services, list their IPs directly.

SPF for Google Workspace

Google Workspace requires you to add an SPF record that includes _spf.google.com. Google’s official SPF setup guide recommends:

v=spf1 include:_spf.google.com ~all

If you send email from other services (e.g., a CRM or marketing platform), add their include: mechanisms before the ~all:

v=spf1 include:_spf.google.com include:mailgun.org ~all

Google recommends using ~all (softfail) initially, then switching to -all (hardfail) once you’ve confirmed all legitimate senders are authorized.

Google Workspace SPF setup reference: https://support.google.com/a/answer/33786

SPF for Microsoft 365

Microsoft 365 requires you to include spf.protection.outlook.com in your SPF record:

v=spf1 include:spf.protection.outlook.com ~all

If you send email from other services, add their include: mechanisms:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

Microsoft also recommends starting with ~all and moving to -all after testing.

Microsoft 365 SPF setup reference: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-spf-configure

SPF for Common Email Services (SendGrid, Mailgun, Amazon SES)

Most third-party email services publish their sending IPs in an SPF record you can include in your own record.

Example combining Google Workspace + SendGrid + custom server:

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

The 10-Lookup Limit

SPF has a strict limit: no more than 10 DNS lookups during evaluation. Exceeding this limit causes a permerror, which makes SPF evaluation fail entirely.

What Counts as a Lookup?

How Lookups Are Counted

Lookups are cumulative across all include: chains. For example:

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

• Lookup 1: _spf.google.com
• Lookup 2: Inside _spf.google.com, there’s include:_netblocks.google.com
• Lookup 3: Inside _netblocks.google.com, there’s include:_netblocks2.google.com
• Lookup 4: Inside _netblocks2.google.com, there’s include:_netblocks3.google.com
• Lookup 5: sendgrid.net
• Lookup 6: Inside sendgrid.net, there’s include:sendgrid.biz

This example uses 6 lookups. Adding just 4 more third-party services would push you over the limit.

How to Stay Under the Limit

1. Flatten includes: Replace include: with direct ip4:/ip6: entries where the service’s IP ranges are stable (our SPF flattener automates this)
2. Remove unused services: Audit your SPF record regularly and remove services you no longer use
3. Use subdomains: Send marketing email from mail.example.com with its own SPF record, separate from your main domain
4. Consolidate services: If possible, send all email through a single provider to reduce include: statements

Example of flattening:

Before (uses 2 lookups):

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

After (uses 1 lookup):

v=spf1 include:_spf.google.com ip4:167.89.0.0/17 ip4:168.245.0.0/16 -all

In this example, SendGrid’s IP ranges are replaced with direct ip4: entries, saving one lookup. However, this requires manually updating the record if SendGrid changes its IP ranges.

SPF Macros

SPF macros allow dynamic substitution of values in SPF records. They’re rarely used in practice but can be helpful for advanced configurations.

Example using exists: with a macro to check a dynamic blocklist:

v=spf1 exists:%{i}.spamhaus.org -all

If the sender’s IP is 203.0.113.5, this expands to exists:203.0.113.5.spamhaus.org. If that domain exists, the mechanism matches.

Macros are rarely needed for standard SPF configurations.

SPF Alignment and DMARC

SPF alone doesn’t prevent spoofing because it only checks the envelope sender (MAIL FROM), not the visible From: header that users see. Attackers can spoof the From: header while using their own domain in the envelope.

DMARC solves this by requiring SPF alignment: the domain in the MAIL FROM address must match the domain in the From: header.

Relaxed vs Strict Alignment

• Relaxed alignment (default): The organizational domain must match. For example, mail.example.com aligns with example.com.
• Strict alignment: The domains must match exactly. mail.example.com does not align with example.com.

DMARC uses relaxed alignment by default (aspf=r). You can enforce strict alignment with aspf=s in your DMARC record.

v=DMARC1; p=quarantine; aspf=s; rua=mailto:[email protected]

SPF vs DKIM

SPF and DKIM are complementary email authentication protocols. Both are recommended for comprehensive protection.

SPF is simpler to set up but breaks when email is forwarded (because the forwarding server’s IP won’t match your SPF record). DKIM requires key pair generation and signing configuration but survives forwarding because the signature travels with the message.

Use both. SPF catches spoofing from unauthorized IPs, and DKIM verifies message integrity and survives forwarding.

Common SPF Failures and How to Fix Them

Use our SPF record checker to validate your record and catch these issues before they affect delivery. For failures that cascade into DMARC problems, see our DMARC failure troubleshooting guide.

PermError (Permanent Error)

Cause: You exceeded the 10-lookup limit, have multiple SPF records, or have a syntax error.

Fix: Flatten your SPF record to reduce lookups, ensure you have exactly one SPF TXT record, and validate your syntax.

TempError (Temporary Error)

Cause: A DNS lookup failed during SPF evaluation (network issue, DNS server down).

Fix: This is usually temporary. Ensure your DNS provider is reliable.

None

Cause: No SPF record was found for your domain.

Fix: Publish an SPF record as a DNS TXT record at your domain.

Neutral

Cause: Your SPF record ends with ?all (neutral).

Fix: Replace ?all with ~all (softfail) or -all (hardfail) for stronger protection.

Softfail

Cause: The sending IP didn’t match any mechanism, and your SPF record ends with ~all.

Meaning: The receiver should accept the email but mark it as suspicious. This is normal during testing.

Fix: Once you’ve verified all legitimate senders are authorized, change ~all to -all.

Fail (Hardfail)

Cause: The sending IP didn’t match any mechanism, and your SPF record ends with -all.

Meaning: The receiver should reject the email.

Fix: Add the legitimate sender’s IP or include: mechanism to your SPF record.

Multiple SPF Records

Cause: You have more than one SPF TXT record at your domain.

Fix: Combine all mechanisms into a single SPF record. Only one SPF record is allowed per domain.

Missing Terminating Mechanism

Cause: Your SPF record doesn’t end with all (e.g., v=spf1 include:_spf.google.com).

Fix: Add ~all or -all at the end. Without a terminating mechanism, SPF defaults to neutral, which provides weak protection.

Frequently Asked Questions

What is an SPF record?

An SPF record is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. Receivers use it to verify that incoming email claiming to be from your domain actually came from an approved server.

How do I create an SPF record?

Create an SPF record by adding a DNS TXT record to your domain with the syntax: v=spf1 [mechanisms] [qualifier]. Include your sending mail servers using ip4:/ip6: for specific IPs or include: for third-party services. Always end with -all or ~all. Use a generator tool or your DNS provider’s interface to publish the record.

What is the SPF 10-lookup limit?

SPF has a strict limit of 10 DNS lookups during evaluation. Each include:, a, mx, and redirect mechanism counts as a lookup. Exceeding this limit causes a PermError, which makes SPF evaluation fail completely. Flatten your SPF record by replacing include: statements with direct ip4:/ip6: entries to stay under the limit.

What is the difference between SPF and DKIM?

SPF checks the sending server’s IP address against a DNS record, while DKIM uses cryptographic signatures to verify the message content and sender. SPF validates the MAIL FROM envelope address; DKIM validates the message body and headers. Both are recommended for comprehensive email authentication.

Why is my SPF record failing?

Common SPF failures include: exceeding the 10-lookup limit (PermError), having multiple SPF records (only one is allowed), forgetting the terminating -all or ~all mechanism, or sending from IPs not listed in the record. Check your SPF syntax and ensure all legitimate sending sources are authorized.

Can I have multiple SPF records?

No. A domain must have exactly one SPF TXT record. If multiple SPF records exist, receivers will treat SPF evaluation as failed (PermError). If you need to authorize multiple services, combine them into a single SPF record using include: mechanisms or direct IP entries.

What does “spf softfail” mean?

A softfail occurs when an SPF record ends with ~all (tilde all). It means the sending server is not authorized, but the receiver should accept the email anyway and mark it as suspicious. Softfail is used during SPF testing or when you’re unsure if all legitimate senders are listed. Use -all (hardfail) for stricter enforcement.

Does SPF alone prevent spoofing?

No. SPF alone does not prevent spoofing because it only checks the envelope sender (MAIL FROM), not the visible From: header that users see. Attackers can spoof the From: header while using their own domain in the envelope. DMARC is required to enforce alignment between the two and prevent header-based spoofing.

Related Protocols

• DMARC — Uses SPF results (with alignment) to enforce email policy and prevent spoofing
• DKIM — Complements SPF by signing message content and surviving forwarding
• ARC — Preserves SPF results through forwarding chains, solving SPF’s forwarding problem