Configuring SPF for Microsoft 365 Without Breaking It: The 10-Lookup Limit Nobody Checks

An incorrect or missing SPF record is one of the most common reasons legitimate Microsoft 365 email gets marked as spam or rejected outright by receiving mail servers. Configuring it correctly is straightforward, but there are a handful of details, particularly around DNS lookup limits when you use multiple email services, that trip up otherwise correct configurations. Here is how to set it up properly and avoid the mistakes that cause SPF to silently stop protecting your domain.

What SPF actually does and why it matters

Sender Policy Framework is a DNS TXT record that tells receiving mail servers which hosts are authorized to send email on behalf of your domain. Without a correct SPF record, external recipients see an “SPF fail” or “SPF none” result in message headers, and mailbox providers, Gmail and Yahoo in particular, increasingly reject or quarantine mail that fails SPF rather than just flagging it. This isn’t a minor deliverability nuisance anymore, it can mean legitimate business email simply never arrives.

The correct base record for Microsoft 365

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

Breaking this down: v=spf1 declares the SPF version in use. include:spf.protection.outlook.com authorizes Microsoft’s own outbound mail infrastructure to send on your domain’s behalf, this is the value that actually matters for Microsoft 365 specifically. The trailing -all is a hard fail, telling receiving servers to reject mail from any source not explicitly authorized in the record. Some guidance recommends a softer ~all (soft fail) during initial rollout or testing, but -all is the stronger, recommended setting once you’ve confirmed every legitimate sending source is properly included.

Adding other services without breaking anything

Most real organizations send mail through more than just Microsoft 365, marketing platforms, transactional email services, CRM systems. Each needs its own include statement in the same record, since a domain can only have one SPF record and DNS providers will reject or ignore a second one:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:spf.mandrillapp.com ~all

Get the exact include value from each service’s own documentation, not from a generic template, since these values are specific to each provider and do occasionally change.

The DNS lookup limit that silently breaks SPF

This is the detail that causes real, hard-to-diagnose problems. SPF has a hard limit of 10 DNS lookups per evaluation, defined in the SPF specification itself, not a Microsoft-specific limit. Microsoft 365’s own include:spf.protection.outlook.com consumes roughly 2 to 3 of those lookups on its own. Add a handful of additional services, each with their own nested includes, and it’s genuinely easy to exceed the limit without realizing it.

When an SPF record exceeds the 10-lookup limit, the result is a “permerror,” and many receiving mail servers treat a permerror the same as an outright SPF failure, meaning your domain’s email authentication silently stops working even though the record itself looks syntactically correct. This is worth checking explicitly, not assuming:

# Check your domain's current SPF record directly
nslookup -type=TXT yourdomain.com

# Several free online SPF validators will also count lookups explicitly
# and flag if you're approaching or exceeding the 10-lookup limit,
# worth running any time you add a new service to the record

If you’re approaching the limit, flattening some includes into their actual IP ranges (where the provider supports this) or removing services genuinely no longer in use are the two practical ways to bring a record back under the limit.

SPF alone is not enough

SPF verifies the sending server, but it doesn’t verify message content wasn’t altered in transit and doesn’t protect against display-name spoofing on its own. Configure DKIM (which cryptographically signs outbound messages) alongside SPF, then publish a DMARC record that tells receiving servers how to handle messages that fail both. Start DMARC with a monitoring-only policy (p=none) to observe real traffic without risking legitimate mail being rejected, then move toward p=quarantine and eventually p=reject once you’ve confirmed every legitimate sending source is properly covered by SPF and DKIM.

Frequently asked questions

I updated my SPF record but recipients still report SPF failures. Why?
DNS changes take time to propagate, and receiving servers may cache the old record for a period after your update. Confirm the change actually published correctly with a direct DNS query first, then allow for propagation time before troubleshooting further. If failures persist well beyond normal propagation time, recheck for a syntax error or the 10-lookup limit being exceeded, both are more common causes of persistent failures than propagation delay.

Can I have more than one SPF (TXT) record for redundancy?
No, and this is a common, genuinely harmful mistake. Having multiple SPF records (multiple TXT records starting with v=spf1) causes SPF validation to fail entirely for many receiving servers, since the specification only permits one. If you need to authorize multiple services, add multiple include statements within a single record, not multiple separate records.

Does moving to Microsoft 365 automatically create the SPF record for me?
No, SPF is a DNS record you (or whoever manages your domain’s DNS) must create and maintain manually, Microsoft doesn’t configure it on your behalf during tenant setup. This is precisely why so many organizations end up with missing or incomplete SPF records, it’s an easy step to overlook during a busy migration, verify it explicitly rather than assuming it’s handled.