Set Up DMARC on Microsoft 365: The Records, the Rollout, and the Gotchas

You open the Microsoft 365 admin center to switch on DMARC for your company domain, and the setting is not there. There is no toggle, no wizard, and no PowerShell cmdlet either. That is by design rather than an oversight, and understanding why is the fastest route to setting it up correctly, because it tells you where the record actually lives and who owns it.

Microsoft manages authentication for domains it controls. Your custom domain is not one of those, so the DMARC record for it belongs at your registrar or DNS host, alongside your SPF and DKIM records. Microsoft's own documentation is explicit that no admin portal path and no cmdlet manages DMARC for custom domains.

The two places a record can live

There is exactly one domain in your tenant that Microsoft does manage, and it is the one most rollouts forget about.

Your custom domainCreated at your DNS host

• No admin portal path and no PowerShell cmdlet
• TXT record published at your registrar or DNS provider
• Hostname is _dmarc, which is required
• Same place your SPF and DKIM records already live
• You own the change and the rollback

Your onmicrosoft.com domainCreated in the admin center

• Settings, then Domains, then the domain, then DNS records
• Add record, type TXT, name _dmarc
• Value v=DMARC1; p=reject
• TTL one hour
• Microsoft hosts the zone, so the record is created in the portal

The onmicrosoft.com domain deserves a moment because it is easy to dismiss as internal plumbing. It is a real sending identity, and it does not cover your brand domain. In Microsoft's own alignment examples, a message with a From address of user@contoso.com authenticated against contoso.onmicrosoft.com fails alignment under both relaxed and strict modes. So mail that authenticates as the onmicrosoft domain is doing nothing for contoso.com, and that domain needs a policy of its own.

What goes in the record

The record is a TXT record on the hostname _dmarc. Microsoft documents the basic form as v=DMARC1; followed by a p= policy value of none, quarantine or reject, an optional pct= between 0 and 100, and rua=mailto: and ruf=mailto: addresses for reports.

Two notes on that shape before you publish it.

The pct= tag is where Microsoft's documentation and the current specification disagree, and it is worth knowing rather than discovering later. Microsoft's page still recommends percentage staging and still cites RFC 7489. The IETF published RFC 9989, 9990 and 9991 on 20 May 2026, obsoleting RFC 7489, and in that revision pct= is deprecated along with rf= and ri=. Both statements are accurate. Deprecated tags are ignored rather than rejected, so nothing breaks, but a new rollout is better staged by domain and by time than by percentage. The reasoning behind that, and the choice between the two enforcement values, is in DMARC quarantine vs reject.

The ruf= address is optional and mostly theoretical inside Microsoft 365, because Microsoft 365 does not send forensic reports at all, even when a valid ruf address is published. Microsoft's advice is to start with rua only, and to point it at a dedicated shared mailbox rather than a user mailbox. There are further conditions on whether reports arrive at all, including a cross-domain authorisation record that silently blocks them, covered in DMARC aggregate reports.

The rollout order Microsoft actually recommends

The sequence is p=none, then monitoring, then p=quarantine, then p=reject. What makes Microsoft's version of it worth following is the ordering advice attached to it: start with a low-volume subdomain and save the parent domain for last.

1. Step 1Publish p=none with a rua address

   On the low-volume subdomain first. Without rua the monitoring phase collects nothing and you are simply waiting.

2. Step 2Monitor and enumerate senders

   Identify every service sending as the domain and get each one signing with aligned DKIM.

3. Step 3Move to p=quarantine

   Microsoft suggests optionally stepping pct= here, which the 2026 specification deprecates. Stage by domain and by time instead.

4. Step 4Move to p=reject

   Once a full reporting cycle at quarantine has produced no surprises on that domain.

5. Step 5Repeat, parent domain last

   The parent carries the most senders and the most history, so it is the riskiest and goes at the end.

That ordering has a specific interaction with how DMARC treats subdomains, and it is the trap that catches Microsoft 365 tenants most often.

The inheritance rule that differs from SPF and DKIM

This is the single most important Microsoft 365 gotcha, and it is counterintuitive precisely because the neighbouring records behave the opposite way.

A domain's DMARC record automatically covers all of its subdomains, including subdomains that do not exist, unless a given subdomain publishes its own DMARC record. Each subdomain still needs its own SPF and DKIM records.

Read those two sentences together and the failure mode falls out. Publishing p=reject on _dmarc.contoso.com immediately enforces reject on mail.contoso.com, notifications.contoso.com and every other subdomain that has not published its own policy. Those subdomains did not inherit any authentication, because SPF and DKIM do not work that way. So a subdomain sending real mail with no SPF or DKIM of its own goes from delivering to being refused, at the moment you tighten the parent, without you having touched the subdomain at all.

The coverage of non-existent subdomains is the useful half of the same rule. Spoofing a name like billing.contoso.com that was never created is a standard technique, and the parent record covers it automatically. The 2026 specification adds np= to set a distinct policy for non-existent subdomains, and sp= remains available for setting a subdomain policy that differs from the parent.

Before you publish p=reject on the parent domain

• ✓Yes: Every subdomain that sends mail has its own SPF and DKIM records
• ✓Yes: The onmicrosoft.com domain has its own DMARC record, created in the admin center
• ✓Yes: Parked and unused domains you own are published at p=reject
• ✓Yes: rua is published and reports have actually been arriving
• ✓Yes: A low-volume subdomain has already been through the full sequence
• ✕No: The parent record is assumed to give subdomains SPF and DKIM coverage too
• ✕No: ruf is expected to produce failure reports from Microsoft 365
• ~Depends: A subdomain needs a different policy from the parent, so sp= applies

Parked domains

Domains you own and never send from are the easiest decision in the whole exercise. Microsoft's guidance for parked and unused domains is to publish v=DMARC1; p=reject; and be done with it. There is no legitimate mail to break, so there is no monitoring phase to run and nothing to stage.

This matters more than it sounds for anyone buying domains in batches for outbound, where a set of registered but not yet activated domains is a standing spoofing surface that nobody is watching. Publish reject on them at registration.

The alignment table, worked

Alignment is the concept that decides whether an authentication pass counts. The adkim= and aspf= tags each take r for relaxed, which is the default, or s for strict. Relaxed requires the organizational domain to match and permits subdomains. Strict requires the fully qualified domain name to match exactly.

Microsoft publishes a worked table for a From address of user@contoso.com, which is the clearest way to see the difference.

The second and third rows are why relaxed is the sensible default. Sending platforms routinely use a bounce subdomain for the return path, and internal senders routinely use a subdomain in the From address, and both of those pass under relaxed while failing under strict. The last two rows are the ones that describe real problems: a third-party sender authenticating as itself, and mail from your tenant authenticating as the onmicrosoft domain, neither of which does anything for your brand domain.

Strict alignment is worth reaching for only when you control every sender on the domain and want to close the subdomain path deliberately. On a domain with any third-party senders on it, strict is a way to break working mail for no security gain you could not get from enforcement plus proper DKIM.

Where cold email fits

Outbound sending belongs on domains that are separate from your primary company domain, which changes this procedure in one useful way: those sending domains are not in your Microsoft 365 tenant at all, so the entire portal question disappears. Each one is a TXT record at whichever registrar holds it, and each needs its own SPF, its own DKIM from the sending platform, and its own DMARC record.

None of them inherits anything from your Microsoft 365 configuration. That is the point of the separation, and it is also the reason a fleet of sending domains is where unpublished DMARC records accumulate: nobody audits twenty registrar zones. The underlying record mechanics for all three protocols are in our SPF, DKIM and DMARC setup guide, and the policy ladder from monitoring to enforcement is in DMARC policy not enabled.

The short version

Microsoft 365 has no admin portal path and no PowerShell cmdlet for managing DMARC on custom domains, so the TXT record is created at your registrar on the hostname _dmarc. The one exception is your onmicrosoft.com domain, which is managed in the admin center under Settings, then Domains, then DNS records, adding a TXT record named _dmarc with the value v=DMARC1; p=reject and a TTL of one hour. That domain needs its own record because it fails alignment against your brand domain.

Microsoft's rollout order is p=none, monitor, p=quarantine, p=reject, starting on a low-volume subdomain and saving the parent domain for last. The rule that catches people is that a DMARC record automatically covers all subdomains including non-existent ones, while SPF and DKIM do not, so enforcing on a parent can break a subdomain that never got its own authentication. Parked domains go straight to v=DMARC1; p=reject;. Relaxed alignment is the default and the right choice on any domain with third-party senders. Microsoft still recommends pct= staging while the May 2026 RFCs deprecate the tag, so stage by domain and by time instead.

We run sending domains, authentication and the reporting behind them as part of our outbound engagements, which keeps this off the list of things your IT team owns without much context. You can see what a campaign would look like for your market.

Microsoft 365 procedures, values and recommendations are per Microsoft's DMARC configuration documentation as of August 2026. Specification details are per RFC 9989, 9990 and 9991, published 20 May 2026. Verify current guidance with the official sources before making DNS changes.

Sources: Set up DMARC to validate the From address domain, Microsoft Learn, IETF publishes updated DMARC specification, dmarc.org