What is SPF? The Sender Policy Framework Explained

You have probably seen SPF mentioned in email headers, DNS configurations, or security audits. Maybe your mail provider told you to set one up. Maybe a phishing test at your company made someone wonder why fake emails got through so easily.

SPF is one of those things that sounds complicated until someone explains it properly. Once you understand what it actually does and how it works, it clicks immediately. This guide will get you there.

What is SPF?

SPF stands for Sender Policy Framework. It is a DNS-based email authentication protocol that lets a domain owner publish a list of mail servers that are authorised to send email on behalf of that domain.

When an email arrives claiming to be from yourcompany.com, the receiving mail server can look up your SPF record in DNS and check whether the server that actually sent the message is on your approved list. If it is, the email passes SPF. If it is not, the email fails.

That is the entire concept. Everything else in this guide is just filling in the details.

SPF was designed to address a fundamental weakness in email: the Simple Mail Transfer Protocol (SMTP), which is the standard used to send email, has no built-in way to verify who is actually sending a message. Anyone with a mail server can claim to be sending from any domain they want. SPF was one of the first practical attempts to fix this, and it was first published as a standard in RFC 4408 back in 2006.

Why Does SPF Exist? The Problem it Was Built to Solve

To understand SPF properly, you need to understand just how open the original email system is.

When email was invented in the early days of the internet, the community of people using it was small and largely trusted. Nobody designed SMTP with attackers in mind. The protocol simply accepts whatever the sending server claims about where the message is coming from.

This means that without any additional controls, a mail server anywhere in the world can send an email that claims to be from ceo@yourcompany.com, and nothing in the base protocol stops it. The receiving server has no way to know the email is fake just by looking at it.

This is the root of email spoofing. Attackers exploit this to:

• Send phishing emails that appear to come from legitimate organisations (banks, government agencies, well-known brands)
• Impersonate executives inside a company to authorise fraudulent payments
• Spoof supplier domains to redirect invoice payments
• Conduct mass spam campaigns while hiding behind legitimate domain names

SPF gives receiving servers a way to verify the sending server. Instead of just trusting whatever the email claims, the receiving server can check: "Is this server actually authorised to send mail for this domain?"

How SPF Works: Step by Step

Here is exactly what happens when an SPF check runs.

Step 1: You publish an SPF record in DNS

As the domain owner, you add a TXT record to your domain's DNS that lists all the servers and IP addresses that are allowed to send email for your domain. This might include your primary mail server, your email marketing platform, your CRM, your HR system and so on.

Step 2: Someone sends an email claiming to be from your domain

This could be you sending a legitimate email, or it could be an attacker trying to impersonate your domain.

Step 3: The receiving mail server looks up your SPF record

When the email arrives, the receiving server extracts the domain from the Return-Path address (more on this in a moment) and queries DNS for that domain's SPF record.

Step 4: The receiving server checks whether the sending IP is on your approved list

The receiving server compares the IP address of the server that actually sent the email against the list in your SPF record.

Step 5: The check passes or fails

If the sending server's IP is on your list, SPF passes. If it is not, SPF fails. What happens next depends on your DMARC policy, but the receiving server now has reliable information about whether this email came from an authorised source.

What Does an SPF Record Actually Look Like?

An SPF record is a TXT record published in DNS. Here is a real-world example:

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

Breaking this down piece by piece:

v=spf1
This declares that the record is an SPF record, version 1. All SPF records start with this.

include:_spf.google.com
This tells receiving servers to also check Google's SPF record and treat any server listed there as authorised. If you send through Google Workspace, this is how you authorise Google's mail servers.

include:sendgrid.net
Same idea, but for SendGrid. If you send marketing emails through SendGrid, this authorises their servers to send on your behalf.

ip4:203.0.113.50
This directly authorises a specific IPv4 address. If you have an on-premise mail server or a dedicated sending IP, you add it this way.

-all
This is the most important part. The -all mechanism says: anything not listed above should be rejected. It is a hard fail. If an email comes from a server that does not match any of the earlier mechanisms, the receiving server should treat it as unauthorised.

The alternative is ~all, which is a soft fail. It says: unauthorised servers should be marked as suspicious but not necessarily rejected. Many organisations use ~all while they are setting things up, but -all is the more secure option once you are confident your configuration is complete.

The Different SPF Mechanisms

SPF records support several different mechanisms for defining what is authorised. Understanding these helps when you are reading or writing SPF records.

Each mechanism can be prefixed with a qualifier:

In practice, most SPF records use include statements, a few ip4 entries, and end with either -all or ~all.

The Critical Blind Spot: What SPF Actually Checks

This is the part that trips people up, including experienced engineers. It is the most important thing to understand about SPF.

SPF does not check the From address you see in your email client.

Read that again, because it matters enormously.

SPF checks the Return-Path address, which is also called the envelope sender or the MAIL FROM address. This is a technical field used during the SMTP transaction. It is different from the visible "From" header that appears in your inbox.

Think of it like sending a physical letter. The visible From address on the letter inside the envelope is what the recipient reads. The Return-Path is like the return address printed on the outside of the envelope. The postman (the receiving mail server) only checks the envelope. What is written on the letter inside is a separate matter entirely.

An attacker can exploit this gap. They can send an email where:

• The Return-Path is attacker@legitimatecompany.com (a real domain with valid SPF)
• The visible From header shows ceo@yourcompany.com

SPF would check the Return-Path domain, find a valid SPF record, and pass. Your recipient sees the CEO's address in the From field. The attack succeeds despite SPF passing.

This is not a bug in SPF. It is just what SPF was designed to do: verify the envelope sender. The alignment between the envelope sender and the visible From address is what DMARC handles. This is why SPF alone is not enough, and why the three protocols need to work together.

Common SPF Mistakes (And How to Avoid Them)

If you manage DNS records for any organisation, you will almost certainly encounter these.

Mistake 1: Forgetting third-party sending services

Every service that sends email on your behalf needs to be in your SPF record. Marketing platforms. CRM systems. HR software. Helpdesk tools. Support ticketing systems. If you add a new SaaS tool that sends email from your domain and you do not update your SPF record, those emails will fail SPF and may end up in spam or be rejected entirely.

Mistake 2: Hitting the DNS lookup limit

SPF has a hard limit of 10 DNS lookups per check. Every include statement, every a or mx mechanism triggers a DNS lookup. If your SPF record causes more than 10 lookups, the check automatically fails.

This is a surprisingly common problem for organisations that use many third-party email services. The fix involves flattening your SPF record (replacing include statements with direct IP addresses) or using a macro-based SPF service.

Mistake 3: Multiple SPF records for the same domain

A domain can only have one SPF record. If you publish two TXT records that both start with v=spf1, receiving servers will not know which one to use. The SPF check will fail. This often happens when organisations add a new record without realising one already exists.

Mistake 4: Using ?all or leaving off all entirely

Ending your SPF record with ?all (neutral) or not including an all mechanism at all provides no meaningful protection. It tells receiving servers: "We have no opinion on whether unauthorised servers should be allowed." Always end with -all or at minimum ~all.

Mistake 5: Not including all your IP ranges

If your organisation has multiple mail servers across different IP ranges, make sure all of them are covered. This includes backup mail servers, transactional email servers, and servers in different regions or data centres.

Mistake 6: Setting -all too early

Going straight to a hard fail without testing first is risky. If you have missed any legitimate sending sources, those emails will be rejected. Start with ~all, monitor your DMARC reports to identify all your sending sources, and then switch to -all when you are confident everything is covered.

How to Check Your SPF Record Right Now

Before making any changes, it is worth knowing what you are starting with. You can check your SPF record in under two minutes.

Option 1: MXToolbox
Go to mxtoolbox.com/spf.aspx, enter your domain name, and run the lookup. It will show you your current SPF record and flag any obvious issues.

Option 2: dig (command line)
If you are comfortable with the command line:

1dig TXT yourdomain.com

Look for the line starting with v=spf1 in the output.

Option 3: nslookup (Windows)

1nslookup -type=TXT yourdomain.com

Same result, different tool.

What you are looking for:

• A single TXT record starting with v=spf1
• All your legitimate sending services covered
• The record ending with -all or ~all
• No obvious omissions (check your email tools list against what is in the record)

If you see "No SPF record found", your domain has no SPF protection whatsoever. Any server in the world can send email claiming to be from your domain and there is nothing in place to flag it.

How to Write a Basic SPF Record

If you are setting up SPF for the first time, here is a practical starting point.

Step 1: List every service that sends email from your domain

Go through your tools and identify anything that sends email using your domain name. Common ones include:

• Google Workspace or Microsoft 365 (your primary mail)
• Mailchimp, HubSpot, or similar marketing platforms
• Salesforce or other CRM tools
• Zendesk, Freshdesk, or support platforms
• Payroll or HR systems
• Any custom applications that send transactional email

Step 2: Find the SPF include string for each service

Each email provider publishes their own SPF include string. Google's is include:_spf.google.com. Microsoft 365's is include:spf.protection.outlook.com. Most providers document this in their setup guides.

Step 3: Assemble the record

1v=spf1 include:[provider1] include:[provider2] ip4:[your-server-ip] ~all

Step 4: Publish it as a TXT record in DNS

Log into your DNS provider (GoDaddy, Cloudflare, Route53, etc.) and add the record. The hostname field should be @ or your domain name depending on the provider. The type is TXT.

Step 5: Start with ~all, then move to -all

Once you have monitored your DMARC reports for a few weeks and confirmed all legitimate mail is passing, switch to -all for the strongest protection.

SPF and Email Forwarding: A Known Problem

Email forwarding breaks SPF in a way that is worth understanding, especially if your organisation uses email forwarding rules or redirect services.

Here is what happens. User A at company-a.com receives an email originally sent from sender@example.com. User A has set up a forwarding rule that redirects all their mail to user-a@company-b.com.

When the forwarded email arrives at company-b.com, the Return-Path still shows the original sender's domain example.com. But the server that actually delivered the email to company-b.com is the forwarding server at company-a.com, not a server authorised by example.com. SPF fails.

This is not a flaw in your SPF configuration. It is just how forwarding works under the hood. DKIM handles this scenario much better because DKIM's cryptographic signature travels with the email through forwarding. This is one of the reasons DKIM and DMARC are necessary alongside SPF rather than replacing it.

Reading SPF Results in Email Headers

If you want to see SPF in action, you can look at the headers of any email you receive. Every major email client lets you view full headers.

In Gmail, click the three-dot menu on an email and select "Show original". You will see something like this:

1Received-SPF: pass (google.com: domain of sender@example.com designates 
2203.0.113.45 as permitted sender) client-ip=203.0.113.45;

Or a failure:

1Received-SPF: fail (google.com: domain of sender@example.com does not 
2designate 198.51.100.22 as permitted sender) client-ip=198.51.100.22;

The key field is Authentication-Results, which will show you SPF, DKIM, and DMARC results together:

1Authentication-Results: mx.google.com;
2   spf=pass (google.com: domain of sender@example.com designates 
3   203.0.113.45 as permitted sender) smtp.mailfrom=sender@example.com;
4   dkim=pass header.i=@example.com;
5   dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Getting comfortable reading these headers is a genuinely useful skill if you work in IT or security. It tells you immediately whether an email you are suspicious about passed or failed authentication.

What SPF Does Not Protect Against

Being clear about SPF's limitations is just as important as understanding what it does. Here is where SPF falls short.

Display-name spoofing
An attacker can set the visible "From" name to anything, for example "PayPal Security" while sending from a completely unrelated domain. SPF has no visibility into the display name at all.

Cousin domain attacks
An attacker registers paypa1.com (with a number 1 instead of letter l) and sets up a valid SPF record for that domain. Every email they send will pass SPF perfectly. SPF only verifies the listed domain. It cannot know that paypa1.com is a lookalike of paypal.com.

Compromised legitimate accounts
If an attacker gains access to a legitimate email account on your domain, they send from a fully authenticated source. SPF passes. There is nothing for SPF to flag.

Malicious content inside authenticated emails
SPF says nothing about what is inside the email. A link to a malicious website inside an SPF-passing email is still a malicious link. Authentication and content inspection are separate problems requiring separate solutions.

From-header spoofing (without DMARC)
As covered earlier, SPF checks the Return-Path, not the visible From. Without DMARC enforcing alignment between the two, an attacker can pass SPF while still spoofing the From address your recipient sees.

Interview Questions on SPF

These are the questions that come up regularly in security analyst, email security, and infrastructure engineer interviews.

Q: What is the purpose of SPF and how does it work?
SPF lets domain owners publish a list of authorised sending servers in DNS. When an email arrives, the receiving server checks the Return-Path domain's SPF record and verifies whether the sending IP is on the approved list. If it is, SPF passes.

Q: What is the difference between SPF hard fail and soft fail?
A hard fail (-all) instructs receiving servers to reject emails that fail SPF. A soft fail (~all) instructs receiving servers to mark them as suspicious but still deliver them. Soft fail is useful during testing. Hard fail is the appropriate setting for a production environment once configuration is confirmed complete.

Q: What does SPF check? The From address or the Return-Path?
SPF checks the Return-Path address, also called the envelope sender or MAIL FROM address. This is different from the visible From header that recipients see in their email client. This distinction is one of SPF's most important limitations.

Q: What is the 10 DNS lookup limit in SPF and why does it matter?
The SPF specification limits the number of DNS lookups that can occur during an SPF check to 10. Each include, a, and mx mechanism triggers a lookup. If the limit is exceeded, the SPF check returns a PermerError result, which typically causes the check to fail. Organisations using many third-party email services can hit this limit without realising it.

Q: Why does email forwarding break SPF?
When an email is forwarded, the forwarding server sends the email on from its own IP address. SPF checks whether that IP is authorised by the original sender's domain, and since the forwarding server is not on that list, SPF fails. This is a structural limitation of SPF that DKIM does not share, because DKIM's signature travels intact through forwarding.

Q: Can SPF alone stop phishing?
No. SPF alone cannot prevent phishing because it does not check the visible From address, cannot detect lookalike domains, and says nothing about the content of the email including malicious links. SPF is one layer in a defence-in-depth approach that requires DKIM and DMARC at minimum, plus additional controls like link inspection and sandboxing.

Q: What happens if a domain has no SPF record?
The SPF check returns a None result. The receiving server has no information about which servers are authorised to send for that domain. Depending on the receiving server's configuration, this may cause emails to be treated with suspicion or delivered without any SPF validation at all.

Q: What is the difference between v=spf1 -all and v=spf1 ~all?
A record of v=spf1 -all with no other mechanisms authorises zero servers and hard-fails everything. It is used for domains that should never send email, for example parked domains. A record of v=spf1 ~all with no other mechanisms is similar but uses a soft fail, which means emails will be delivered but flagged.

Frequently Asked Questions

Do I need SPF if I already use Microsoft 365 or Google Workspace?

Yes. Microsoft 365 and Google Workspace automatically configure SPF for the onmicrosoft.com or googlemail.com subdomain they assign you. But your custom domain, the one your users actually email from, requires its own SPF record. Your provider's documentation will give you the exact include string to use.

Can I have two SPF records for the same domain?

No. A domain must have only one SPF record. If you have two TXT records starting with v=spf1, receiving servers will not know which one to use and the SPF check will fail. If you need to add a new sending service, edit your existing SPF record rather than creating a new one.

How long does it take for SPF changes to propagate?

DNS changes typically propagate within a few minutes to a few hours, though the theoretical maximum TTL can be longer. In practice, most SPF changes are visible across the internet within an hour. You can use a tool like MXToolbox to check whether your updated record is visible yet.

My emails are going to spam. Could SPF be the cause?

It could be a contributing factor. If your SPF record is missing, misconfigured, or has a hard fail and you are sending from an unlisted server, that can hurt your email deliverability. But spam filtering is influenced by many factors beyond SPF, including sending reputation, content, and DKIM and DMARC status. Check all three authentication protocols together rather than diagnosing SPF in isolation.

What is SPF flattening?

SPF flattening is the process of replacing include statements in your SPF record with the actual IP addresses they resolve to. This reduces the number of DNS lookups required during an SPF check, helping you stay under the 10-lookup limit. The downside is that you need to update your SPF record manually whenever your email provider changes their IP ranges. Some services automate this for you.

Is SPF enough on its own to protect my domain from spoofing?

No. SPF is the first layer. It verifies the envelope sender but not the visible From address your recipients see. Without DMARC enforcing alignment between the two, an attacker can still pass SPF while spoofing your visible From header. SPF, DKIM, and DMARC together form the complete authentication stack.

What does permerror mean in SPF results?

PermError means there is a permanent error with the SPF record itself, usually because it is syntactically incorrect or exceeds the 10 DNS lookup limit. Unlike a TempError (which is temporary, usually caused by a DNS timeout), a PermError will keep occurring until the SPF record is fixed. Many receiving servers treat PermError the same as a fail.

Summary

SPF is your domain's authorised sender list. It tells the world which mail servers are allowed to send email on your behalf, and it gives receiving servers a way to check. Setting it up correctly is not complicated, but the details matter: the lookup limit, the all qualifier, the difference between the Return-Path and the visible From address.

The most important thing to take away is this: SPF is layer one. It solves one specific problem, which is verifying the envelope sender. It does not solve the problem of tamper-proof message integrity, and it does not solve the problem of aligning the envelope sender with the visible From address. Those are DKIM and DMARC's jobs.

Set up SPF. Do it correctly. Then build on top of it.

SPF is layer one. Here is what DKIM adds on top: What is DKIM? How Email Signatures Prove Your Messages Are Genuine

Related reading:

• Email Authentication Explained: SPF, DKIM, DMARC and Why All Three Matter
• What is DKIM? How Email Signatures Prove Your Messages Are Genuine
• What is DMARC? Why 66% of Companies Still Don't Have It Configured