AuthPulse

Setup guide
SPF for Microsoft 365

SPF record for Microsoft 365: the exact setup, and the traps

SPF is the DNS record that tells the world which servers may send mail as your domain. If you run Microsoft 365, the record is short. The traps are in what happens when you add sending tools on top of it.

The record

For a domain that sends all mail through Microsoft 365 and nothing else:

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

Add it as a TXT record at your domain root (the host field is usually @ or left blank, depending on your DNS panel). One record, one line. If your registrar has an SPF wizard, skip it and paste the record directly.

What each part means

• v=spf1 - the version tag. Every SPF record starts with it.
• include:spf.protection.outlook.com - "the servers listed in Microsoft's SPF record may send as my domain". Microsoft manages that list, so you never edit it when they change their infrastructure.
• -all - "everything else is not authorized". Hard fail. Receiving providers treat unauthorized senders as spam or reject them.

Why -all and not ~all

~all (softfail) is sometimes recommended as a "safe start". In practice it reads as "probably spam", and Gmail and Outlook weigh it only slightly softer than a hard fail for alignment purposes. If your mail genuinely all goes through M365, -all is correct and there is nothing to be careful about. Use ~all only while you are still discovering forgotten sending systems, and plan to end at -all.

The trap that actually bites: the 10-lookup limit

SPF has a hard limit of 10 DNS lookups per check. The M365 include costs 1 lookup (it resolves to a flat list of Microsoft's IP ranges, with no nested includes), so on its own you are far from the limit. Every sending tool you add next costs at least one more:

• SendGrid, Mailgun, HubSpot, Salesforce, Zendesk: one include: each
• A second M365 tenant or a sister domain: another include chain
• a, mx, exists mechanisms: one lookup each

Past 10 lookups, receivers are required by RFC 7208 to treat your SPF as a permanent error, which most read as fail. Your record still looks fine to you. Your mail degrades. This is the single most common way SPF breaks after it was once working, and it happens exactly when a team adds a new marketing tool.

If you are near the limit, the fix is not a longer record. It is flattening: hosting a static include under your own domain (some DNS providers call this a delegated sender or SPF flattening) or dropping includes for tools you no longer use.

Mistakes we see in scans

• Two SPF records. If any tool "helpfully" added its own v=spf1 record next to yours, receivers must treat the pair as an error. Merge into one record, delete the other.
• +all in the record. This authorizes the entire internet to send as you. Usually a typo someone made while editing; always fatal if it ships.
• No all mechanism at all. The record authorizes Microsoft but says nothing about everyone else, so the test always ends neutral.
• SPF on a subdomain only (mail.yourdomain.com). Receivers query the root domain; the subdomain record is invisible to them.

How to check it landed

After adding the record, run:

dig TXT yourdomain.com +short

You should see exactly one string starting with v=spf1. Then send a test message to an address outside your organisation and inspect the SPF result in the headers: you want spf=pass. DNS propagation is usually minutes but can take up to an hour.

SPF alone is not enough

SPF breaks on forwarding and it says nothing about message integrity. DKIM signs messages so they survive forwarding, and DMARC ties both to a policy that catches spoofing. The three work as a set; if you only fix SPF you have fixed a third of the problem.

Want us to check yours? Email your domain to hello@authpulse.io and you get the full SPF, DKIM and DMARC scan back the same business day, free. If something is broken, we hand you the exact records to fix it.