No SPF record found: add one SPF record for your domain
"No SPF record found" means your domain doesn't publish the list of servers allowed to send its email, so receivers can't confirm your sign-in links and receipts really came from you. Add one TXT record at the root of your domain, such as v=spf1 include:_spf.google.com ~all for Google Workspace, with the include: values your email providers give you. Keep it to a single SPF record.
What SPF is
Google: "An SPF record is a line of text that you add to your domain, following your domain provider's instructions." Receiving servers read it to check that a message came from a server you allow. Gmail's sender guidelines ask every sender to "Set up SPF or DKIM email authentication for your sending domains."
Add the record
- List everything that sends email as your domain: your mailbox provider (Google Workspace, Microsoft 365), your app's email service (Resend, Postmark, SendGrid, Amazon SES and others), your newsletter tool, your help desk.
- Collect each one's SPF value from its setup docs. Google Workspace's is
include:_spf.google.com. - Write one record that combines them, ending in
~all:
v=spf1 include:_spf.google.com include:spf.example-email-provider.com ~all
- Add it at your DNS provider as a TXT record with the name
@(the root of your domain) and that value. - Wait for DNS to update, then look it up:
dig +short TXT yourdomain.comshould show one line startingv=spf1.
Google's note on ~all: it "tells receiving servers to mark messages as spam if they're from servers that aren't listed in the SPF record," and "Google recommends you use ~all."
Some app email services send from their own subdomain of your domain (for example send.yourdomain.com) and ask for an SPF record there instead. Follow the provider's instructions for the exact name.
Mistakes to avoid
- Two SPF records. RFC 7208: "A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record," and more than one produces a "permerror". Merge them into one.
+all. It allows every server in the world to send as your domain. Use~all.- Too many lookups. RFC 7208 limits SPF to 10 terms that need DNS lookups (
include,a,mx,ptr,exists,redirect); going over is also a permerror. Remove senders you no longer use.
What Pewterkit Check looks at
For an app on its own domain, the check reads the TXT and MX records at the root of your domain. It reports a fix when the domain receives email (has MX records) but has no SPF record, when there is more than one SPF record, or when the record ends in +all; and a warning when there is no SPF record and no MX record, in case your app sends from this domain. A DNS lookup that fails never becomes a finding.
FAQ
Do I need SPF if I only send email through my app's provider?
Yes, for the domain or subdomain that provider sends from. Its setup page tells you the record to add.
What's the difference between ~all and -all?
RFC 7208 calls ~all a softfail ("probably not authorized") and -all a fail ("not authorized"). Google recommends ~all; once you're sure every sender is listed, some teams move to -all.
Is SPF enough on its own?
Add DKIM (from your email provider) and DMARC too. Senders of 5,000 or more messages a day to Gmail need all three, per Google's guidelines. See no DMARC record found.
Sources
- Set up SPF (Google Workspace Admin Help) — read 27 Oct 2026
- Email sender guidelines (Gmail Help) — read 27 Oct 2026
- RFC 7208: Sender Policy Framework (SPF) — read 27 Oct 2026
How this page was made: drafted with AI from the sources listed, reviewed by Pewterkit. Docs checked Oct 27, 2026. Spotted something out of date? Tell us.
Related guides
- No DMARC record found: add one at _dmarc, start with p=none
- Emails from a new domain going to spam: authenticate first, then build up slowly
- Stripe secret key exposed in your frontend code: rotate it, then move it to the server
- OpenAI API key in your React or Vite frontend: rotate it and move calls to a backend