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

URL: https://iblockspam.com/blog/dmarc-onmicrosoft-domain-microsoft-365
Last updated: 2026-10-10
Published: 2026-10-10
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> Why your onmicrosoft.com (MOERA) domain needs its own DMARC record, how to add it in the Microsoft 365 admin center, how DKIM works for it, and how to check it.

## Short answer

Every Microsoft 365 tenant has an onmicrosoft.com domain. Microsoft sets up its SPF and DKIM, but not DMARC. Add it yourself in the Microsoft 365 admin center: Settings > Domains, select the onmicrosoft.com domain, open DNS records and add a TXT record named _dmarc with the value v=DMARC1; p=reject if you don't send from it.

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](https://iblockspam.com/blog/dmarc-setup-microsoft-365) 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](https://learn.microsoft.com/en-us/microsoft-365/admin/setup/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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) 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](https://www.rfc-editor.org/rfc/rfc9989.html), with nothing found for the domain or its parents, there is simply no policy to apply.

| Record | Who sets it up | Status by default |
|---|---|---|
| MX | Microsoft | Points to Exchange Online |
| SPF | Microsoft | `v=spf1 include:spf.protection.outlook.com -all` in the tenants we checked |
| DKIM | Microsoft | Outbound mail signed automatically |
| DMARC | **You** | Missing until you add it |

## 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](https://techcommunity.microsoft.com/blog/exchange/limiting-onmicrosoft-domain-usage-for-sending-emails/4446167)). 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](https://iblockspam.com/blog/microsoft-365-message-trace) 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure), 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](https://www.rfc-editor.org/rfc/rfc9990.html) 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](https://iblockspam.com/tools/dmarc-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](https://iblockspam.com/tools/dmarc-report-analyzer) reads the report files in your browser.

### Common mistakes

| Mistake | What happens | Fix |
|---|---|---|
| Adding `_dmarc` at your registrar for `contoso.onmicrosoft.com` | Nothing; you don't control that zone | Use the DNS records tab in the Microsoft 365 admin center |
| Covering only the first onmicrosoft.com domain | A second or fallback domain has no policy | Add a record to each one |
| Leaving `p=none` in place indefinitely | Receivers still get no instruction to reject spoofs | Move to `p=reject` once nothing legitimate sends from it |
| Sending reports to another domain without authorization | Receivers that check may not send them | Publish the `_report._dmarc` record on the receiving domain |
| Two `_dmarc` TXT records | Receivers can't apply a single policy | Keep exactly one |

## How does DKIM work for the onmicrosoft.com domain?

According to [Microsoft Learn](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure), 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](https://iblockspam.com/blog/dkim-setup-microsoft-365-google-workspace) covers custom domains, and the [DKIM-Signature header guide](https://iblockspam.com/blog/dkim-signature-header-explained) 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](https://iblockspam.com/tools/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](https://iblockspam.com/tools/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](https://iblockspam.com/tools/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](https://iblockspam.com/blog/dmarc-none-to-reject-small-business), and lock down any [parked domains](https://iblockspam.com/blog/protect-parked-domains-from-spoofing) the same way.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### What is a MOERA domain in Microsoft 365?

MOERA stands for Microsoft Online Email Routing Address. It's the onmicrosoft.com domain Microsoft 365 creates when you sign up, such as contoso.onmicrosoft.com. Microsoft keeps it because it's used behind the scenes for your subscription, so you can't remove or rename it, though you can add a new one and make it your fallback domain.

### Do I need DMARC for onmicrosoft.com if I only use my own domain?

Yes. Microsoft's guidance for parked domains says to publish a DMARC record stating that no mail should ever come from them, and it explicitly includes the onmicrosoft.com domain if you aren't using it for email. Without a record, receivers have no policy telling them to reject mail that spoofs it.

### Can I add the onmicrosoft.com DMARC record at my registrar?

No. You don't own the onmicrosoft.com zone, so you can't publish records in it at your registrar or DNS host. Microsoft provides a DNS records tab for the onmicrosoft.com domain in the Microsoft 365 admin center, and that's where you add the _dmarc TXT record.

### Is DKIM already set up for my onmicrosoft.com domain?

Yes. Microsoft says outbound mail from senders in the onmicrosoft.com domain is automatically DKIM signed by that domain, so you don't need to do anything. You can optionally enable it in the Defender portal to make it appear on the DKIM tab and allow manual key rotation, as there's no automatic rotation for it.

### Can I still send email from my onmicrosoft.com address?

Only in small amounts. Microsoft now throttles mail from onmicrosoft.com domains to 100 external recipients per tenant in a rolling 24-hour window, and blocked messages bounce with 550 5.7.236. Microsoft says these domains should only be used for testing, so move users and apps to a custom domain.

## Sources

- [Microsoft Learn: Set up DMARC to validate email in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)
- [Microsoft Learn: How to use DKIM for email in your custom domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure)
- [Microsoft Learn: Domains frequently asked questions](https://learn.microsoft.com/en-us/microsoft-365/admin/setup/domains-faq)
- [Microsoft Exchange Team Blog: Limiting Onmicrosoft Domain Usage for Sending Emails](https://techcommunity.microsoft.com/blog/exchange/limiting-onmicrosoft-domain-usage-for-sending-emails/4446167)
- [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html)

## Free tools for this guide

- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator): Build a DMARC record with the right policy, reporting and alignment settings.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.

---

Source: iBlockSpam, https://iblockspam.com/blog/dmarc-onmicrosoft-domain-microsoft-365 (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt