How to set up an SPF record in Microsoft 365

A Sender Policy Framework (SPF) record tells receiving mail servers which servers are allowed to send email for your domain. In Microsoft 365, getting it right is what keeps your legitimate mail out of spam folders and makes it harder for anyone to send email that looks like it came from you.

The mechanics of SPF records are simple. The rules around them are where admins get caught: the one-record requirement, the 10 DNS lookup limit, and what happens when you add another tool that sends on your behalf.

Third-party email signature tools fall into two camps, and only one of them touches your SPF record. A tool that applies email signatures through Microsoft’s own mail flow doesn’t add a sending domain, so it doesn’t need its own include: entry. One that routes mail through its own infrastructure does, and on a record with a hard lookup limit, that difference adds up. 

Most organizations haven’t covered the basics yet. Fewer than one-third have implemented SPF, DKIM, or DMARC, according to Exclaimer’s State of Business Email 2025 research, so setting yours up properly already puts you ahead. This guide covers how to create, configure, and validate an SPF record in Microsoft 365, how to stay under the lookup limit, and how third-party tools affect what you publish.

v=spf1 include:spf.protection.outlook.com -all 

What is SPF, and why does it matter? 

SPF is a DNS record that lists the mail servers authorized to send email for your domain. When a receiving server gets a message claiming to be from you, it checks your SPF record to confirm the sending server is on the approved list. If it is, the message passes. If it isn’t, the receiving server can treat the message as suspicious or reject it. 

Two things ride on this. The first is deliverability: mail that fails SPF is far more likely to land in spam, or never arrive. The second is that it makes your domain harder to impersonate, because a message sent from an unapproved server won’t pass the check. 

An SPF record lives in your DNS as a TXT record, written in a specific syntax. A basic one for a Microsoft 365 domain looks like this: 

v=spf1 include:spf.protection.outlook.com -all 

That tells receiving servers to accept mail from Microsoft 365’s sending infrastructure and reject the rest. 

How SPF, DKIM, and DMARC fit together 

SPF rarely works alone. It’s one of three standards that verify your email is genuine, and each does a different job.

SPF confirms which servers can send for your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature that proves a message wasn’t altered in transit. DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties the two together and tells receiving servers what to do when a check fails. 

Starting with SPF is sensible, and you can run it on its own. But the three are built to work as a set, which is why most organizations implement all of them. For more information, see our DKIM setup guide.

How to set up an SPF record in Microsoft 365

Setting up SPF takes four steps: find everything that sends mail for your domain, build a single record that lists it, publish that record in DNS, and set a sensible refresh time. 

1. Identify your sending sources 

List every service that sends email on your domain’s behalf. For most Microsoft 365 organizations that’s Exchange Online, but it usually includes more: a CRM, a marketing platform, a helpdesk or ticketing system, and an invoicing tool. Each legitimate source has to be accounted for, or its mail risks failing SPF. 

2. Build your SPF record 

Start with the Microsoft 365 include and add any other senders. Microsoft 365 is represented by include:spf.protection.outlook.com. A marketing platform or CRM will publish its own include value in its documentation. The record then ends with an allmechanism, covered in the example below.

3. Publish it in DNS 

Add the record as a TXT record at the DNS host for your domain, on the root domain (often shown as @). You do this at your DNS provider, not inside Microsoft 365, though the Microsoft 365 admin center shows you the value it expects. 

4. Set the TTL 

Time to live (TTL) controls how long servers cache your record before checking again. An hour (3600 seconds) is a reasonable default. Lower it temporarily before making changes, so updates propagate faster. 

What does a valid SPF record look like?

Here’s an SPF record for a Microsoft 365 domain that also sends through a marketing platform: 

v=spf1 include:spf.protection.outlook.com include:_spf.marketingtool.com -all 

Reading it left to right: v=spf1 declares the record version. Each include: authorizes another sender's servers, here Microsoft 365 and the marketing platform. The closing -all is a hard fail, telling receiving servers to reject mail from any source not listed. A ~all (soft fail) is the more cautious alternative, marking unlisted mail as suspicious rather than rejecting it.

Why you can only have one SPF record

A domain can have exactly one SPF record. Publishing two TXT records that both start with v=spf1 doesn't combine them. It breaks SPF, and receiving servers return a permanent error.

This catches people out when a new tool's setup guide says to add an SPF record, and they create a second one instead of editing the existing entry. If you're adding a sender, add its include to the record you already have.

What is the SPF 10 DNS lookup limit, and how do you fix it?

A single SPF record can trigger no more than 10 DNS lookups when a receiving server evaluates it. Every include:, along with a few other mechanisms like a and mx, counts as a lookup, and some includes contain nested includes that count too. Go over 10 and your record returns a permerror. SPF stops validating, and your authentication effectively fails.

It's easy to breach this without realizing. One Microsoft 365 include is fine, but add a marketing platform, a CRM, a helpdesk, and a couple of other services, and each can bring nested includes of its own. A record that appears to list four senders can resolve into well over 10 lookups.

Three things keep you under the limit:

1. Remove unused includes. The quickest win and worth auditing every so often as tools come and go.
   
   

2. Consolidate senders. The fewer separate infrastructures your mail routes through, the fewer lookups you accumulate.
   
   

3. Flatten the record. SPF flattening replaces include mechanisms with the actual IP addresses they resolve to, removing those lookups entirely.

Flattening works, but it has a maintenance cost. When a provider changes the IP ranges behind its include, a flattened record won't update automatically the way an include: would. You either re-flatten manually or rely on a service that keeps the record current.

How email signature tools affect your SPF record 

Whether an email signature tool touches your SPF record comes down to one thing: where your mail is sent from. 

Some tools route your outbound mail through their own servers to add the signature, then send it on. Because the mail now originates from their infrastructure, you have to add their include: to your SPF record. That consumes one of your 10 lookups, sometimes more if their include is nested inside others.

Exclaimer's Microsoft 365 solution applies signatures within Microsoft's own mail flow. Your outbound mail is routed there for processing, then handed back to Microsoft 365 for delivery, so the final connection to the recipient still comes from Microsoft 365's sending infrastructure, the same include:spf.protection.outlook.com you already have. There's no extra sending domain to authorize and no additional lookup to account for. For an admin managing a tight lookup count, that's one fewer thing on the record.

The same holds for DKIM. When a server-side signature is applied, the original DKIM signature is stripped during processing, and Microsoft 365 re-signs the message before it goes to the recipient, so it arrives correctly authenticated. Because Microsoft 365 handles final delivery, the outbound mail comes from its infrastructure rather than a separate sending domain.

For the specifics, see Exclaimer’s documentation on DKIM behavior with server-side signatures. 

How to test and validate your SPF record 

Confirm the record works before you rely on it. Three checks cover most cases. 

• Run it through an SPF validation tool. Free checkers like MXToolbox and dmarcian parse your published record and show a live count of the DNS lookups it triggers. This is the fastest way to confirm your lookup count stays below 10 and that each entry resolves correctly. 

• Send a test message and read the headers. Send an email from your domain to an external account, then view the message headers (in Gmail, “Show original”; in Outlook, “View message source”). Find the authentication-results line and check that it reads spf=pass. That confirms the record holds up in a real delivery, not just in a checker.

• Check the envelope sender. SPF validates the envelope sender (the Return-Path), which isn’t always the address your recipient sees in the From field. If SPF passes but DMARC still fails, a mismatch between those two domains is a common cause.

Common SPF misconfigurations and how to diagnose them 

Most SPF problems trace back to a handful of mistakes.

More than one SPF record 

A domain can have only one. If you've published two TXT records starting with v=spf1, receiving servers return a permerror and may skip SPF entirely. List your domain's TXT records in a checker; if two SPF entries show up, merge them into one.

Too many DNS lookups 

Once your record passes 10 lookups, it returns a permerror and stops validating. A validation tool shows the count and flags the entry that tips you over. Remove unused includes or flatten the record to bring it back under. 

The wrong all mechanism

This is where intent and configuration drift apart. ~all (soft fail) marks unlisted mail as suspicious but still accepts it, which is sensible while testing. Many records stay on ~all long after the admin assumes they’re strictly enforcing with -all (hard fail). And +all authorizes anyone to send for your domain, undoing the record entirely. Check that the mechanism matches what you think you’ve set. 

A missing include 

If legitimate mail from a known service is failing SPF, its sending servers probably aren’t in your record. Confirm the correct include value in the service’s documentation and add it. This tends to surface after a new tool is onboarded and nobody updates DNS. 

Syntax errors 

A stray space, a mistyped include, or a missing v=spf1 prefix can break the whole record. A validation tool catches most syntax issues and points to the entry at fault. 

The pattern across all of these: when a record fails, read the checker’s output instead of guessing. A permerror points to structure (too many lookups, duplicate records), while a softfail or outright failure usually points to a sender that isn’t authorized yet. 

How do you keep your SPF record accurate as your setup changes?

An SPF record reflects your sending setup at a moment in time, and that setup keeps changing. Add a tool that sends mail, switch providers, or retire a service, and the record should change with it. The ones that cause problems are usually the records nobody has looked at since the day they were published.

Tool sprawl is what makes this hard. Each sending service is another include, another set of lookups, another entry to keep current. Audit your record against what your organization actually uses, and strip out anything that’s no longer sending. 

That upkeep adds up. In Exclaimer’s State of Business Email 2025 research, 35% of IT teams said email signature management was one of their two most time-consuming tasks, while only 18% had moved to centralized management. Choosing tools that work within your existing Microsoft 365 mail flow, instead of adding sending domains and lookups, keeps the maintenance burden lower. 

Go wider: Our MX record guide explains the records that route your mail in the first place. 

Managing email signatures in Microsoft 365

SPF, DKIM, and DMARC handle the authentication layer: confirming that your mail is genuine and that your domain is only being used by authorized infrastructure. That's the foundation. Once it's in place, the next piece most Microsoft 365 admins turn to is what those authenticated emails actually contain.

Email signature management is where that authentication work pays off or gets undermined. Consistent, correctly formatted signatures reflect the organization you've worked to protect. Inconsistent ones, updated individually with no central control, undermine that.

Our Microsoft 365 email signature management guide covers the full process: what Microsoft 365 natively supports and how centralized management handles it at scale.