What is SPF?
What it is, why it matters, and how to get it right
Sender Policy Framework (SPF) is an email standard that pioneered the concept of domain-based email authentication. Below, we’ll walk you through everything you need to know about SPF, including what it is, how it works, limitations, and solutions.
Table of Contents
Email remains one of the most common and most exploited forms of business communication. Without safeguards, your domain is wide open to spoofing, phishing, and impersonation.
Sender Policy Framework (SPF) is one of the foundational email authentication protocols designed to stop exactly that. By authorizing which mail servers can send on your behalf, SPF helps ensure your messages are trusted, your brand is protected, and bad actors can’t pretend to be you.
Key takeaways:
- SPF checks the Return-Path domain, not the From: address, so it’s not a standalone solution and should be paired with DKIM and DMARC for full protection.
- The 10-DNS lookup limit is a major SPF constraint. Exceeding it causes silent failures and is common with cloud-based sending services.
- SPF fails with email forwarding because the forwarded message appears to come from an unexpected and unapproved IP address.
- Valimail Instant SPF automates SPF management, bypasses the 10-lookup limit, and eliminates SPF flattening risks with no manual DNS edits required.
What is SPF?
SPF prevents spoofing by enabling domain owners to allowlist IP addresses that are authorized to send email on the domain’s behalf.
If a mail server with an IP address not on the list tries to send an email using that domain, it won’t pass SPF authentication.
If the sender is on the list → the email passes SPF.
If the sender is not on the list → the email fails SPF and may be rejected or flagged as suspicious.
A jargon-free explanation of SPF: Think of SPF like a return address allowlist at the post office. Imagine you’ve told the post office to only deliver letters from a specific list of return addresses you trust. If a letter shows up claiming to be from you, but the return address isn’t on your approved list, the post office flags it or holds it back.
SPF is a cornerstone of email authentication and is the first of several standards established for that purpose. In a simplistic sense, SPF lets you create an allowlist for IP addresses. If a mail server with an IP address that’s not on your list tries to send email using your domain, it won’t pass the SPF authentication test.
Work on SPF started in 2003, and domains have been deploying it increasingly widely since then. SPF was published as RFC 4408 in 2006 and became an officially proposed Internet standard via RFC 7208 in 2014. SPF is widely used by major and minor mailbox providers (Google, Microsoft, Yahoo, etc.) and all Secure Email Gateways (SEGs).
How SPF email records work
Here’s a quick overview of how SPF works:
- Publish SPF record.
Domain owners publish SPF records to the Domain Name System (DNS) that spell out the rule sets for their domains. An SPF record is plain text, and it can be as simple as a single line listing the IP addresses allowed to send an email on the domain’s behalf.
- Perform DNS lookup.
When an email server receives an incoming email, it performs DNS lookups to retrieve the SPF record for a domain and examines the domain shown in the message’s Return-Path.
- Process SPF record.
It will then process that SPF record to attempt to find the IP address of the sending server in the SPF record. This typically requires further DNS lookups to process parts of the SPF record linked in “include” statements. Notice the “include” statements in the above SPF record.
- Pass or fail test.
If there’s a match, the email passes the test and, in most cases, is delivered to the user’s inbox. If there is no match, the receiving server will treat the email as having failed SPF verification and will typically reject the message or add a flag to it, marking it as suspicious.
Why is SPF important to set up for my email programs?
SPF is one of the foundational building blocks of a secure and reliable email program. Without it, your messages are at higher risk of being mistrusted, blocked, or even used by attackers for fraudulent purposes.
Protects your brand from spoofing
Attackers often attempt to impersonate trusted domains in phishing and business email compromise (BEC) campaigns. By publishing an SPF record, you tell receiving mail servers exactly which systems are authorized to send on your behalf. This makes it much harder for fraudsters to forge your domain in their attacks.
Supports inbox placement and reputation
Deliverability is about making sure your audience actually receives it. SPF helps receiving servers verify the legitimacy of your messages, which improves your domain’s reputation. While SPF alone doesn’t guarantee inbox placement, it works with DKIM and DMARC to create a strong authentication framework that boosts trust and reduces the risk of your emails being flagged as spam.
Provides visibility and control
By defining your approved senders, SPF gives you more control over your email ecosystem. This is especially important if your organization uses multiple services (like Google Workspace, Salesforce, or Mailchimp) to send mail. With SPF, you set clear rules about who can and can’t send using your domain.
Meets industry and custom expectations
Today’s customers and partners expect trusted brands to safeguard their communications. Many security frameworks, regulators, and even industry groups view SPF as a minimum best practice for email authentication. Having it in place demonstrates that your organization takes email security seriously.
Google, Yahoo, and Microsoft all require that senders’ email messages must pass SPF authentication checks now. If you don’t have SPF configured, your email will be blocked. Learn more about the requirements here.
How can I check SPF record?
Use the Valimail SPF Checker to instantly check your SPF record, identify errors, and validate your domain’s SPF configuration, all for free and with zero signups.
Whether you’re troubleshooting email deliverability, dealing with SPF authentication failures, or trying to stay compliant with DMARC, a trusted SPF record checker is essential. Use this tool to check your SPF record and:
- See exactly what your domain’s SPF record looks like
- Spot SPF syntax issues or formatting errors
- Detect multiple SPF records (a common misconfiguration)
- Check for SPF flattening risks or lookup-limit violations
- Confirm authorized senders and includes
“Valimail helps us to have error-free SPF records and helps us protect our domain and subdomains against spoofing, and it saves us time as we don’t have to update the DNS records manually.”
Venkata Reddy
Senior Security Operations Engineer at DAZN TV
With the free SPF checker from Valimail, you can ensure your domain’s email authentication is set up correctly and performing the way it should before problems hit the inbox.
Check your
domain now
Enter your domain to see if it’s vulnerable to spoofing or if others are sending emails on your behalf. Instantly check your DMARC, SPF, and BIMI status with a detailed security report.
You’re not fully protected, learn more here.
Check your
domain now
Enter your domain to see if it’s vulnerable to spoofing or if others are sending emails on your behalf. Instantly check your DMARC, SPF, and BIMI status with a detailed security report.
You’re not fully protected, learn more here.
Check your
domain now
Enter your domain to see if it’s vulnerable to spoofing or if others are sending emails on your behalf. Instantly check your DMARC, SPF, and BIMI status with a detailed security report.
You’re not fully protected, learn more here.
Your Domain
Not protected AGAINST IMPERSONATION ATTACKS
DMARC NOT AT ENFORCEMENT
exampledomain1.com
Authentication Status for January 10, 2025
DMARC at Enforcement
SPF Record Configured
BIMI Ready
exampledomain1.com
Authentication Status for January 10, 2025
DMARC at Enforcement
SPF Record Configured
BIMI Ready
Is SPF complicated to implement?
Despite being a widely accepted standard for email authentication, SPF adoption is still far from universal because of errors and complications in implementing it. A 2024 study shows that only about half of the top 10 million domains in the world have an SPF record.
SPF adoption lags not because it isn’t valuable, but because of gaps in awareness, complexity, and maintenance.
While simple in theory, SPF can be complex to implement in practice. One potential hang up is that SPF records are text, but the SPF syntax is a little tricky, and it can be easy to make typos or other errors that are hard to spot and which render the SPF record useless.
Companies that lack expertise in cybersecurity in general (and email security in particular) often find SPF even trickier. Even some companies that provide email security systems have issues with their SPF records!
Second, the rules (“directives” in the language of SPF) can be quite a bit more complicated than lists of IP addresses. For example, an SPF record can include:
- A list of specific permitted IP addresses or net blocks (ranges of IPs)
- Rules that point to other types of DNS records. For instance, “if the MX record or the A record for the sending server contains a specific IP address, let the message pass.”
- “Include” directives that reference SPF rules controlled by another entity.
“Managing DNS records for SPF was always challenging, with frequent changes and risk of exceeding lookup limits. With Valimail’s automated monitoring and real-time alerts, we now have complete visibility into our SPF record health, ensuring optimal configuration without disruptions. Their proactive approach saves us time and prevents misconfigurations.”
Melvin Joseph
Security Engineer at Ausgrid
For example, if you are using Google’s G Suite and you want to enable SPF for the mail sent by Gmail (as well as email notifications sent by Google Docs, Google Calendar, and so on), you would add “include:_spf.google.com” to your SPF record. This tells mail servers to do an additional DNS lookup for _spf.google.com to find additional SPF rules listed there. Many other cloud services that send email on their customers’ behalf—and there are thousands of them—use a similar approach.
How to set up and properly configure SPF
Setting up SPF is critical for securing your email programs and improving trust with receiving mail servers. Here’s how to do it correctly:
- Identify your authorized senders.
Make a list of all the services and servers that send email on behalf of your domain (e.g., Google Workspace, Microsoft 365, Salesforce, SendGrid, Mailchimp, on-premise servers).
- Create the SPF Record.
- Start with v=spf1 (this defines it as SPF version 1).
- Add mechanisms for each sending source:
- include for third-party senders like Google (include:_spf.google.com).
- ip4 or ip6 for direct server IP addresses.
- mx or a if you send mail from your own infrastructure.
- End with ~all (softfail) while testing, and move to -all (hardfail) once you’re confident the record is accurate.
Example SPF Record:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.0.2.1 ~all - Add the SPF record as a TXT entry in your DNS settings.
- Example DNS entry:
- Type: TXT
- Name: @Publish the SPF record to DNS.
Value: v=spf1 include:_spf.google.com ~all
- Test your SPF record.
Use online tools like Valimail’s SPF checker or dig/nslookup commands to verify your record.
Send test emails to external accounts and check the “Authentication-Results” header to confirm SPF passes. - Maintain and update regularly.
– Review your SPF record anytime you add or remove a service.
– Monitor for errors like exceeding the 10 DNS lookup limit.
Troubleshooting common SPF errors
Even a small misconfiguration can break SPF. Here’s a quick reference of the most common SPF errors and how to fix them:
Error | What it means | How to fix it |
|---|---|---|
No SPF record found | Your domain has no SPF TXT record published in DNS. | Create and publish a valid SPF TXT record in your DNS settings. |
Domain not found in SPF | An include points to a domain without an SPF record, or the domain is invalid. | Verify the included domain has an SPF record and correct any typos. |
Too many DNS lookups | The SPF record exceeds the 10-lookup limit due to nested includes. | Flatten the record or use a service like Valimail Instant SPF® to optimize it. |
SPF record too long | The TXT record exceeds 255 characters per string. | Split the record into quoted strings or simplify senders to reduce length. |
SPF fail (-all) | The sending source is not listed in the SPF record. | Add the correct IP, domain, or include statement to authorize that sender. |
SPF softfail (~all) | Unauthorized sender flagged but still delivered (often to spam). | Review logs and adjust SPF to cover missing legitimate sources. |
SPF neutral / none | No guidance on how to handle unauthorized senders. | Replace with ~all once your record is complete. |
Emails landing in spam despite SPF pass | SPF passes, but the reputation or DKIM/DMARC is missing. | Implement DKIM and DMARC; monitor sending IP/domain reputation. |
Some of the SPF risks and limitations
While SPF is better than nothing, it’s not a complete solution to protect your sending domains. Here are a few of the risks and limitations of SPF:
1. Email SPF doesn’t survive email forwarding
SPF’s use of “last hop” IP address checks means that SPF does not inherently support email forwarding. Any SPF records from senders trying to reach you through a forwarding address won’t validate because, to the receiving server, it looks like the message is coming from the forwarding server, not the source-identifying originating IP addresses.
For instance, if you’re an alumnus of a college that offers you a lifetime email address (@alumni.college.edu or something similar), that typically forwards email to your actual address (gmail.com or your company address). Any SPF records from senders trying to reach you through that address won’t validate, because to the Gmail server, it looks like the message is coming from the college’s email server (the “last hop” engaged in forwarding the message to you), not the source email server. The same problem applies to e-mail discussion lists and even wanted bulk mail, like order receipts, shipping notifications, and newsletters.
SPF only lets you know that a message came from an approved IP address. This doesn’t always represent a one-to-one relationship.
2. SPF on its own fails to prevent spoofing
SPF uses the domain shown in a message’s Return-Path field for authentication, not the “From:” address that humans can read. This creates a few issues:
- The “From:” address can still be spoofed.
- The Return-Path indicates where bounce messages should go, so the “From:” and Return-Path domains may differ. Most mail clients do not display the Return-Path address by default. For example, if you’re sending mail through a mailing list or marketing automation platform, the “From:” field might show your address, while the “Return-Path:” field shows the address of the email list or the automation platform’s bounce handling system.
- Phishers exploit the general invisibility of “Return-Path:” when setting up their domains with their own SPF records. Then, they can send phishing emails with a company’s domain showing in the “From:” field, but the phisher’s domain in the Return-Path. Such messages are fake, but they will pass SPF authentication.
3. Shared infrastructure creates risk
SPF only lets you know that a message came from an approved IP address. But it doesn’t prevent others using that IP address from sending emails using your domain.
Shared systems like cloud platforms can host multiple cloud services that are dynamically assigned IP addresses at runtime. If the IP address identifies a service that you authorize, such as MailChimp, then anyone using the same IP address on that system could send messages that are authorized with your SPF record.
4. It has a strict SPF 10 DNS lookup limit
SPF is an essential part of email authentication, but it wasn’t designed for the cloud era. On its own, SPF will not authenticate email. However, in the absence of a DMARC record, how receiving servers handle a failed SPF check is entirely up to them.
The SPF standard limits the number of DNS lookups mail servers will do when evaluating an SPF record. Before cloud services became common, 10 DNS queries were sufficient because most email messages were sent from applications hosted by the domain owner.
But for modern cloud services, 10 lookups can go quickly, particularly because one lookup might contain other nested “include” statements requiring further DNS queries.
For example, an “include” directive like include:_spf.google.com may look like one lookup, but it actually triggers four, because Google’s SPF record contains three nested includes. Multiply this across services like Salesforce, SendGrid, and G Suite, and it’s easy to burn through the limit. To make things worse, vendors can change their SPF records at any time, altering the number of lookups required—without notifying you.
To include all the sending services means the SPF record exceeds the 10 DNS lookup limit. To mitigate the limitations of 10 domain lookups, they do SPF flattening to the record by pulling all the IP addresses of approved sending services forward into the primary SPF record.
Fluctuations in the IP addresses used by a cloud platform or sending service will require constant updates to the SPF record to prevent good email from being blocked. Some vendors attempt to cover any possible changes to IP address blocks used by cloud providers by specifying wide ranges in the SPF record, in tens of thousands to millions of IP addresses.
Overly permissive IP blocks can allow fraudulent senders to send email on behalf of your domain, defeating the purpose of DMARC enforcement.
“As a CTO, my team and I were spending too much time troubleshooting DMARC issues, managing complex SPF records, and ensuring our email security policies didn’t disrupt legitimate business communication. Valimail’s DMARC solution completely changed that. Their automated solution platform did the heavy lifting, eliminating SPF flattening issues, streamlining DKIM authentication, and providing real-time visibility into our email ecosystem.”
Nicholas Costa
CTO at Soaring Towers
Pro Tip:
Use Valimail to manage your SPF record.
“Before Valimail, managing our SPF record was challenging, and enforcing DMARC seemed impossible due to the 10-lookup limit. Valimail made the process seamless.” – Matthew Tyrney, Systems Engineer at Omni Hotels & Resorts
Valimail Instant SPF®: The solution to SPF flattening
Valimail has a patented methodology to manage SPF records that mitigates the SPF 10-lookup limit and enables you to define unlimited senders. Valimail’s Instant SPF leverages the macros already defined in the SPF standard to:
- Extract identifying information
- Map this information to the originating service
- Return service-specific SPF rules that the receiver can evaluate
Valimail’s patented SPF macro dynamically generates a perfectly tailored SPF record, in milliseconds, in response to each mail server request.
Start your SPF journey with Valimail
Hand-crafting SPF records and maintaining them in conventional DNS doesn’t work for most organizations. What’s more, SPF doesn’t ensure that mail gets delivered (if it passes) or that it gets quarantined/rejected (if it fails). In the absence of a DMARC record, how receiving servers handle a message that fails SPF is entirely up to them.
Valimail automates SPF management with our patented SPF tech, so you don’t have to worry about SPF syntax errors, lookup limits, or constantly updating records. With one-time DNS delegation, Valimail dynamically responds to SPF queries in real time, keeping your authentication accurate, compliant, and secure.
As the recognized #1 leader in DMARC and email authentication on G2, Valimail helps over 90,000 organizations move beyond manual DNS updates and error-prone key management.
“Managing SPF, DKIM, and DMARC manually was complex, and we frequently hit SPF record limits and authentication failures. Valimail’s automated solution took the guesswork out of email authentication, resolving our misconfigurations instantly and providing full visibility into our email ecosystem.”
Carlos Cornielle
Cloud Security Engineer at Evopoint Solutions
Want to uncover your sending services? Valimail Monitor can reveal all your sending services by name rather than digging through XML reports. And the best part is that it’s completely free, no credit cards or trial sign-ups required.
Take the first step toward SPF automation with Valimail Monitor:
Additional SPF resources
Explore more on SPF, email authentication, and phishing prevention with these expert insights. Whether you’re just getting started or fine-tuning your enforcement strategy, these resources will help you secure your domain and stay ahead of emerging threats.
Frequently asked questions about SPF
As the global leader in DMARC and email authentication, Valimail has helped over 80,000 organizations secure their domains and stop impersonation attacks. In this section, we answer the most common questions and SPF FAQs so you can protect your email domains with peace of mind.
Will adding SPF for only Google affect my MailChimp sending services?
Yes, it might. SPF is domain-wide, so if you only include Google in your SPF record and leave out Mailchimp, Mailchimp’s messages may fail SPF checks and land in spam. You should always include all legitimate senders in a single SPF record.
Can you have multiple SPF records?
No, your domain should have only one SPF record. Multiple records break SPF and can cause the email to fail authentication. Instead, combine all senders into a single, properly formatted SPF record.
How do I make my server IP pass SPF?
To authorize your server’s IP address, include it in your SPF record using the ip4: or ip6: mechanism. For example:
v=spf1 ip4:192.0.2.1 ~all
How can I add SPF to my domain?
You add SPF by publishing a TXT record in your domain’s DNS settings. The record should start with v=spf1, followed by authorized sending sources, and end with ~all.
How do I set up SPF and DKIM for Gmail?
When setting up SPF for Gmail, you’ll need to add Google’s SPF mechanism (include:_spf.google.com) to your domain’s Gmail SPF record. For DKIM, Google Workspace provides a DNS TXT record you publish to authenticate Gmail-sent email. Google offers detailed setup instructions in your admin console.
What is the difference between PTR and SPF?
SPF explicitly authorizes sending sources using a DNS record, while PTR (reverse DNS) maps an IP address back to a domain. PTR is not an authentication protocol; it’s a basic trust signal. SPF is the standard for sender identity validation.
Is the SPF PTR mechanism deprecated?
Yes. The ptr mechanism in SPF is deprecated and not recommended. It’s inefficient, unreliable, and discouraged by both the IETF and leading email providers.
What is the difference between an SPF record and an A record?
An SPF record is a type of DNS TXT record that specifies which mail servers can send email on your domain’s behalf. An A record, on the other hand, maps your domain name to an IP address, allowing users to reach your website. While both live in DNS, they serve different purposes: SPF for email authentication, A records for web and network routing.
What is a Google SPF record?
A Google SPF record is the SPF configuration needed when your organization uses Google Workspace (formerly G Suite) to send email. To authorize Google’s servers, you’ll typically include:
v=spf1 include:_spf.google.com ~all
This tells receiving servers that Google’s mail servers are allowed to send email for your domain. Without it, messages sent from Gmail on behalf of your domain may fail authentication and land in spam.
What happens if I’m missing an SPF record?
If you get an error saying “No SPF record found,” email servers that receive your messages have no way to verify whether the messages are authorized. This often results in:
- Emails are being marked as spam or suspicious.
- Higher chances of phishing or spoofing attacks using your domain.
- A negative impact on your email deliverability.
Adding a simple SPF record can help protect your brand and improve inbox placement.
Can I see an SPF record example?
Yes, here is a sample SPF record that you might see:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.168.0.1 ~all
You can actually find your own SPF record using Valimail’s free SPF record checker:
Enter your domain to see if it’s vulnerable to spoofing or if others are sending emails on your behalf. Instantly check your DMARC, SPF, and BIMI status with a detailed security report. Enter your domain to see if it’s vulnerable to spoofing or if others are sending emails on your behalf. Instantly check your DMARC, SPF, and BIMI status with a detailed security report. Enter your domain to see if it’s vulnerable to spoofing or if others are sending emails on your behalf. Instantly check your DMARC, SPF, and BIMI status with a detailed security report. Not protected AGAINST IMPERSONATION ATTACKS DMARC NOT AT ENFORCEMENT Authentication Status for January 10, 2025 DMARC at Enforcement SPF Record Configured BIMI Ready Authentication Status for January 10, 2025 DMARC at Enforcement SPF Record Configured BIMI ReadyCheck your
domain nowYou’re not fully protected, learn more here.
Check your
domain nowYou’re not fully protected, learn more here.
Check your
domain nowYou’re not fully protected, learn more here.
Your Domain
exampledomain1.com
exampledomain1.com
Get started for free
with Monitor
Start your path to DMARC enforcement with a panoramic view of the traffic being sent on your behalf.
No trial offers, credit cards, or obligations.
Explore all Valimail
has to offer
Go one step further than visibility…Take action! Reach DMARC enforcement faster. Stay compliant with evolving sender requirements. All while protecting your brand.