Defaults.Exposed › Setup walkthroughs › DMARC › Microsoft 365

Set up DMARC on Microsoft 365

There is no DMARC (Domain-based Message Authentication, Reporting and Conformance) toggle inside Microsoft 365. Searching the admin centre’s own settings for a DMARC option finds nothing, because the record lives in DNS (Domain Name System) rather than in a mailbox setting. Microsoft does have a DKIM (DomainKeys Identified Mail) screen with a toggle on it, which is why people reasonably assume there is a DMARC one too.

The DMARC record for Microsoft 365

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

The record opens on v=DMARC1, which is mandatory and must be first. p=none is the policy, and it asks for no change in how any message is handled. rua=mailto: is the mailbox receivers send their aggregate reports to.

Microsoft 365 publishes nothing for DMARC on its own. The record is typed into a DNS records page, and Microsoft’s only role is hosting that page when Microsoft happens to run the domain’s nameservers.

Find out who holds the DNS

Check the Nameservers section in the registrar account to see which company answers DNS for the domain. If Microsoft 365 is the DNS host, the record goes in the Microsoft 365 admin center under Settings, then Domains, then DNS records. If another company runs the nameservers, the record goes in that company’s DNS settings instead, usually under a menu labelled DNS, Records, or Advanced DNS.

Microsoft 365 runs the mailboxes for the domain. The DMARC record is added wherever the domain’s DNS lives, which may or may not be Microsoft.

Add the record

1. Sign in to the DNS host, which is the Microsoft 365 admin center only if Microsoft runs the domain’s nameservers.
2. Open the domain’s DNS settings, usually labelled DNS, Records, or Advanced DNS.
3. Add a new record and choose the record type TXT.
4. In the Name or Host field, enter exactly _dmarc, keeping the leading _ character.
5. Do not type _dmarc.yourdomain.com in that field, since the DNS host appends the domain automatically.
6. In the Value or Content field, paste v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, replacing the email address with a mailbox that is read.
7. Paste the value unquoted, since most DNS hosts add the surrounding quoting themselves.
8. Leave the TTL (Time to Live) field at the host’s default setting.

The Name or Host field takes _dmarc exactly, with the leading _ character and nothing appended, since the DNS host adds the domain itself. The Value or Content field takes the full record string starting v=DMARC1;, pasted without surrounding quotes.

Traps specific to this setup

• Leaving off the _ character in _dmarc, or typing the full domain after it, puts the record at the wrong host name and the DMARC check will not find it.
• Exactly one TXT (Text) record should exist at _dmarc. Where one is already present, edit it rather than adding a second.
• A DMARC record published before SPF (Sender Policy Framework) and DKIM are working can get the domain’s own legitimate mail blocked once the policy tightens beyond p=none.
• The rua address must be a mailbox that someone reads, otherwise the reports arrive nowhere.

What the reports show on a Microsoft tenant

Three sources turn up in nearly every Exchange Online tenant’s reports, and each has a different answer.

Microsoft’s own outbound servers should pass cleanly, on SPF via include:spf.protection.outlook.com and on DKIM via the two CNAMEs (Canonical Name records) and the signing toggle. If Microsoft’s own traffic is failing, one of those is missing, and the SPF and DKIM records are where to look before anything else.

Next is anything relaying through the tenant: an on-premises server, a line-of-business application, a scan-to-email function on a printer, all configured with a connector or SMTP (Simple Mail Transfer Protocol) AUTH. Those send through Microsoft, so they inherit Microsoft’s authentication and generally pass.

Last is the group that fails: services sending as your domain from their own infrastructure. A CRM, a campaign tool, an e-signature platform. Each needs its own DKIM key signed on your domain so it aligns, or at minimum an SPF include, and the report tells you which are doing neither.

Alignment is the concept that explains most confusing rows. DMARC passes when SPF or DKIM passes and the domain it passed for matches the From domain a reader sees. A platform can pass SPF on its own domain and still fail DMARC on yours, which is why adding an include does not always fix what the report is showing you.

Stepping the policy up

p= takes three values. none changes nothing and asks for reports. quarantine asks receivers to treat failures as suspicious. reject asks them to refuse the message outright.

Use pct= to get between them rather than jumping. v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com applies quarantine to a quarter of failing messages and leaves the rest alone, so anything you missed shows up at a quarter of the scale while the reports keep telling you what happened. Raise the figure over a few weeks, then drop the tag and move to reject.

Two tags matter later. sp= sets a separate policy for subdomains, which is useful when a campaign platform or a transactional service sends from one and is not ready for the parent’s policy. adkim= and aspf= decide whether alignment is relaxed or strict, and relaxed is the sensible default because it lets a subdomain satisfy the parent.

One Microsoft-specific caution. Tenants frequently have an on-premises relay, a printer or a line-of-business application configured years ago and forgotten. Those usually send through Exchange Online and are fine, but anything configured to send directly is not, and it will be the thing that breaks the day you publish p=reject. The reports name it well before then.

Wait, then read the result

Once saved, the change can take from minutes up to a couple of hours to be visible everywhere. The saved record appears back in the same DNS records list it was added to, whether that list sits in the Microsoft 365 admin center or in another provider’s DNS settings.

How the scan grades this record: the DMARC policy check, with its pass and fail rules and how many domains pass it.

For scale: 249,025,625 domains (74.9%) in the October 2026 census publish no DMARC record at all, and of the ones parked at p=none, 35,049,364, or 80.17%, have no rua= address to collect anything.

Once a fortnight of reports shows nothing failing that should not be, step the policy up to p=quarantine, then to p=reject. Receivers act on the record only at p=quarantine or p=reject.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.