How do you set up DMARC for your onmicrosoft.com domain?

Every Microsoft 365 tenant comes with a domain you probably never think about: yourtenant.onmicrosoft.com. Microsoft configures its SPF and DKIM for you, but not its DMARC record. Until you add one, nothing tells receivers to reject mail that spoofs it. This guide explains why it matters, how to add the record in the admin center, and how to check the result.

If you're setting up DMARC for your custom domains as well, our Microsoft 365 DMARC setup guide covers those.

What is the onmicrosoft.com (MOERA) domain?

When you sign up for Microsoft 365, it creates a domain such as contoso.onmicrosoft.com. Microsoft calls it the Microsoft Online Email Routing Address (MOERA) domain. Microsoft's domains FAQ explains the rules:

• You can't remove it. Microsoft 365 "needs to keep the onmicrosoft.com domain because it's used behind the scenes for your subscription."
• You can't rename it, but you can create a new one and make it your default, or "fallback", onmicrosoft.com domain.
• You're limited to five onmicrosoft.com domains, and any new one can't be removed either.

So every tenant has at least one of these domains for life, and it's a real, resolvable mail domain with its own MX and SPF records.

Why does the onmicrosoft.com domain need DMARC?

A domain with no DMARC record gives receivers no instruction about mail that fails authentication. Anyone can put ceo@contoso.onmicrosoft.com in the From line, and a receiver checking DMARC finds nothing to enforce.

Microsoft's DMARC guidance is clear on two points:

1. Although SPF and DKIM "are already configured for your *.onmicrosoft.com domain, you need to create the DMARC TXT record" for it in the Microsoft 365 admin center.
2. For registered domains that don't send mail, you should publish DMARC records saying no mail should ever come from them, and "this directive includes the *.onmicrosoft.com domain if you aren't using it for email."

There's no fallback from the parent domain either. When we checked in October 2026, onmicrosoft.com itself published no DMARC record, and the sample tenant domains we queried, such as contoso.onmicrosoft.com, had SPF ending in -all but no _dmarc record. Under RFC 9989, with nothing found for the domain or its parents, there is simply no policy to apply.

Should you still send mail from onmicrosoft.com?

Microsoft says no. Its Exchange Team announced in 2025 that "MOERA domains should only be used for testing purposes, not regular email sending" (Exchange Team Blog). It throttles mail from onmicrosoft.com domains to "100 external recipients per 24 hour rolling window" per organization, counted after distribution lists are expanded. Senders over the limit get an NDR starting 550 5.7.236.

Microsoft's published schedule phased the throttling in by tenant size, starting with trial tenants on October 15, 2025 and reaching tenants with more than 10,001 seats on June 1, 2026. At the time of writing (October 2026), that schedule has run its course, so assume your tenant is covered.

That makes p=reject the right policy for almost every tenant. If something still sends from the onmicrosoft.com domain, find it and move it first.

What might still be sending from it

Microsoft's post lists cases to check, including:

• Mailboxes or apps whose primary address is still on the onmicrosoft.com domain.
• A tenant whose default domain is still the onmicrosoft.com domain. Microsoft notes that the Sender Rewriting Scheme may use MOERA domains as a fallback in that case.
• Bookings invites configured to send from the onmicrosoft.com domain.
• The external postmaster address. If it isn't set, the default accepted domain is used, so set it to an address on a custom domain.

Microsoft suggests using Message trace in the Exchange admin center with a wildcard sender such as *@contoso.onmicrosoft.com to find this traffic. Our Microsoft 365 message trace guide explains the tool.

How do you add DMARC for the onmicrosoft.com domain?

You can't publish this record at your registrar, because you don't control the onmicrosoft.com zone. Microsoft provides a DNS records page for it instead. These are the steps from Microsoft Learn, current at the time of writing (October 2026):

1. In the Microsoft 365 admin center at https://admin.microsoft.com, select Show all > Settings > Domains.
2. Select the onmicrosoft.com domain by clicking anywhere in its row other than the check box.
3. On the domain details page, select the DNS records tab.
4. Select Add record.
5. In the Add a custom DNS record flyout, check that Type is TXT (Text).
6. Set TXT name to _dmarc.
7. Set TXT value to v=DMARC1; p=reject.
8. Check that TTL is 1 hour, then select Save.

If you've created extra onmicrosoft.com domains, repeat the steps for each one. They're separate domains, not subdomains of each other, so one record doesn't cover the others.

Do you need reports for this domain?

Microsoft's example with reporting is v=DMARC1; p=reject; rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. For a domain that should send nothing, Microsoft says report addresses "are arguably not needed". Reports can still show you something sending as the domain, legitimately or not.

If you want aggregate reports sent to an address on your custom domain, the receiving domain has to authorize it. RFC 9990 and Microsoft's guidance both describe a TXT record of v=DMARC1; at a name like contoso.onmicrosoft.com._report._dmarc.contoso.com. Without it, receivers that check won't send reports to that external address. The DMARC Record Generator builds the main record with any reporting addresses you choose.

What if something still has to send from it?

If you can't move a sender straight away, don't publish p=reject blind. Use the same staged approach you'd use on a custom domain:

1. Publish v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com, with the reporting authorization record described above.
2. Read the aggregate reports for a few weeks. Anything passing DMARC from Microsoft's servers is one of your own senders; anything failing from elsewhere is spoofing or a misconfigured service.
3. Move each legitimate sender to a custom domain.
4. Change the record to v=DMARC1; p=reject.

Remember the throttle while you do this: anything still sending externally from the onmicrosoft.com domain is limited to 100 external recipients a day across the whole tenant. The DMARC Report Analyzer reads the report files in your browser.

Common mistakes

How does DKIM work for the onmicrosoft.com domain?

According to Microsoft Learn, you don't need to do anything for the initial onmicrosoft.com domain: "Outbound messages from senders in the contoso.onmicrosoft.com domain are automatically DKIM signed by the contoso.onmicrosoft.com domain."

Two details are worth knowing:

• The domain usually doesn't appear in Get-DkimSigningConfig unless you've configured it manually. You can turn it on in the Defender portal under Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. That makes its settings visible and allows manual key rotation.
• Microsoft says "there's no automatic DKIM key rotation for the *.onmicrosoft.com domain."

The onmicrosoft.com domain also plays a part in custom domain DKIM. For custom domains set up before Microsoft's May 2025 format change, the CNAME records point to keys under it, for example selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Newer custom domains use a target under dkim.mail.microsoft instead, such as selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft. Either way, that's only where the key is hosted. The signing domain is still your custom domain, which is what DMARC needs. Our DKIM setup guide covers custom domains, and the DKIM-Signature header guide shows how to check which domain signed a message.

How do you check the onmicrosoft.com DMARC record?

1. Look it up. Enter contoso.onmicrosoft.com (your own tenant name) in the DMARC Checker. Or run nslookup -type=TXT _dmarc.contoso.onmicrosoft.com, or in PowerShell, Resolve-DnsName -Name "_dmarc.contoso.onmicrosoft.com" -Type TXT.
2. Confirm there's exactly one record and that it starts with v=DMARC1. Two DMARC records for the same name are an error.
3. Check SPF too. The SPF Checker should show Microsoft's record ending in -all.
4. Send a test, if you still use the domain. Send from an onmicrosoft.com address to an outside mailbox and read the Authentication-Results header in the Email Header Analyzer. You want dkim=pass with header.d=contoso.onmicrosoft.com and dmarc=pass.

Next steps

1. Add v=DMARC1; p=reject to every onmicrosoft.com domain in your tenant.
2. Run a message trace for *@yourtenant.onmicrosoft.com and move anything still sending to a custom domain.
3. Make sure your tenant's default domain is a custom domain.
4. Publish DMARC for each custom domain, following our p=none to p=reject guide, and lock down any parked domains the same way.

Browse our other SPF, DKIM and DMARC guides.