SummaryUse the Microsoft SPF value for your environment, account for every actual outbound route and update the existing TXT policy. Verify external messages after the change.
In this guide
The standard Microsoft 365 SPF record
For a custom domain whose only outbound source is commercial Exchange Online, Microsoft publishes this SPF value:
v=spf1 include:spf.protection.outlook.com -allPublish SPF as a DNS TXT record at the appropriate domain name. It is not an Exchange transport rule or an MX record. Microsoft documents different values for some sovereign cloud environments, including GCC High, DoD and Microsoft 365 operated by 21Vianet. Use the value for your environment from Microsoft’s SPF setup guidance.
The standard example authorises Microsoft’s specified sending infrastructure and gives unlisted senders an SPF fail result. It does not prove that a website, scanner or invoicing service sends through that infrastructure.
Find every outbound route before editing DNS
Build a short inventory of actual workflows: a user sending in Outlook, an application sending an invoice, a website submitting an enquiry and any bulk or automated sender. For each one, record:
- The system or account owner who can explain how it sends.
- The final outbound service or gateway that connects to external recipients.
- The visible From domain and the envelope-sender domain shown in received headers.
- The provider’s account-specific authentication instructions.
An app using authenticated submission through Microsoft 365 can have a different SPF requirement from an app delivering directly from its own SMTP server. Similarly, an outbound security gateway can become the IP address the recipient evaluates. Verify the route; the presence of an Outlook mailbox does not answer that question.
Adding a third-party sender
Suppose a fictional invoice service really uses studio.example as its envelope-sender domain and instructs the owner to authorise invoice.example. An illustrative combined policy is:
v=spf1 include:spf.protection.outlook.com include:invoice.example -allUpdate the existing SPF TXT record at that name. Publishing the service’s complete SPF value as a second record would create a duplicate-policy error.
If the service instead uses bounce.studio.example, follow its instructions at that subdomain. If it uses a provider-owned envelope domain, an extra root-domain include may not be needed. Set up the service’s custom DKIM or return-path configuration as appropriate, then test DMARC alignment. The visible From address alone is insufficient to decide where an SPF change belongs.
A hybrid Exchange deployment or a third-party gateway deserves a route-specific policy review. Avoid adding every IP address that appears in a Received header: internal hops are not necessarily the servers connecting to the final recipient.
Publish the record at your authoritative DNS host
- Find the active DNS provider. It may differ from the registrar where the domain was purchased. Confirm which nameservers serve the domain.
- Save the current configuration. Record the exact TXT name, value and TTL. Keep the workflow inventory with this baseline.
- Edit the relevant SPF policy. Many DNS interfaces use
@for the zone’s root; others expect a blank field or the full domain. Follow that host’s naming convention. - Inspect the published answer. Confirm there is one SPF policy at the intended name. Watch for a domain suffix appended twice.
- Allow for caching and test fresh messages. Save the time of each test so it can be compared with the change.
On Windows, this read-only PowerShell command can show the TXT records returned by your configured resolver. Replace the placeholder with your domain:
Resolve-DnsName -Name studio.example -Type TXTDiagnose common Microsoft 365 SPF results
| Result | What to investigate |
|---|---|
none | Check the actual evaluated domain and whether it publishes SPF. |
permerror | Inspect duplicate policies, syntax, references and lookup limits. |
temperror | Investigate temporary DNS resolution failures before rewriting the policy. |
fail or softfail | Compare the connecting IP and sending route with the intended authorisations. |
| SPF pass, DMARC fail | Check alignment and DKIM; adding another Microsoft include is not an alignment fix. |
These results are distinct; retain the exact diagnostic text. See Microsoft’s authentication troubleshooting reference and our lookup-limit walkthrough.
Finish with DKIM, DMARC and real-message tests
Send to an external mailbox you control from each important workflow. Inspect the authentication results added by that receiving system. Record the SPF result and smtp.mailfrom, the DKIM result and signing domain, and the DMARC result. Microsoft’s message-header reference explains these fields.
Configure and verify custom-domain DKIM using Microsoft’s current DKIM instructions. Read why DMARC can fail when SPF passes if the results do not align. A successful message test is evidence for that route and time; test the other workflows before closing the change.
For ongoing SPF maintenance, Microsoft 365 is included in Emailmetry’s launch plans. Review compatibility and pricing, then register interest if the service suits your setup.