SPF (Sender Policy Framework): What It Is and How It Works

Email spoofing is one of the oldest tricks in the attacker’s playbook, and it still works because too many domains make it easy. Sender Policy Framework (SPF) is the first line of defense. It is a foundational email authentication protocol that tells receiving mail servers which IP addresses are actually authorized to send email on your behalf.

This guide covers what SPF is, how the SPF protocol works, how to set it up correctly, and where its limits lie.

What Is SPF (Sender Policy Framework)?

Sender Policy Framework (SPF) is an email authentication protocol designed to prevent email spoofing, one of the most common techniques used in phishing attacks and spam campaigns.

It works by allowing domain owners to publish a list of authorized mail servers in their DNS, so receiving servers can verify whether an incoming message genuinely comes from an approved source.

SPF is a foundational part of email authentication because it gives receiving systems a clear, authoritative answer to a simple question: is this server allowed to send mail for this domain?

Where SPF fits in the broader email security picture

SPF does not work in isolation. It is one of three core email authentication protocols, alongside DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting, and Conformance (DMARC). Together, these protocols form a complete defense against email fraud.

SPF is also a required component for setting up DMARC. Without a valid SPF record in place, DMARC cannot function correctly.

Suggested read: SPF, DKIM, And DMARC: How They Work Together

How the SPF Protocol Works

SPF operates entirely through DNS. When an email is sent, the receiving mail server runs a series of checks to determine whether the message should be trusted. Here is how that process works from start to finish.

The SPF verification process

1. An email is sent from a server, carrying the sender’s domain in the Return-Path address
2. The receiving server identifies the sender’s domain from that Return-Path address
3. The receiving server performs an SPF record lookup in the domain’s DNS to find the published SPF record
4. The sending server’s IP address is compared against the list of authorized IP addresses in the SPF record
5. If there is a match, the email passes SPF authentication. If there is no match, the email may be flagged as suspicious or rejected depending on the domain’s policy

SPF authentication outcomes

It is important to note that SPF only verifies the sending server’s IP address. It does not authenticate the actual identity of the sender or the content of the message. That is where DKIM and DMARC fill the gaps.

What Does an SPF Record Look Like?

An SPF record is a DNS TXT record published in your domain’s DNS settings. It follows a specific syntax of mechanisms and qualifiers that define which servers are authorized to send email for your domain.

Basic SPF record structure

v=spf1 ip4:192.0.2.0/24 include:mailprovider.com -all

SPF records for non-sending domains

For domains that never send email, a restrictive SPF record should still be published to prevent them from being spoofed:

v=spf1 -all

This tells receiving servers to reject all email claiming to come from that domain.

The 10 DNS lookup limit

SPF has a limit of 10 DNS lookups per record evaluation. Each include:, a:, mx:, and redirect: mechanism triggers a lookup.

Exceeding this limit causes a PermError, which can cause legitimate emails to fail SPF authentication silently. This is one of the most common and overlooked SPF configuration problems, particularly for organizations with complex email environments.

How to Create and Publish an SPF Record

Creating and publishing an SPF record is one of the most important steps in securing your domain’s email.

Done correctly, it tells every receiving mail server exactly which sources are authorized to send on your behalf. Done incorrectly, it can silently break authentication for your own legitimate emails. Here is how to get it right.

Step 1: Audit all your email sending sources

Before writing a single line of your SPF record, identify every service and system that sends email from your domain. This is the step most organizations rush, and it is the most common reason SPF records fail after publishing.

Your audit should cover:

• Your primary mail server
• Email marketing platforms
• CRM and sales tools
• Helpdesk and support software
• Billing and transactional email services
• Any third-party vendors sending on your behalf

For each source, collect either the specific sending IP addresses or the SPF include string provided by that service.

Step 2: Draft your SPF record

Combine all authorized senders into a single DNS TXT record using correct SPF syntax. A basic example looks like this:

v=spf1 ip4:192.0.2.1 include:sendingservice.com include:marketingplatform.com -all

Key rules to follow when drafting:

Step 3: Publish the record in your DNS

Once your record is drafted, log in to your DNS provider and add it as a TXT record at your root domain.

The record should be added at @ or yourdomain.com, not at a subdomain, unless you are specifically creating a separate record for a subdomain.

If you use separate subdomains for different sending services, each subdomain needs its own SPF record. This is also a useful technique for staying within the 10-lookup limit when managing multiple third-party senders.

Step 4: Test your record after publishing

Publishing your record is not the final step. Always verify it after publishing to confirm that:

• The record is correctly formatted and contains no syntax errors
• All authorized IP addresses and include strings are present
• The DNS lookup limit has not been exceeded
• No duplicate SPF records exist on the same domain

Use PowerDMARC’s SPF lookup tool to run this check immediately after publishing, and again whenever you make changes.

Step 5: Keep your record up to date

An SPF record is not a set-and-forget configuration.

Every time you add a new sending platform, change an email service provider, or decommission an old one, your SPF email record needs to be updated. An outdated record that references old IP addresses or missing services is one of the most common causes of legitimate emails failing SPF authentication.

Set a regular schedule to review your SPF record, particularly after any changes to your email infrastructure.

SPF and Email Deliverability

One of the most direct benefits of implementing SPF is improved email deliverability. Here is how SPF affects the journey your emails take from send to inbox.

How SPF improves deliverability

• Receiving mail servers and mailbox providers use SPF as a trust signal when deciding whether to deliver, filter, or reject incoming mail
• A valid SPF record reduces the chances of legitimate emails being marked as spam
• Consistent SPF authentication builds domain reputation over time, making it less likely that your emails are blocked or diverted to junk folders
• Implementing SPF signals a commitment to email security to ISPs, contributing positively to sender reputation

How SPF can hurt deliverability when misconfigured

Maintaining an accurate and up-to-date SPF record is vital for protecting your domain reputation and ensuring consistent email deliverability.

The Limitations of SPF

SPF is a foundational email authentication method, but it has well-documented limitations that every domain owner should understand. Relying on SPF alone leaves significant gaps in your email security posture.

What SPF cannot do

SPF is the start, not the finish

SPF alone cannot protect the From address visible to users, cannot survive forwarding, and cannot authenticate message content.

For full protection against domain spoofing and phishing attacks, SPF must be combined with DKIM and DMARC. DMARC specifically closes the gap SPF leaves open by requiring that the From address align with the authenticated sender information.

Protect Your Domain With SPF and PowerDMARC

SPF is where email authentication starts, but it is only one piece of the puzzle.

Getting your SPF record right, keeping it accurate as your sending infrastructure evolves, and pairing it with DKIM and DMARC is what actually protects your domain from spoofing, phishing, and deliverability problems.

A client shares:

“PowerDMARC made SPF management effortless for our IT team. Our email deliverability and security improved overnight.” – CISO, Financial Institution

PowerDMARC makes that entire process manageable. From generating and validating your SPF record to monitoring authentication outcomes across all your sending domains and pushing toward full DMARC enforcement, PowerDMARC gives you the visibility and control to do it correctly the first time and maintain it long term.

Get started with PowerDMARC today!

FAQs

1. What is the SPF sender policy framework?

The SPF (Sender Policy Framework) is an email authentication protocol that allows domain owners to specify which mail servers are authorized to send emails on behalf of their domain. It works by publishing a DNS TXT record that lists approved sending sources, helping receiving servers verify email authenticity and prevent spoofing.

2. How does SPF differ from DKIM and DMARC?

SPF validates the sending server’s IP address, DKIM uses cryptographic signatures to verify message integrity, and DMARC provides policy enforcement and reporting. SPF checks the envelope sender, DKIM validates the message content hasn’t been altered, and DMARC tells receiving servers what to do when SPF or DKIM fails. All three work together for comprehensive email authentication.

3. How do I use Sender Policy Framework?

Identify every service sending email from your domain, collect their authorized IP addresses, and publish a single DNS TXT record starting with v=spf1. Test it after publishing and keep it updated as your sending infrastructure changes.

4. What are some SPF email record limitations?

SPF only verifies the sending server, not the sender’s identity or message content. It breaks on forwarded emails and has a strict 10 DNS lookup limit that can silently break authentication if exceeded.

5. Is SPF the same as DKIM?

No. SPF verifies the sending server’s IP address. DKIM uses a cryptographic signature to verify that message content has not been altered in transit.

6. Why would an email fail SPF?

The most common causes are an unauthorized sending server, an outdated SPF record missing a legitimate sender, syntax errors in the record, or exceeding the 10 DNS lookup limit.

• About
• Latest Posts

Maitham Al Lawati

Cybersecurity Expert, CEO at PowerDMARC

Maitham is a tech entrepreneur, cybersecurity expert, CEO and Founder of PowerDMARC with 15+ years of industry experience. Maitham holds a Global MBA from the University of Manchester and various professional certifications including CISSP, CISM, CRISC, and ISC2 CCSP.

Latest posts by Maitham Al Lawati (see all)

• Email Phishing and DMARC Statistics: 2026 Email Security Trends - January 6, 2026
• How to Fix “No SPF record found” in 2026 - January 3, 2026
• SPF Permerror: How to Fix Too Many DNS Lookups - December 24, 2025