Back to Learning CenterEmail Authentication

What is SPF? Sender Policy Framework Explained

By Samuel ChenardMay 12, 2025Updated August 3, 20269 min read
What is SPF? Sender Policy Framework Explained

Sender Policy Framework (SPF) is an email authentication protocol, defined in RFC 7208, that lets a domain owner declare which mail servers are allowed to send on the domain's behalf. It helps combat spoofing and phishing by giving receiving mail servers a way to verify that an incoming message came from an authorized source. SPF is a foundational component of email security, and it works best alongside DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) to build a layered defense against email fraud. You can inspect any domain's policy with the free SPF checker.

How Does SPF Work?

SPF operates through a straightforward process that hinges on DNS (Domain Name System) records:

Three-step flow showing how SPF works: publish a DNS record, the receiver checks the sender's IP against it, then the email passes or fails. SPF verification hinges on a TXT record published in your DNS.
  • Publish an SPF record: The domain owner creates a single TXT record in their DNS, listing the IP addresses or servers authorized to send email for the domain. A record might look like v=spf1 ip4:192.0.2.0 include:_spf.example.com -all. This tells receivers which servers are legitimate and what to do with everything else.
  • Verification by receivers: When a message arrives, the receiving server reads the domain from the envelope sender — the RFC5321.MailFrom address, also called the Return-Path, not the visible From header a user sees — and looks up that domain's SPF record. It then compares the connecting server's IP address against the authorized list.
  • Pass or fail: If the IP matches an authorized source, the message passes SPF. If not, the receiver applies the qualifier attached to the matching mechanism (for example, treat as spam or reject), a decision usually reinforced by the domain's DMARC policy.
Each mechanism in the record carries a qualifier that sets how strictly to enforce it: + (pass, the default), - (fail), ~ (soft fail), or ? (neutral). The all mechanism at the end catches everything not matched above, so -all is the strict setting that tells receivers to reject unauthorized senders.

Why SPF Matters

SPF brings several critical benefits to domain owners and email ecosystems:

  • Prevents Spoofing: By restricting who can send emails from your domain, SPF stops attackers from forging your domain in phishing or spam campaigns.
  • Enhances Email Security: It provides a clear mechanism to verify legitimate senders, reducing the risk of malicious emails reaching inboxes.
  • Improves Deliverability: Properly configured SPF signals to email providers that your domain is trustworthy, increasing the chances your emails land in the inbox rather than the spam folder.
  • Supports Broader Authentication: SPF is a key pillar of DMARC, which combines it with DKIM to enforce policies and provide reporting, amplifying its impact.

SPF record syntax explained

An SPF record is a single line of DNS text that always begins with the version tag v=spf1. After that come mechanisms — the building blocks that describe authorized senders — each optionally prefixed with a qualifier. Receivers evaluate the mechanisms left to right and stop at the first match.

The core mechanisms are:

  • ip4 and ip6: authorize a specific IPv4 or IPv6 address or CIDR range, for example ip4:192.0.2.0/24. These are the only mechanisms that cost no DNS lookup.
  • a: authorizes the IP addresses in the domain's own A/AAAA records.
  • mx: authorizes the servers listed in the domain's MX records — handy when the mail servers that receive your mail also send it.
  • include: pulls in another domain's SPF record, which is how you authorize a third-party sender such as a marketing platform or help desk that publishes include:_spf.vendor.com.
  • all: the catch-all at the end of the record that matches every sender not already matched.
Two modifiers can also appear: redirect, which points to another domain's policy entirely, and exp, which supplies an explanation string for failures. Every mechanism except ip4, ip6, and all triggers a DNS query and counts toward the lookup budget.

Qualifiers set the verdict for a matched mechanism. + means pass and is the implicit default, so a bare include is a passing rule. - means fail, ~ means soft fail, and ? means neutral. In practice the qualifier that matters most is the one on all, because it decides the fate of everyone your record does not explicitly authorize. Generate a valid record for your own senders with the SPF checker rather than editing DNS by hand.

Common SPF problems

SPF is simple to describe but easy to misconfigure. A few failure modes account for most broken records:

  • Too many DNS lookups: This is the most common failure. If evaluating your record requires more than 10 DNS-querying mechanisms, receivers return a PermError and stop treating the record as valid — legitimate mail can then fail authentication. A related, quieter limit caps void lookups (queries that return NXDOMAIN or no answer) at 2, which also produces a PermError. The fix is to consolidate or "flatten" nested includes so the total stays under the cap.
  • Multiple SPF records: A domain may publish only one v=spf1 TXT record. If a DNS review turns up two, receivers treat the result as a PermError and may ignore both. Merge every authorized source into a single record — see how many SPF records a domain can have for how to consolidate.
  • SPF breaks on forwarding: When a message is forwarded, the forwarding server usually keeps the original Return-Path but relays from its own IP, which is not in your record, so SPF fails at the next hop. This is inherent to how SPF works, and it is the main reason to also deploy DKIM — a DKIM signature survives forwarding, so a message can still pass DMARC through DKIM even when SPF breaks. Confirm your DKIM setup with the DKIM checker.

Things to Keep in Mind

While SPF is a powerful tool, it requires careful setup and maintenance:

Checklist of four SPF maintenance points: cover all senders, respect the 10-lookup limit, pair with DKIM and DMARC, and keep the record updated. A missed sender or stale record can cause valid emails to fail authentication.
  • Comprehensive Records: Ensure all legitimate email sources—like your mail servers, marketing platforms, or third-party vendors—are included in the SPF record. Missing one can cause valid emails to fail authentication.
  • Lookup Limits: RFC 7208 caps an SPF check at 10 DNS-querying mechanisms — include, a, mx, ptr, exists, and the redirect modifier. This is a limit on lookups, not on the character length of the record. Adding one more include than the budget allows breaks the whole record with a PermError. Use includes sparingly or flatten the record to stay under the cap.
  • Not Foolproof Alone: SPF only checks the sending server’s IP, not the email’s content or integrity, and it authenticates the Return-Path rather than the From address a user reads. Pair it with DKIM (for signatures) and DMARC (for policy enforcement and alignment) for full protection.
  • Regular Updates: If you change email providers or add new services, update your SPF record promptly to avoid delivery issues.
When you need to inspect the published mechanisms and understand the returned result, follow the SPF checking tool workflow. A public checker reports what a receiver sees, but it cannot prove alignment on its own — confirm that with a full email security score before you change DNS.

If a DNS review shows two v=spf1 values at the same name, read how many SPF records a domain can have before adding another sender. It explains why receivers return permerror and how to consolidate the authorized sources into one policy.

If a marketing team uses Constant Contact, review SPF and Constant Contact before adding an unnecessary include, then use its DKIM and DMARC self-authentication path for that sending service.

Wrapping Up

SPF is a cornerstone of email security, empowering domain owners to control who can send emails on their behalf. By publishing a clear policy in DNS, it helps block spoofed emails, protects your brand, and boosts trust with recipients. When combined with DKIM and DMARC, SPF forms a vital part of a comprehensive email authentication strategy, making it essential for anyone serious about secure communication. Ready to see where your domain stands? Run the free email security score and Get started with automated monitoring.

Questions readers ask

Frequently asked questions

Fix SPF limits without rebuilding your record

Start in Palisade.

Get started
Palisade domain settings with Hosted SPF enabled

Keep going with AI

Ask AI how this applies to you

Take this guide to your assistant — each question opens pre-filled, with a link back to this page so it can read the details.

  • How Does SPF Work?
  • How does this apply to my domain?
  • What should I do about it, step by step?

Share this article

Samuel Chenard

Written by

Samuel Chenard

CEO & Co-Founder, Palisade

Samuel Chenard is the CEO and co-founder of Palisade, AI-first DMARC software for IT teams and MSPs, from one domain to thousands.

More from Samuel

Related articles