The SPF record for Microsoft 365 or Google Workspace

The short version

• Microsoft 365: v=spf1 include:spf.protection.outlook.com -all
• Google Workspace: v=spf1 include:_spf.google.com ~all
• One TXT record, host @, at whichever company runs your domain’s DNS.
• Other senders go into the same record, before the all at the end.
• Check it from outside after saving, and allow up to 48 hours.

Which record do I use?

These come straight from each provider’s own page, checked on October 31, 2026.

If you use a mailbox provider not listed here, use the exact value from its own setup page. Don’t guess an include. A misspelled one fails, and Microsoft’s page notes that an include that doesn’t resolve makes the whole check return an error.

How do I add it?

1. Find where your DNS is managed. Look up your domain at ICANN Lookup and read the name servers. That company is where the record goes, even if you bought the domain somewhere else.
2. Check for an existing SPF record. Open the DNS records and look for a TXT record whose value starts with v=spf1. If one exists, you’ll edit it. Don’t add a second.
3. Create or edit the TXT record.
   • Type: TXT
   • Host or Name: @ (some providers want it left blank, or want the domain name itself)
   • Value: the record from the table above
   • TTL: Microsoft recommends at least 3600 seconds (one hour)
4. Save it, then check it from outside with our email deliverability checker.
5. Send a test from your mailbox to a personal Gmail address. Open the message, choose Show original, and look for SPF: PASS.

Google says changes can take up to 48 hours. Microsoft adds that there’s nothing to switch on in Microsoft 365 itself. SPF lives only in DNS.

Should it end in -all or ~all?

The ending tells receivers what to do with mail from servers that aren’t listed.

• -all (hard fail): unlisted servers aren’t allowed. Microsoft recommends this for Microsoft 365 domains, because it lets DMARC act on spoofed mail that has no DKIM signature.
• ~all (soft fail): unlisted servers probably aren’t allowed, so accept but treat with suspicion. Google recommends this for Workspace.
• ?all or +all: neutral or “anyone may send.” Don’t use either on a business domain.

Both providers are right for their own setups. Once DKIM and DMARC are in place, DMARC decides what happens to failing mail, and the difference between the two endings matters much less. Our working rule: use ~all while you’re still discovering every service that sends for you, then move to -all once your DMARC reports show nothing legitimate failing. That’s E-3’s judgment, not a rule from either provider.

Why does SPF matter?

SPF is the simplest of the three checks, and Gmail and Yahoo require at least SPF or DKIM from every sender. Without it, receivers have no list of servers allowed to send for you. Unlisted servers include a spammer pretending to be you, and also your own website if nobody added it. SPF alone isn’t enough, though. It checks the hidden “envelope” sender, not the From address your customer sees, which is why DKIM and DMARC matter too.

What are the common mistakes?

• Two SPF records. Microsoft’s page says multiple SPF records for the same domain make SPF return a permanent error. Merge them into one.
• Typos that look right. Microsoft lists the usual ones: a trailing dot after the domain, include= instead of include:, and a space after the colon.
• Forgetting other senders. Your website, newsletter tool, invoicing system and CRM may all send as your domain. Each needs either an include in SPF or its own DKIM setup.
• Too many includes. SPF allows at most 10 DNS lookups per check. Any mail whose check needs more gets an error instead of a pass, and that can include your everyday mail. See adding tools without breaking SPF.
• Assuming subdomains are covered. They aren’t. Microsoft notes that news.yourbusiness.com needs its own SPF record if it sends mail.
• Leaving an old provider in the record long after you moved. It doesn’t break anything, but it lets a server you no longer control send as you.

What if SPF still fails?

• Check what the receiver saw. In the message headers, the Authentication-Results line names the server that sent it. If that’s your web host or a tool you forgot, add it, or better, send that mail through your provider. See making your website send email properly.
• Look for “permerror”. That usually means two records, a typo or more than 10 lookups.
• Forwarded mail fails SPF by design, because the forwarding server isn’t on your list. That’s normal, and DKIM is what carries it through.

How long does it take?

Editing the record takes a few minutes. It’s free, since it’s part of your domain’s DNS. Allow up to 48 hours for every resolver to see the change, though it’s often much quicker. Our answer on why DNS changes take time explains why.

How does E-3 handle this?

Most SPF problems we fix aren’t exotic. A second SPF record added by a new tool. Curly quotes pasted from a document that turned into odd characters in DNS. ipv4: typed where SPF needs ip4:. A web server whose IP address changed, so form mail it was allowed to send suddenly failed. Before we change a client’s DNS records, we save a copy of the existing ones. Our free email deliverability checker shows what your domain publishes today.

Related questions

• How do I turn on DKIM in Microsoft 365 or Google Workspace?
• How do I move DMARC from none to reject safely?
• How do I change DNS records without breaking my email?
• What is DNS, and why does it affect my email and website?
• Back to the complete guide to business email that lands

Sources

1. Set up SPF to identify valid email sources for your Microsoft 365 domain (Microsoft Learn)
2. Set up SPF (Google Workspace Admin Help)
3. RFC 7208: Sender Policy Framework (SPF) (IETF)