If you landed here looking for SMTP2GO’s SPF settings, here’s the short version: SMTP2GO handles your SPF for you through a CNAME record on your sender domain, not a traditional TXT include. Add the CNAMEs we provide on your Verified Senders page, and SPF (and DKIM) authenticate automatically. We unpack why a little further down.
If you’re here because you’ve heard “SPF” tossed around in deliverability conversations and want the real picture, stick around. By the end of this guide, you’ll know what an SPF record is, why it matters more in 2026 than ever, how to read and write one, and how to verify yours is doing its job.
What is an SPF record?
An SPF record (Sender Policy Framework) is a small piece of text published in your domain’s DNS. Its job is simple: it tells the rest of the world which mail servers are allowed to send email on behalf of your domain.
Think of it like a doorman with a clipboard. When a receiving mail server gets a message claiming to come from [email protected], it asks your DNS, “Is this server actually allowed to send for yourcompany.com?” The SPF record is the clipboard. If the sender is on the list, the message gets a green light. If not, it can be rejected, marked as spam, or quietly flagged depending on how strict your record is.
SPF lives in DNS as a TXT record. (You may have seen references to a dedicated “SPF” record type. It was deprecated years ago. Use TXT.)
Why SPF matters in 2026
A few reasons, and they’ve all gotten louder lately:
1. Spoofing is still cheap and easy. SMTP, the protocol that moves email around the internet, was never designed to verify who the sender claims to be. Without SPF, anyone can send a message that looks like it came from your domain. SPF is the first line of defense against that.
2. Gmail and Yahoo enforce it. Since February 2024, Gmail and Yahoo require senders to authenticate with SPF and DKIM, with extra rules for senders pushing more than 5,000 messages a day. Skip SPF and your messages are either rejected outright or quietly buried in spam. We’ve covered the full Gmail and Yahoo 2024 inbox protection rules if you want the deeper read.
3. SPF feeds DMARC. A DMARC policy can only do its job if it has SPF (and ideally DKIM) results to evaluate. No SPF, no real DMARC. And DMARC is increasingly how mailbox providers decide whether to trust you.
In short: SPF stopped being a “nice to have” years ago. In 2026, it’s table stakes for anyone serious about email deliverability.
How SPF actually works
Here’s what happens, step by step, when an email arrives at a receiving server:
- The receiving server reads the message’s Return-Path (also called the envelope sender). That domain is what SPF checks against, not the address in the From header.
- It looks up the SPF record at that Return-Path domain in DNS.
- It compares the IP address that just delivered the message against the list of authorized senders in the SPF record.
- It returns one of seven results:
pass,fail,softfail,neutral,none,temperror, orpermerror. The receiving server then decides what to do with the message based on that result (and on your DMARC policy, if one exists).
Two important nuances most explainers gloss over: - The Return-Path is often a different domain than what the recipient sees in the From header, especially when you use an external sending service. That’s by design and it’s how SPF works correctly with services like SMTP2GO.
- A
passresult on SPF doesn’t mean the message is good. It means the sending server is authorized. DMARC is what ties SPF results back to the visible From address.Anatomy of an SPF record
A typical SPF record looks like this:
v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all
Break it down piece by piece:
v=spf1is mandatory. It tells the receiving server, “this is an SPF record, version 1.” Anything else (v=spf2, etc.) makes the record invalid.ip4:198.51.100.0/24authorizes a range of IPv4 addresses. You’d useip6:for IPv6.include:_spf.google.compulls in Google Workspace’s SPF record. Theincludemechanism is how you authorize a third-party service (Google, your CRM, your help desk) to send on your behalf.-allis the catch-all at the end. It tells receivers what to do with any sender not explicitly listed above it.Qualifiers: the four endings of an SPF record
The character before all (or any mechanism) controls the verdict:
| Qualifier | Meaning | When to use it |
|---|---|---|
-all | Hard fail. Reject anything not listed. | Best practice once you’re confident your record is complete. |
~all | Soft fail. Mark as suspicious but accept. | Useful while you’re testing or rolling out. |
?all | Neutral. No opinion. | Almost never. It defeats the point. |
+all | Pass everything. | Never. This authorizes the entire internet to send as you. |
The 10-DNS-lookup limit
SPF caps the number of DNS lookups a record is allowed to trigger at ten. Each include, a, mx, ptr, and exists mechanism counts. Go over and your record returns a permerror, which fails SPF authentication completely. We get into this further down under common errors.
How SMTP2GO handles SPF (and why it looks different)
Here’s where SMTP2GO takes a different path from most providers, and why it’s actually a better one.
The traditional approach is to have you add an include: to your domain’s TXT record, something like include:spf.someprovider.com. Easy enough, until you have three or four sending services and you’re bumping up against the 10-lookup limit, or one provider changes its SPF and silently breaks yours.
Instead, SMTP2GO uses a CNAME-based approach with VERP (Variable Envelope Return-Path). When you add a sender domain to your Verified Senders page, we give you a small set of CNAME records to add at a subdomain (something like em100.yourdomain.com). Those CNAMEs point to records we maintain on our side. We send your mail using a Return-Path at that subdomain, and SPF gets validated against the SPF record we keep accurate, automatically.
What that means for you:
- Your public SPF record stays clean. You don’t have to add SMTP2GO to it, which keeps you well under the 10-lookup ceiling and frees up room for other services.
- You don’t maintain anything. When our infrastructure changes, we update SPF behind the scenes. Nothing breaks on your end.
- Better security. Your visible SPF doesn’t broadcast every service you use to the internet, so attackers have less to work with.
- DKIM gets handled too. The same CNAME flow signs your mail with DKIM, so you cover both authentication checks in one move.
It’s the modern standard for ESP authentication, and it’s the reason SMTP2GO setup looks different from the boilerplate “add this TXT record” instructions you see in older guides.
Setting up SPF with SMTP2GO: step by step
- Log in to your SMTP2GO dashboard and head to Sending > Verified Senders.
- Click Add Sender Domain and enter the domain you want to send from (e.g.,
yourcompany.com). - We generate a set of CNAME records. Copy them.
- Log in to your DNS provider (Cloudflare, GoDaddy, Namecheap, Route 53, whoever hosts your domain’s DNS) and add the CNAMEs exactly as shown.
- Come back to the Verified Senders page. Once DNS has propagated, the domain flips to Verified. That’s it.
If you have multiple domains or you’re sending on behalf of customers, we have automation that adds DNS records for you at supported registrars, which removes the copy-paste step entirely.
Setting up SPF without SMTP2GO
If you’re authenticating a domain for a different provider (or you want to add SMTP2GO alongside other services in a traditional include: model), here’s the generic flow:
- Find your existing SPF record first. Use a tool like MxToolbox or run
dig TXT yourdomain.comfrom a terminal. You can only have one SPF record per domain. If you already have one, you’ll edit it, not add a second. - Get the include value from your provider. Most ESPs publish theirs (
include:_spf.google.comfor Google Workspace,include:sendgrid.netfor SendGrid,include:spf.protection.outlook.comfor Microsoft 365, and so on). - Compose the record. Combine includes with a clear ending qualifier:
v=spf1 include:_spf.google.com include:provider2.com ~all - Publish it as a TXT record at the root of your domain (
@oryourdomain.com). - Wait for propagation. DNS changes typically take 15 minutes to a few hours, occasionally up to 48.
- Verify. Use any free SPF checker, or just dig the record yourself.
Common SPF errors and how to fix them
“Too many DNS lookups” (PermError). You’ve exceeded the 10-lookup limit. Audit your include chain. Many ESPs nest their own includes, which compounds quickly. Drop services you no longer use, or switch services that support a CNAME or “flattening” approach (like SMTP2GO).
Two SPF records on one domain. Only one is allowed. Receivers see two and return a PermError, which fails everything. Merge them into a single record.
SPF passes but mail still goes to spam. SPF alone doesn’t guarantee inbox placement. Make sure DKIM is also signing your mail, your DMARC policy aligns, and your sender reputation isn’t dragging you down. Our guide to improving email deliverability covers the rest of the stack.
SPF passes for the Return-Path but DMARC fails. This is an alignment problem. The Return-Path domain and the From header domain need to align (loosely or strictly, depending on your DMARC policy). When SMTP2GO sends with a Return-Path at a subdomain of your sender domain, SPF stays aligned automatically.
Soft fails leaking through. If your record ends in ~all, receivers may still accept unauthorized mail. Once you’re confident your record is complete, switch to -all.
SMTP2GO domain not verifying. A common cause is multiple DNS servers returning different results. Search cname:em100.yourdomain.com:all at MxToolbox (replacing the hostname with your actual CNAME), and you’ll see results from each authoritative server. Hovering over the warning icon on your Sender Domains page will surface the specific error message. Our guide to verifying sender address errors walks through the rest.
How SPF works with DKIM and DMARC
Treat them as a three-part stack:
- SPF authorizes the server. Did this IP have permission to send for this domain?
- DKIM authorizes the message. Was this email signed by a key belonging to the sending domain, and was it tampered with in transit?
- DMARC authorizes the brand. Does the visible From address align with what SPF and DKIM verified, and what should happen if not?
You need all three working together to satisfy modern mailbox providers and to actually protect your domain. We’ve gone deep on each: our DKIM deep dive and what DMARC is and how to use it cover the rest.
How to verify your SPF record is working
A few quick checks:
- Send yourself a test email from your domain to a Gmail or Yahoo address. Open the message, click the three-dot menu, and choose Show Original. Look for
spf=passin the headers. - Use a free SPF checker. MxToolbox, Google Admin Toolbox, and DMARCian all have free lookups.
- Run
digfrom a terminal.dig TXT yourdomain.comshows your published record.dig CNAME em100.yourdomain.comconfirms an SMTP2GO CNAME is resolving correctly. - In your SMTP2GO dashboard, the Verified Senders page shows the live status. Green check means everything is in order.
FAQ
Can I have multiple SPF records on my domain?
No. Only one SPF record per domain. If receivers find two, they return a PermError and SPF fails. Merge them into a single record.
Do I need to add SMTP2GO to my SPF record?
No. SMTP2GO authenticates through CNAME records on your sender domain, not through a traditional include:. You add the CNAMEs we give you, and SPF is handled.
What if I send from multiple services?
Add an include: for each service that requires it, watch the 10-lookup ceiling, and consider services that authenticate via CNAME (like SMTP2GO) so they don’t eat into that budget.
Is SPF enough on its own?
No. SPF authorizes servers, not messages. You also need DKIM, and you need DMARC to tie them to your visible From address. The three together are what mailbox providers expect.
Should I use ~all or -all?
Start with ~all if you’re testing. Move to -all once you’re confident every legitimate sender is in the record. -all is the stronger, more protective ending.
Why does SMTP2GO use a CNAME instead of a TXT include?
It keeps your public SPF record cleaner, helps you stay under the 10-DNS-lookup limit, lets us update authentication behind the scenes without you touching DNS, and reduces what attackers can learn about your sending stack. It’s the modern standard.
My domain isn’t verifying. What do I check first?
Confirm the CNAMEs are typed exactly as the dashboard shows them, including any subdomain prefix. Then check propagation across multiple DNS servers (MxToolbox does this in one query). If something’s off, the warning icon on your Sender Domains page will show the specific error.
Get authentication off your plate
SPF, DKIM, and DMARC are non-negotiable in 2026, and they’re a maintenance tax most teams shouldn’t be paying by hand. SMTP2GO automates SPF and DKIM at the CNAME layer, surfaces verification problems before they hit your delivery, and stays out of the way.
Try SMTP2GO free and ship authenticated mail today, or read more on how we approach deliverability before you decide.
About the author
Simon Slade
Simon is a co-founder of SMTP2GO, launched in 2006 out of Christchurch, New Zealand. The idea was simple: a reliable way to send email from anywhere, even when local networks were blocking the usual ports. Twenty years on, SMTP2GO delivers for 35,000+ businesses across 130+ countries. SMTP2GO is ISO 27001 certified, GDPR compliant, an M3AAWG member, and a five-time Deloitte Technology Fast 500 company.
