How do I check the SPF record for my Office 365 domain?

Two places, and you need both. The Microsoft 365 admin center under Settings, Domains, your domain, DNS records tells you the value Microsoft expects. Then query the TXT records of the domain from outside your network to see what receivers actually get. The admin center only confirms its own value is present; it does not evaluate the rest of the record or count your DNS lookups.

Can I have two SPF records if I use Office 365 and a marketing tool?

No. Microsoft states that only one SPF record is allowed per domain or subdomain, and a receiver that finds two ends the evaluation in a permanent error. Merge both senders into a single record, for example v=spf1 include:spf.protection.outlook.com include:_spf.yourtool.com -all.

Should the Office 365 SPF record end in -all or ~all?

Microsoft recommends -all (hard fail) for Microsoft 365 domains, on the basis that you also run DKIM and DMARC. Soft fail with ~all asks receivers to accept and mark the message, which is a reasonable place to sit for a week while you are still finding senders, not a permanent setting.

How to check your SPF record in Office 365: the exact value

A 14-person insurance brokerage calls us on a Monday. Their quotes stopped reaching Gmail addresses on Friday. Nothing changed, they say. Then someone remembers that marketing signed up for a newsletter tool three weeks ago, and whoever set it up pasted a line into DNS because a support article said to.

That is the shape of most SPF problems in a Microsoft 365 tenant. The record was correct the day the domain was connected. Then the business grew, added a sender, and nobody counted what it cost. Here is the check we run first on a client domain, the order we repair it in, and the traps that keep showing up in Microsoft 365 specifically.

Where Microsoft tells you what to publish

Start in the Microsoft 365 admin center. Microsoft's own domain setup documentation sends you to Settings, then Domains, then your domain, then the DNS records view, where the values your tenant expects are listed. That page is useful for one thing: it tells you what Microsoft wants present.

It is not a verdict on your record. The admin center checks that its own value is there. It does not evaluate the rest of the record, it does not count your DNS lookups, and it will happily show a green state on a record that fails at the receiving end. So read the admin center for the required value, then go and look at what the internet actually returns for your domain: query the TXT records of the domain itself, from outside your network.

; what a receiving mail server reads for your domain
example.com.   3600   IN   TXT   "v=spf1 include:spf.protection.outlook.com -all"

That single line is the whole published policy for a tenant that sends only through Exchange Online. Microsoft documents that exact value as the SPF record for Microsoft 365.

What each part of the record is doing

v=spf1 marks the record as SPF. Anything in your TXT set that does not start with this is not an SPF record, whatever it looks like.

include:spf.protection.outlook.com points at the hostname Microsoft maintains, which holds the sending sources for Exchange Online. You never list Microsoft's IP addresses yourself; the include is how you stay current when Microsoft changes them.

-all is the qualifier for everything else. Microsoft's SPF guidance for Microsoft 365, in the version of that page dated 3 July 2026 and checked on 21 September 2026, recommends hard fail: "For Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain." The softer ~all asks receivers to accept but mark the message, which is a reasonable place to sit for a week while you are still discovering senders, and a bad place to live permanently.

Two structural rules matter more than the syntax. First, in Microsoft's words, "only one SPF record is allowed per domain or subdomain." Second, SPF authorises the envelope sender, the address used in the SMTP conversation, not the From address your recipients read in their mail client. Microsoft's documentation is blunt about the gap: SPF makes no attempt to match the envelope domain and the From domain. DMARC is the piece that requires them to line up. A domain can pass SPF and still fail DMARC, which is why an SPF fix alone sometimes changes nothing.

Adding a second sender without breaking the record

This is where the brokerage went wrong, and it is the single most common self-inflicted wound we see. Their DNS ended up holding two separate SPF records:

; broken: two SPF records on the same name
example.com.   TXT   "v=spf1 include:spf.protection.outlook.com -all"
example.com.   TXT   "v=spf1 include:_spf.newslettertool.com ~all"

A receiver that finds two records cannot choose between them, so the evaluation ends in a permanent error and both senders lose the benefit. Microsoft's guidance for domains that already have a record is to add the Microsoft value to the existing record rather than publish a second one. The repaired version is one record with both senders in it:

; correct: one record, both senders
example.com.   TXT   "v=spf1 include:spf.protection.outlook.com include:_spf.newslettertool.com -all"

Before you add anything, get the include string from the vendor's own documentation. Support forum answers go stale, and an include pointing at a hostname the vendor retired is a lookup you are paying for with nothing in return.

Counting lookups, and why flattening is the last resort

SPF has a hard ceiling. RFC 7208 section 4.6.4 limits an evaluation to ten terms that require a DNS query, and an implementation that goes past it must return a permanent error. Microsoft states the consequence plainly: "If the number of DNS lookups is greater than 10, the message fails SPF with a permanent error."

The terms that cost a lookup are include, a, mx, ptr, exists and the redirect modifier. The ones that are free are ip4, ip6 and all, because the answer is already in the record.

The trap is that an include is not one lookup. It costs one query for itself plus every query the record it points to performs, all the way down. Microsoft's include resolves to a record that contains further includes, and several marketing and CRM platforms do the same. Do not assume a number for any vendor. Measure your own record as published, because your total is the only one that matters.

Paste your domain in and see what a receiver sees before you touch DNS:

When the count comes back over ten, work in this order. Each step is safer than the one after it.

Delete includes for services you no longer use. On a domain that has been running since 2018 this alone usually clears the overage. The old CRM, the trial of a helpdesk, the invoicing tool that was replaced two years ago.
Remove leftover a and mx mechanisms. These are often a souvenir of the shared hosting the domain lived on before the move to Microsoft 365. If that host no longer sends your mail, they are two free lookups back.
Move a noisy sender to a subdomain. Let invoicing send as bills.example.com with its own SPF record and its own lookup budget. This costs you a conversation with the vendor about the envelope domain, and it is the most durable fix on this list.
Replace an include with published IP ranges, and only where the vendor commits to stable addresses in writing. ip4 entries are free of lookups and they are also frozen in time, so this step comes with a calendar reminder to re-check, not without one.
Lean on DKIM for what is left. A sender that signs with DKIM aligned to your domain passes DMARC without being in the SPF record at all. For a marketing platform that is usually the cleaner answer.

Automated flattening services, which expand every include into a list of addresses and keep it updated, sit outside that list on purpose. They work until the vendor moves an IP address and the refresh does not happen, and then mail fails on a Saturday with no obvious cause. We use them only where a client has no other route, and never without monitoring.

Verify with a real message, not only with a checker

A syntax checker tells you the record parses. It does not tell you that your invoicing app passes. So send a real message from every system that uses your domain, to a Gmail address and to an Outlook.com address, and read the headers of what arrives.

In the Authentication-Results header you want three things: spf=pass with an smtp.mailfrom that belongs to your domain, dkim=pass, and dmarc=pass. If SPF passes but DMARC does not, the envelope domain is the vendor's and the From domain is yours, and no amount of SPF editing will fix it. Our header analyzer will break a pasted header down if you would rather not read it by eye, and the long version of that skill is in our guide to reading email headers to find why a message went to spam.

Both large receivers now expect this. Google's sender guidelines require every sender to set up SPF or DKIM, and require SPF, DKIM and DMARC together from anyone sending more than 5,000 messages a day to personal Gmail accounts, alongside a spam complaint rate under 0.3 percent and one-click unsubscribe on marketing mail. Microsoft published matching requirements for high-volume senders to Outlook.com, Hotmail.com and Live.com, enforced from 5 May 2025, with non-compliant mail routed to Junk first. Neither rule is new, and both are worth checking against before you decide your record is done.

The traps we hit most often in Microsoft 365 tenants

The record on the wrong name. SPF belongs on the domain that appears in the envelope sender. We regularly find it published at spf.example.com or _spf.example.com, where no receiver will look.
Subdomains with no record of their own. If a subdomain sends mail and publishes nothing, receivers do not inherit the parent's SPF record. Each sending subdomain needs its own.
Scan-to-email and line-of-business apps. The multifunction printer and the practice management system relay into Exchange Online using your domain, and they are invisible until a DMARC report shows them failing. Inventory them before you tighten anything.
The record split badly across strings. A DNS TXT record holds strings of up to 255 characters each. Long SPF records have to be split, and some DNS panels do it in a way that inserts a space or drops a character. Always re-read the published value after saving.
~all with no DMARC behind it. Soft fail without a DMARC policy is close to no policy at all. If you are staying on ~all, publish DMARC and read the reports, then tighten both.

If you are working on a Microsoft 365 domain from scratch rather than repairing one, our Microsoft 365 SPF, DKIM and DMARC setup checklist covers all three records in order, and the DMARC record for Office 365 guide handles the policy ramp afterwards. If the lookup count is the whole problem, the deeper version lives in fixing SPF too many DNS lookups.

How Guanacos Tech helps

We do this for small and mid-sized companies in North America and Latin America, usually in a single session: inventory every system that sends as your domain, rebuild the record into one line that passes and stays under the limit, confirm alignment with real messages at Gmail and Outlook, then watch the DMARC reports for a month to catch the sender nobody mentioned. If you would rather hand it over, our email deliverability consulting for small business starts with a short call to look at your current record and tell you what is actually broken.

The Office 365 SPF record: how to check it, update it, and stay under 10 lookups