Your campaigns are landing in spam and your email platform says everything is fine? That’s one of the most frustrating situations for an email marketer: deliverability shows 98%, open rate collapses, and nobody can explain why. The cause is often a missing or misconfigured SPF record in the DNS zone of the sending domain.
When a domain has no SPF, receiving servers handle the message one of two ways: classify it as spam or reject it silently at the SMTP level. Neither shows up as a bounce in your dashboard. Messages go out, they appear “delivered,” but they never reach the inbox.
Good news: adding a valid SPF record takes less than 10 minutes. DNS propagation time is the only variable outside your control.
What an SPF record actually does
Your recipient’s mail server, before even examining the email content, queries your domain’s DNS zone to check whether the server that sent the message is authorized to do so. That’s what SPF (Sender Policy Framework) is: a single line of text in your DNS that lists which servers are allowed to send on behalf of your domain.
If that line is missing, the receiving server gets an empty response. What it does next depends on its internal policy. Gmail, since November 2025, actively rejects non-compliant emails at the SMTP level for high volumes. Soft penalties are gone; this is a hard rejection. Microsoft Exchange is even stricter: it shows an average inbox placement rate of 75.6% for partially authenticated domains, according to TrulyInbox data (analysis of 32,000+ accounts, May 2026).
With no authentication at all, the same data shows inbox placement dropping below 30%. With SPF alone, it climbs back to 55–70%. The full SPF + DKIM + DMARC stack reaches 85–95%. The gap between “nothing” and “fully configured” is 60 percentage points.
Why the problem stays invisible for so long
In April, a growth manager notices his open rate dropped from 32% to 18% over three months. No content changes, no notification from his ESP. The hard bounce rate stayed normal. His CMO wants an explanation.
This scenario is documented in the Suped 2025 report (Whittaker, updated May 2026): 43% of companies have significant inbox misses while their platforms show deliverability rates above 95%. The distinction is between “accepted” and “inboxed”: an email can be accepted by the receiving server and still end up in spam. Your dashboard only sees the first step.
Sender reputation doesn’t degrade overnight. In the first few weeks, Gmail is relatively forgiving. But every failed send feeds negative signals: rising complaint rate, accumulating soft bounces, users who stop clicking. By the time IP reputation starts dropping in Postmaster Tools, the missing SPF has often been causing damage for months.
How to check whether your SPF is missing or broken
Three tools work well for this diagnosis, each from a different angle.
- MXToolbox SPF Lookup—enter your domain at mxtoolbox.com, the result tells you whether an SPF record exists and whether it’s syntactically valid. Time: 30 seconds.
- Google Postmaster Tools—if your domain sends to Gmail, the “Authentication” tab shows the percentage of emails passing SPF, DKIM, and DMARC over the last 30 days. An SPF rate below 95% signals an active issue.
- A raw headers test—send an email from your domain to a Gmail address, open the message, click “Show original.” The Received-SPF line shows
pass,softfail,fail, ornone.noneconfirms the record is missing.
If MXToolbox returns “No SPF Record Found” or Postmaster Tools shows an SPF authentication rate below 90%, proceed to the fix.
Creating a valid SPF record
An SPF record is a TXT record in your DNS zone. Its basic syntax looks like this:
v=spf1 include:_spf.google.com ~all
The include: mechanism points to the authorized servers of your sending provider. Each ESP provides its own value. Some common examples:
| Provider | include mechanism to add | Typical use case |
|---|---|---|
| Google Workspace | include:_spf.google.com |
Sending via Google Workspace |
| Brevo (formerly Sendinblue) | include:spf.brevo.com |
Marketing campaigns |
| Mailchimp / Mandrill | include:spf.mandrillapp.com |
Mandrill transactional |
| Amazon SES | include:amazonses.com |
Sending via AWS |
| OVHcloud MX Plan | include:mx.ovh.com |
Shared hosting |
If you use multiple providers, combine them in a single record: v=spf1 include:_spf.google.com include:spf.brevo.com ~all. Watch out for the 10 DNS lookup limit: each include: mechanism consumes at least one lookup, and some chain others. Exceeding this limit breaks SPF authentication even if the syntax is correct.
The trailing ~all (softfail) or -all (hard fail) defines what servers do with messages not covered by the record. For a domain with a stable configuration, -all is preferable; during migration, stick with ~all until you’ve confirmed no legitimate source is missing.
Adding the record to your DNS
The steps vary slightly by registrar, but the approach is the same.
Log in to your DNS interface (OVHcloud, Cloudflare, Gandi, Namecheap, GoDaddy). Find the DNS zone for your main domain. Add a new TXT record with the name @ (or the bare domain depending on the interface) and paste your SPF value into the “Value” or “Content” field. Save.
Cloudflare typically propagates in under 5 minutes. OVHcloud and Gandi can take 30 minutes to a few hours. To verify propagation is complete, rerun MXToolbox or use dig TXT yourdomain.com from a terminal; when the record appears, you’re live.
In practice, the configuration takes 5 to 8 minutes on Cloudflare; the rest of the stated 10 minutes covers the initial diagnosis and post-add verification.
The objection we hear all the time: “I already have Lemlist, Instantly—my ESP handles that”
Outreach platforms like Lemlist, Instantly, or Smartlead set up their own sending infrastructure and can add their SPF mechanism to your DNS through an onboarding wizard. But that mechanism only covers sends going through their servers. If your domain also sends via Google Workspace, an internal SMTP server, or another transactional tool, those flows are not covered by your ESP’s include.
An SPF record covers all authorized sources for a given domain. The classic oversight: a domain configured for Lemlist with no include for Google Workspace, where billing or support emails end up in spam because the Google server isn’t listed.
“SPF misconfigurations affect 15% of domains that have SPF enabled.” (dmarcian, cited by TrulyInbox, May 2026)
Having SPF isn’t enough if the list of authorized sources is incomplete or if the 10 DNS lookup limit is exceeded.
What SPF alone doesn’t fix
SPF improves sender authentication but doesn’t sign the message content. That’s DKIM’s job: a cryptographic key pair that proves the email hasn’t been tampered with in transit. Without DKIM, TrulyInbox data shows an additional inbox placement penalty of 10 to 15 points.
DMARC takes both SPF and DKIM together to define a policy: what to do if an email fails both checks? Reject, quarantine, or do nothing (monitoring only). Without DMARC, even correct SPF and DKIM leave your domain open to spoofing, and you have no aggregate reporting to catch anomalies. In 2026, 78% of organizations know about DMARC but only 42% actually enforce it with a strict policy (Valimail, State of DMARC 2026).
Starting with SPF is the right call: it’s the technical prerequisite for the other two. But SPF alone puts your inbox rate between 55 and 70%. List hygiene and IP warming do the rest.
Gmail now rejects unauthenticated emails at the SMTP level. The TXT record in your DNS is the one variable you control entirely. It takes a few minutes and costs nothing.
