SPF Record: What It Is, How It Works, and How to Set One Up

What is SPF?

SPF (Sender Policy Framework) is one of the three core email authentication protocols, alongside DKIM and DMARC, that prevents unauthorized servers from sending email using your domain. An SPF record is a DNS TXT record that lists every IP address and mail server authorized to send on your behalf. Without one, any server on the internet can impersonate your domain, and receiving servers have no way to tell the difference.

What This Guide Covers

Jump to any section, or read straight through for the full picture:

How SPF Works

When a receiving mail server gets an email, it extracts the domain from the Return-Path (envelope sender), queries DNS for a TXT record starting with v=spf1, and checks whether the sending server's IP matches the authorized list. If it matches, SPF passes. If not, the result is a fail, softfail, or error, and what happens next depends on your DMARC policy.

SPF validates the Return-Path domain (the technical envelope address), not the visible "From:" address. This means SPF alone can't prevent display-name spoofing. That's why DMARC alignment exists to bridge this gap.

SPF Record Syntax: Mechanisms and Qualifiers

An SPF record starts with v=spf1, lists authorized senders using mechanisms like ip4:, ip6:, and include:, and ends with a qualifier that tells receivers what to do with unlisted senders. Here's an example:

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

-all and ~all signal different levels of enforcement in SPF. -all (hard fail) tells receiving servers that only listed senders are authorized and everything else should be rejected. ~all (softfail) is more lenient and flags all unauthorized senders as suspicious, but still accepts them. Use -all once your senders are fully audited.

Each include:, a, mx, redirect=, and exists: mechanism counts toward the 10 DNS lookup limit. Exceeding it triggers a PermError that breaks authentication entirely. The ptr: mechanism is deprecated, avoid using.

How to Create an SPF Record

Start by listing every service that sends email from your domain, like:

• Your primary mail server
• Google Workspace or Microsoft 365
• Marketing tools (Mailchimp, HubSpot, Klaviyo)
• Transactional services (SendGrid, Mailgun, Amazon SES), and any CRM or helpdesk that sends on your behalf.

Each provider publishes an include: value in their documentation. Build a single record combining all senders (you can only have one SPF record per domain), publish it as a TXT record in your DNS provider, and validate it with an SPF checker. DNS propagation typically takes a few hours but can take up to 48.

Provider-specific setup guides

How to Check and Validate Your SPF Record

Use an SPF checker tool to validate that your record is syntactically correct, within the 10-lookup limit, and resolving to the right IP addresses. PowerDMARC's SPF Lookup tool performs all of these checks instantly.

What a good SPF check should verify:

• Record starts with v=spf1
• Only one SPF record exists for the domain
• Total DNS lookups are 10 or fewer
• No syntax errors or unresolvable include: domains
• The all qualifier is present and appropriate
• No deprecated mechanisms (e.g., ptr:)

Command-line check (Linux/Mac):

dig TXT yourdomain.com +short | grep "v=spf1"

Using PowerDMARC's SPF Lookup: Enter your domain at PowerDMARC SPF Checker for an instant diagnostic report showing lookup count, mechanism breakdown, and any errors.

Common SPF Errors and How to Fix Them

Most SPF failures come from configuration drift, not the protocol itself. Here are the errors we see most often and where to fix each one:

SPF and DMARC: Understanding Alignment

SPF can pass while DMARC still fails. This happens because SPF validates the Return-Path domain, but DMARC requires that domain to align with the visible "From:" address. When you send through a third-party service that uses their own Return-Path, SPF authenticates against their domain, not yours, and DMARC fails the alignment check.

The fix is to either configure a custom Return-Path on your domain with each provider, or rely on DKIM alignment instead (DKIM signatures survive forwarding and aren't tied to the sending IP). Set alignment mode with the aspf= tag in your DMARC record: aspf=r (relaxed, subdomains OK) or aspf=s (strict, exact match).

SPF vs. DKIM vs. DMARC: How They Work Together

These three protocols are complementary, not interchangeable. SPF verifies the sending server, while DKIM verifies message integrity with a cryptographic signature. DMARC ties both together, enforces a policy (none / quarantine / reject), and generates aggregate and forensic reports. An email passes DMARC if it passes either SPF alignment or DKIM alignment, you need both configured so one can compensate when the other breaks (e.g., SPF fails on forwarded mail, but DKIM survives).

Hosted SPF: Solving the Scalability Problem

Every SaaS tool you add to your SPF record consumes DNS lookups. Once you hit the 10-lookup limit, the entire record breaks and all SPF checks return PermError. Manual SPF flattening (replacing includes with raw IPs) works short-term but goes stale when vendors rotate their IP ranges, and they do, without warning.

PowerDMARC's automatic SPF flattening solves this by dynamically resolving include: chains into optimized records, monitoring vendor IP changes, and keeping your record under the lookup limit without manual DNS edits. For organizations using SPF macros or managing SPF across multiple domains and subdomains, hosted SPF eliminates the maintenance overhead entirely.

SPF Best Practices Checklist