How to set up DMARC for Microsoft 365

To get DMARC working on a domain that uses Microsoft 365, you need three things: an SPF record that includes Microsoft, DKIM signing turned on in the Defender portal with two CNAME records published, and a DMARC record at _dmarc.yourdomain.com. Start the DMARC record at p=none with a reporting address, and do not forget the onmicrosoft.com domain that came with your tenant, which needs a DMARC record of its own.

Step 1: SPF

SPF (Sender Policy Framework) lists the servers allowed to send mail for your domain. For a domain that only sends through Microsoft 365, the record is:

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

Publish it as a TXT record at the root of your domain. A domain can only have one SPF record, so if you already have one for another service, add Microsoft’s include: to it rather than creating a second record. If you use several services, keep an eye on the 10 DNS lookup limit.

SPF alone is not enough for DMARC with Microsoft 365. The SPF check runs against the return-path domain, which Microsoft sets to your domain for normal mail, but forwarding and some third-party routes break it. DKIM is the signature that survives those, so set up both.

Step 2: DKIM

Microsoft signs mail from your domain with DKIM (DomainKeys Identified Mail) once you publish two CNAME records and switch signing on.

1. Open the Microsoft Defender portal and go to Email & collaboration, then Policies & rules, Threat policies, Email authentication settings, and the DKIM tab.
2. Select your domain. The portal shows the two CNAME records to publish, one for selector1._domainkey and one for selector2._domainkey.
3. Publish both CNAMEs at your DNS host, exactly as shown.
4. Back in the portal, turn on Sign messages for this domain with DKIM signatures.

Copy the targets from the portal rather than typing them from a guide. Microsoft changed the format in May 2025: newer custom domains point to something like selector1-yourdomain-com._domainkey.yourtenant.n-v1.dkim.mail.microsoft, while older ones use selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com. The two formats cannot be mixed for the same selector. If you prefer PowerShell, Get-DkimSigningConfig -Identity yourdomain.com | fl Selector1CNAME,Selector2CNAME prints the exact values.

Two details worth knowing:

• Key length. Microsoft’s PowerShell default is a 1024-bit key. You can move to 2048-bit with Rotate-DkimSigningConfig -KeySize 2048. Rotation takes about four days to complete, because Microsoft switches to the idle selector and waits before retiring the old key.
• Why there are two selectors. The pair lets Microsoft rotate keys with no gap: one key signs while the other waits. Our post on finding your DKIM selector explains how to confirm which one is live from a message header.

Step 3: DMARC

With SPF and DKIM in place, publish a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

That turns on reporting without changing delivery. If the rua= address is at a reporting service rather than your own domain, check that the service has authorized your domain to receive reports, or the reports will be silently dropped.

Then follow the usual path: collect a few weeks of reports, fix any sender that fails, and tighten to p=quarantine and then p=reject. We cover that in start with p=none and from p=quarantine to p=reject.

Do not forget your onmicrosoft.com domain

Every tenant comes with a domain like yourtenant.onmicrosoft.com. Microsoft already handles SPF and DKIM for it, but not DMARC: you have to add that record yourself. In the Microsoft 365 admin center, go to Settings, Domains, select the onmicrosoft.com domain, open DNS records, and add a TXT record named _dmarc.

If you never send from that domain, which is true for most organizations once a custom domain is set up, Microsoft’s own guidance is to publish v=DMARC1; p=reject straight away, the same as any domain that sends no mail. We explain why that matters in DMARC for domains that do not send email.

Other senders still need their own setup

Microsoft 365 only authenticates mail it sends. Your marketing platform, CRM, helpdesk and billing system each send as your domain separately, and each needs its own SPF include or, better, its own DKIM records. Your DMARC aggregate reports will show every one of them. A common surprise is that the busiest failing source in the first reports is not Microsoft at all.

How Microsoft treats DMARC on mail it receives

It also helps to know what happens on the receiving side, since Microsoft 365 is one of the biggest receivers your mail will meet. In anti-phishing policies, the setting Honor DMARC record policy when the message is detected as spoof is on by default. With it on, Microsoft’s recommended default actions are to quarantine mail that fails a sender’s p=quarantine policy and reject mail that fails a sender’s p=reject policy. If your tenant’s MX record points to a third-party filtering service first, that only works when Enhanced Filtering for Connectors is turned on.

Microsoft does not send DMARC failure (ruf=) reports, so rely on aggregate reports.

Check your work

Run your domain through the DMARC checker for the policy and SPF, and the DKIM checker with selector1 and selector2 to confirm both keys are published. If anything is missing, the checker says what and why.