SPF not found does not immediately bounce your email. It returns a result of none, which most providers treat as a weak negative signal rather than a hard failure.
The problem is compounding. Pair a missing SPF with a missing DKIM or a strict receiving policy and your mail starts disappearing into spam with no bounce notification and no way to know it happened.
What SPF does
SPF (Sender Policy Framework) is a TXT record at your domain root that lists which mail servers and services are authorized to send email from your domain.
When a receiving server gets your email, it checks this record against the IP that sent the message. No record means no list. The check returns none and the provider has nothing to verify against.
Adding your first SPF record
The record goes at the root of your domain using @ as the host:
Type: TXT
Name: @
Value: v=spf1 include:YOUR-PROVIDER ~all
Common provider values:
-
Google Workspace:
include:_spf.google.com -
Microsoft 365:
include:spf.protection.outlook.com -
SendGrid:
include:sendgrid.net -
Mailgun:
include:mailgun.org
If you send through multiple services, combine them into one record:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
One rule you must not break
Only one TXT record starting with v=spf1 is allowed per domain. If you add a second one, SPF returns a PermError and fails completely regardless of what either record says. If you already have an SPF record, edit the existing one instead of creating a new one.
Start with ~all
The ~all at the end is a softfail. It flags but still delivers mail from unlisted senders. Use this while you are confirming all your sending services are covered. Switch to -all once nothing legitimate is missing from the record.
Verify it worked
dig TXT yourdomain.com | grep spf
You should see exactly one line starting with v=spf1. You can also run a full check at InboxGreen to see SPF, DKIM, and DMARC together in one scan.
For the full guide with provider-specific steps and common mistakes: SPF record not found: fix guide
Top comments (4)
If you’re unfamiliar with SPF, you’ll also be unaware of Reverse DNS/PTR, and you’ll likely be dropped, even if it’s not as catastrophic as without SPF. At the very least, you could have tried to hide that you generated the entire thing using AI (I’m quite confident it was Claude).
Fair point on PTR/rDNS. I left it out to keep the guide focused on the most common issue newcomers hit, but you're right that it belongs in a complete picture. I'll add a section on it. On the AI thing, I use AI as a writing assistant to speed up drafts, but the technical content and structure come from real experience building InboxGreen. Happy to be wrong on anything specific though 🙂
Have you heard of mail-tester.com? It’s been my go-to tool for checking email deliverability for quite some time now. Here’s how it works: you send an email to a temporary address provided by the service, and you’ll receive a report on the deliverability of your email. This makes it a great way to evaluate someone’s email configuration.
There are a few other interesting things that come to mind at the moment:
Some top-level domains (TLDs) have a reputation for being problematic, which can sometimes lead to email rejections. I personally think this is unfair, but it’s something that I’ve heard about. I haven’t been able to verify it myself, though.
You can also set up a general profile image for a domain, such as a business logo. This image will be displayed when your email is delivered.
A very practical feature for a service like yours would be the ability to easily verify deliverability to major email providers, such as Gmail, Microsoft, and others.
Overall, mail-tester.com is a useful tool for anyone looking to improve their email deliverability.
mail-tester.com is a well known tool, no argument there. The fundamental difference in approach that is worth pointing out though: mail-tester works at the email level, meaning you need a working mail setup to send the test message. That's a chicken-and-egg problem when you're debugging a broken configuration. if your SPF is misconfigured, your test email might not even reach them cleanly to begin with.
InboxGreen's free checker at inboxgreen.email/check works at the DNS level. You enter a domain, it reads the records directly no email sending required. That makes it useful when you're setting up a domain from scratch, auditing a client's domain, or checking a domain you don't control. We also have a free SPF generator and DMARC generator for building the records once you know what's missing.
On your other points TLD reputation is real and something I'll add to a future post. The brand logo thing you're referring to is BIMI, which requires DMARC at p=quarantine or p=reject first, so it comes after the basics are solid. And multi-provider inbox placement testing (Gmail, Outlook, Yahoo) is already on the InboxGreen roadmap.