SPF Records: A Simple Guide to Protecting Your Domain From Email Spoofing
When an email arrives in someone’s inbox, their mail server has to decide: “Is this message really from this domain, or is someone faking it?” One of the tools it uses to answer that question is the SPF record in DNS.
SPF records are small pieces of text attached to your domain, but they play a big role in email security. They tell the world which servers are allowed to send email on behalf of your domain and which ones are definitely not.
What Is an SPF Record in DNS?
SPF stands for Sender Policy Framework. An SPF record is a special TXT record in DNS that lists the mail servers (or services) that are permitted to send email using your domain name.
In simple terms, an SPF record is your public statement: “These servers are allowed to send mail as @mydomain.com. Anything else is suspicious.”
A basic SPF record might look like this:
mydomain.com. TXT "v=spf1 include:_spf.mailprovider.com ~all"
Mail servers read this string, interpret the rules, and then decide how much to trust messages that claim to be from your domain.
Why SPF Matters for Your Domain
Without SPF, anyone can send an email that uses your domain in the “From” address. Spammers and attackers do this to trick people into trusting the message. SPF helps receiving servers detect this kind of forgery.
Good SPF configuration can:
- Reduce the chance that your domain is used for spam and phishing.
- Improve deliverability for legitimate emails you send.
- Work together with DKIM and DMARC to build a stronger reputation.
SPF alone is not perfect, but it is a key part of a healthy email setup.
Basic Structure of an SPF Record
Every SPF record starts with a version tag and then lists a series of mechanisms and modifiers. It always lives in a TXT record.
"v=spf1 [mechanisms and modifiers] [result]"
Example:
"v=spf1 ip4:198.51.100.10 include:_spf.mailprovider.com -all"
Let’s break down the main pieces you will see:
v=spf1– version identifier, always present and always exactly this.ip4:198.51.100.10– allow this IPv4 address to send mail for the domain.ip6:2001:db8::10– allow this IPv6 address (if used).include:_spf.mailprovider.com– trust whatever servers are listed in that other domain’s SPF record.a– allow the IPs of the domain’s A/AAAA records to send mail.mx– allow the IPs of the domain’s MX records to send mail.~allor-all– default rule for everything not previously matched.
Understanding the “all” at the End
The last part of an SPF record often looks like ~all, -all, or sometimes ?all. This is the catch-all rule for any sender that does not match earlier rules.
~all(softfail) – “Mail from other servers is probably not okay. Mark as suspicious, but do not always reject.”-all(fail) – “Mail from other servers is not allowed. You can reject it.”?all(neutral) – “I am not giving any clear policy. Treat unknown senders neutrally.”
For many domains, a common pattern is to start with ~all while testing and then move closer to -all once you are confident the configuration is correct.
Example SPF Records for Common Scenarios
1. Simple Setup: One Mail Server
You host mail on a single server with IP 198.51.100.10 and do not use any other services to send mail (no CRM, no newsletter tools).
mydomain.com. TXT "v=spf1 ip4:198.51.100.10 -all"
This says: “Only this IP can send mail as @mydomain.com. Everything else should be treated as a failure.”
2. Using a Hosted Email Provider
Hosted email providers (like Google Workspace, Microsoft 365, and others) usually give you an SPF “include” to use.
mydomain.com. TXT "v=spf1 include:_spf.mailprovider.com -all"
The include means: “Also allow any servers listed in that other domain’s SPF record.” This lets the provider change their server list without you updating your SPF each time.
3. Multiple Senders: Own Server + Marketing Tool
Many businesses send email from several places: their main email provider, plus a newsletter service, plus maybe a CRM.
Example combining your own IP and two providers:
mydomain.com. TXT "v=spf1 ip4:198.51.100.10 include:_spf.mailprovider.com include:_spf.newsletterservice.com ~all"
All three sources are now authorized. Anything else will be marked as a softfail by SPF-aware receivers.
How to Create an SPF Record Step by Step
If you do not have an SPF record yet, here is a simple approach to building one.
- List all your sending sources.
- Your main email provider.
- Any marketing/newsletter tools.
- CRM systems that send email as your domain.
- Transactional email services (order confirmations, password resets, etc.).
- Check each service’s documentation.
Most providers tell you exactly what to add to SPF (often an
include:value, or specific IP ranges). - Combine everything into one SPF string.
Start with
v=spf1, then add each mechanism or include, then end with~allor-all. - Add the record as a TXT entry in DNS.
- Host:
@(or your root domain). - Type: TXT.
- Value: your full SPF string.
- Host:
- Wait for DNS to propagate, then test.
Use online SPF checkers or send test emails to confirm the setup works.
Important Limits and Pitfalls
SPF looks simple, but there are a few technical limits that catch people by surprise.
The 10 DNS Lookup Limit
SPF evaluation is not allowed to perform unlimited DNS lookups. By design, there is a limit of 10 DNS lookups per SPF check. Each include, mx, a, and some other mechanisms can trigger lookups.
If you exceed this limit, some receivers treat your SPF as a failure. This can happen if you include too many different providers or use nested includes.
To avoid this:
- Reduce the number of
include:directives where possible. - Use dedicated sending services instead of many small tools.
- Follow your providers’ best practices; many now design their SPF records to be efficient.
Multiple SPF Records for the Same Domain
Your domain should only have one SPF TXT record at a given host (for example, at mydomain.com). Having two different SPF records is considered invalid and can cause SPF to fail.
Bad example:
mydomain.com. TXT "v=spf1 include:_spf.mailprovider.com ~all"
mydomain.com. TXT "v=spf1 include:_spf.newsletter.com ~all"
Instead, merge them into one:
mydomain.com. TXT "v=spf1 include:_spf.mailprovider.com include:_spf.newsletter.com ~all"
Using Only SPF Without DKIM or DMARC
SPF is useful, but by itself it has weaknesses. For example, SPF is checked using the envelope sender, not just the visible From address. Forwarding can also break SPF in some cases.
That is why SPF is usually deployed together with:
- DKIM – which signs the message content.
- DMARC – which defines how SPF and DKIM should be enforced and aligned.
Think of SPF as one piece of a three-part puzzle for email authentication.
Testing and Monitoring Your SPF Record
After you create or change an SPF record, testing is crucial.
- Use online SPF checkers to validate the syntax.
- Send test emails to inboxes on different providers (Gmail, Outlook, etc.) and check message headers to see SPF results.
- Look for lines like
Received-SPF: pass,softfail, orfail.
If you later add new sending services, remember to adjust the SPF record accordingly. Leaving them out will cause SPF to fail for messages they send.
Key Takeaways About SPF Records
- SPF is a DNS-based framework that lists which servers may send mail for your domain.
- It is implemented as a TXT record starting with
v=spf1. - You should define only one SPF record per host and include all legitimate senders in it.
- Be mindful of the 10 DNS lookup limit when combining multiple services.
- SPF works best alongside DKIM and DMARC to protect your domain from spoofing.
SPF Records FAQ
What is an SPF record in DNS?
An SPF record is a TXT record in DNS that lists which servers are allowed to send email for your domain. Receiving mail servers use it to check whether a message that claims to be from your domain comes from an authorized source or not.
Do I really need an SPF record for my domain?
Yes, in most cases you should have one. Without SPF, it is easier for attackers to spoof your domain in emails. A correctly configured SPF record helps protect your brand and improves the chances that your legitimate messages reach inboxes instead of spam folders.
Can I have more than one SPF record?
You can have multiple TXT records in general, but you should not publish more than one SPF policy for the same host. Instead of creating separate SPF records, combine all your mechanisms and includes into a single v=spf1 record for that domain.
What is the difference between ~all and -all in SPF?
The ~all (softfail) mechanism marks mail from unauthorized servers as suspicious but does not strictly demand rejection. The -all (fail) mechanism tells receivers that they can reject mail from servers not listed in your SPF record. Many domains start with ~all and move toward -all once they are sure the configuration covers all legitimate senders.
How do I know if my SPF record is working?
Use an SPF checker to validate the record and then send test emails to different providers. In the received message headers, look for the SPF result line. If you see spf=pass for messages sent from your authorized servers, your SPF is working as expected.
Related Email Security Topics
- DKIM records: how to sign outgoing mail so receivers can verify it really came from you.
- DMARC policies: combining SPF and DKIM into a clear instruction for mail receivers.
- Reverse DNS (PTR records): why some mail servers check the IP’s hostname before trusting incoming connections.
- TXT records in DNS: understanding the foundation behind SPF, DKIM, DMARC, and verification codes.
Once you have a solid SPF record in place and you understand what it does, managing new sending services and troubleshooting delivery issues becomes much easier. Instead of guessing why emails are flagged, you can look directly at your DNS policy and adjust it with confidence.