The short answer
You will not find SPF settings in Webflow, and that is not a limitation. Webflow does not provide DNS hosting at all. In their words, "Webflow does not provide its own nameservers."
So your DNS is hosted somewhere else already: your registrar, Cloudflare, or another DNS provider. That is where SPF goes. Always. There is no Webflow-specific step and no Webflow plan that changes this.
Clean answer, simple fix.
What SPF actually does
SPF is a TXT record on your domain that lists which mail servers are allowed to send email as you. Receiving inboxes check it. Without it, anyone can send email that looks like it came from your domain, and there is nothing telling Gmail otherwise.
This matters more than most people realise. Your site being on Webflow does not stop someone spoofing your address to your customers.
Where to add it
Find out who hosts your DNS. Usually it is the company you bought the domain from, unless you moved your nameservers to Cloudflare or similar. Then look for the DNS or records section.
- 1.Log in to your DNS host. This is your registrar unless you have pointed your nameservers elsewhere.
- 2.Find the DNS records editor. On Cloudflare that is DNS > Records > Add record. On Namecheap it is Advanced DNS > Add New Record.
- 3.Choose record type TXT.
- 4.For the host or name, enter @ for your root domain. Route 53 is different, leave the name blank for the apex.
- 5.Paste your SPF value, save, and wait. Namecheap quotes around 30 minutes for changes to apply.
What to put in the record
Your SPF value depends on who sends your email. Here are the values we can confirm.
Google Workspace:
v=spf1 include:_spf.google.com ~all
Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all
Google Workspace + another sender:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
A domain that sends no email at all:
v=spf1 -allPick one line, not all of them. You get exactly one SPF record per domain. The sendgrid.net include is only needed when SendGrid Automated Security is OFF. With it ON, which is the default, SendGrid uses CNAME-based authentication and you should not add the include at all.
The mistakes that break SPF
SPF is short, so people assume it is forgiving. It is not.
- →Two SPF records is a hard failure. One SPF record per domain, no exceptions. Two records is a permerror, and it is one of the most common faults we see. If you already have one, merge your new sender into it with another include: rather than adding a second record.
- →The 10-lookup limit. Each include:, a, mx, exists and redirect costs a DNS lookup, and they nest, so one include can eat several. Go over 10 and the whole record permerrors. ip4:, ip6: and all cost nothing.
- →Subdomains are not covered. Your root SPF record does nothing for mail.yoursite.com. Subdomains need their own record.
- →Do not use the old SPF record type. SPF has its own DNS record type (99) and it is deprecated. Use TXT.
- →Do not guess at includes. If you cannot confirm a vendor's include value from that vendor's own current docs, do not add it. A wrong include still burns a lookup.
The ~all versus -all argument
The last part of your record tells inboxes what to do with mail from servers not on your list. This is where vendors openly disagree, so anyone giving you a single confident answer is skipping the nuance.
~all is softfail, meaning "this is probably not authorised". -all is fail, meaning "this is not authorised". ?all is neutral and does nothing useful.
Google recommends ~all for Workspace. Microsoft recommends -all. Both are right for their own reasons.
Our advice: start with ~all. Watch your DMARC reports until you are sure every legitimate sender is listed. Then move to -all. Going straight to -all before you have found that one forgotten invoicing tool is how legitimate mail disappears.
The exception: a domain that sends no email at all. Use v=spf1 -all and be done.
One thing worth knowing about the industry
The "add our include:" era is ending. Vendors are moving to CNAME-delegated Return-Path subdomains instead. SendGrid Automated Security, Mailchimp and Amazon SES all work this way now. It preserves your 10-lookup budget, which is a real constraint once you have four or five senders.
Practically, this means include values are verify-at-the-time facts, not permanent truths. Check the vendor's current docs rather than an old blog post. Ours included.
Check it worked
Give DNS time to propagate, then test. Our free safety check reports your SPF record along with SSL, security headers and other signals. If you have two records or a lookup problem, that is where it will show up.
Run your site through our free safety check to confirm the fix is live, and see what else a shopper would notice.
Run a free checkFrequently asked questions
Where do I add an SPF record for a Webflow site?
At your DNS host, not in Webflow. Webflow does not provide DNS hosting and says plainly that it does not provide its own nameservers. So your DNS is with your registrar, Cloudflare, or another provider. That is where the TXT record goes.
Can I add SPF in the Webflow dashboard?
No, and not because of your plan. Webflow has no DNS editor at all because it does not host DNS. This is actually simpler than platforms where the answer depends on how your domain is connected.
Do I need two SPF records if I use two email providers?
No, and doing that will break your email. One SPF record per domain is a hard rule. Two records is a permerror. Merge both senders into a single record with two include: mechanisms and one terminal all, for example v=spf1 include:_spf.google.com include:sendgrid.net ~all.
Should I use ~all or -all?
Vendors genuinely disagree. Google recommends ~all for Workspace, Microsoft recommends -all. Start with ~all while you confirm every legitimate sender is in your record, then tighten to -all. If your domain sends no email at all, use v=spf1 -all straight away.
Do I need to add SendGrid's include?
Only if SendGrid Automated Security is turned off. With it on, which is the default, SendGrid uses CNAME-based authentication and no include is needed. Adding it anyway wastes one of your 10 DNS lookups for nothing.