What are the SPF and MX records for Microsoft 365?

Microsoft 365 (formerly Office 365) routes email through Exchange Online, and to use it with a custom domain you publish a specific set of DNS records: one MX record so mail is delivered to Microsoft, and one SPF record so receivers know Microsoft is authorized to send for you. Microsoft documents the exact values in its Connect your domain by adding DNS records guide.

The Microsoft 365 SPF record

If Microsoft 365 is the only service that sends mail for your domain, publish exactly this as a TXT record on the root of your domain:

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

This is the value Microsoft publishes verbatim. The include:spf.protection.outlook.com mechanism authorizes all of Exchange Online's sending infrastructure, and Microsoft uses -all (hard fail) by default — stricter than Google's ~all, telling receivers to reject anything not explicitly authorized.

Microsoft is explicit about the one-record rule: "If an SPF record already exists for the domain, don't create a new one for Microsoft 365." Instead, merge the Microsoft include: into your existing SPF record so there is a single line with every sender. A domain with two SPF records fails SPF with a permerror. If you send through more than one service, build the combined record with the SPF record generator, and watch the 10-lookup limit — spf.protection.outlook.com expands into several lookups on its own.

The Microsoft 365 MX record

The MX record routes incoming mail to Exchange Online. It is unique per tenant and takes this form:

Type      MX
Host      @
Priority  0   (highest priority — set to the highest value available)
Value     <tenant>.mail.protection.outlook.com
TTL       3600

Replace <tenant> with your domain's MX token, which Microsoft shows you in the Microsoft 365 admin center under your domain's DNS records (it is usually your domain name with dots replaced by dashes, for example contoso-com.mail.protection.outlook.com). Microsoft instructs you to set the priority "to the highest value available, typically 0" — and because lower numbers are higher priority, 0 ensures Exchange Online is the primary mail route. Remove any existing MX records from a previous provider, or set them to a lower priority, so mail does not leak to the old host.

Use the DNS lookup tool to confirm the published MX record matches your tenant value once you have added it.

The Autodiscover CNAME (highly recommended)

Alongside the MX record, Microsoft has you add an Autodiscover CNAME so Outlook and other clients configure mailboxes automatically:

Type   CNAME
Host   autodiscover
Value  autodiscover.outlook.com   (copy the exact value shown in the M365 admin center)
TTL    3600

Microsoft has you copy the Autodiscover target from the Microsoft 365 admin center's "Add DNS records" page — for standard tenants it is autodiscover.outlook.com. It is technically optional, but without it users have to enter server settings by hand, so in practice every Microsoft 365 domain should publish it.

Merging Microsoft 365 SPF with an existing record

This is the single most common SPF mistake when adding Microsoft 365 to a domain that already sends mail elsewhere. You do not add a second SPF TXT record — you merge the Microsoft include: into the existing one. For Microsoft 365 alongside another common provider, the combined record looks like this:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all
v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Every legitimate sender lives on one line, ending in a single all mechanism. Two SPF records is an error that breaks authentication for the whole domain. The SPF record generator assembles a valid merged record and flags if you cross the 10-lookup limit.

DKIM and DMARC for Microsoft 365

SPF and MX get you delivering and receiving, but Microsoft explicitly recommends adding DKIM and DMARC because "some spoofing techniques bypass SPF." DKIM for Microsoft 365 is set up as two CNAME records:

Host   selector1._domainkey   ->  (value from the M365 admin center)
Host   selector2._domainkey   ->  (value from the M365 admin center)

Microsoft rotates between the two selectors automatically. After DKIM is enabled and signing, publish a DMARC policy at _dmarc.yourdomain.com — start with p=none to collect reports, then tighten to p=quarantine and p=reject. The DMARC generator builds a valid record, and the DMARC fundamentals guide explains alignment, which is what actually determines whether your mail passes.

Verify the full Microsoft 365 setup

1. Confirm SPF, the tenant MX, DKIM, and DMARC are all published and aligned with the free email security test.
2. Cross-check the live MX and TXT records with the DNS lookup tool.
3. Review what receiving providers expect on the sender requirements page — Microsoft's own Outlook bulk-sender rules now mirror Google's and Yahoo's.

Once SPF passes, the tenant MX resolves, DKIM signs with an aligned d= domain, and DMARC is published, your Microsoft 365 mail meets every major mailbox provider's authentication bar. See the SPF guide and DKIM guide for the fundamentals behind each record.