Sending and Receiving Email on an xxx.onmicrosoft.com Address — How Licenses and Mailboxes Fit Together

Create a Microsoft 365 (formerly Office 365) tenant and it hands you a default domain like contoso.onmicrosoft.com. You can create an account such as adele.vance@contoso.onmicrosoft.com under it and sign in, and yet the moment you try to receive mail on that address nothing shows up, or there is no Outlook to send from. It is a common wall to hit.

The trigger is usually verification work: a sign-up or Identity Validation confirmation mail from Azure, a registration confirmation from some external service, something that requires the tenant-side account to receive email. But the onmicrosoft.com address tends to sit in a state where the account exists but there is no mailbox behind it. This post explains why, and how to fix it, following the admin steps.

What kind of domain is onmicrosoft.com

onmicrosoft.com is the default domain assigned automatically when you create a Microsoft Entra ID (formerly Azure Active Directory) tenant. It takes the form <tenant-name>.onmicrosoft.com, and exactly one always exists even if you have never added a custom domain.

This domain is not decorative: it is a genuinely routable mail domain. Formally it is the MOERA (Microsoft Online Email Routing Address), usable for initial setup before you verify a custom domain, and as a backup routing path separate from your custom domain. So the starting point is that onmicrosoft.com can be a real email address.

The catch is that a domain being real and a given account being able to send and receive are two different things.

Why it doesn’t send or receive by default

This is the crux of the post. Being able to sign in and being able to send and receive mail rest on separate mechanisms.

What signs in is the Entra ID “user account.” It authenticates with an ID and password (plus MFA) and holds permissions to access resources in the tenant.
What stores and sends mail is the Exchange Online “mailbox.” The inbox, sent items, and calendar all physically live here.

Creating an Entra ID account alone does not create the corresponding Exchange Online mailbox. The mailbox is provisioned automatically only once you assign the user a license that includes Exchange Online. An account with no license can sign in but has no mail substance behind it, so it can neither receive nor send.

flowchart LR
    A["Entra ID<br/>user account"] -->|can sign in| B["Resources in tenant"]
    A -.->|no license| X["No mailbox<br/>= can't send/receive"]
    A -->|assign Exchange Online<br/>license| C["Exchange Online<br/>mailbox provisioned"]
    C -->|can send/receive| D["Email"]

In most cases, the reason that Azure confirmation mail never arrived is not a permissions or configuration problem on the account, but that there was simply no mailbox to catch it.

The whole thing is three steps

What you actually do is simple:

Get a license that can hold a mailbox (buy one).
Assign the license to the target user (the mailbox is provisioned automatically).
Send and receive with Outlook on the web or another client.

Let’s take them in order.

Step 1: Get a license that can hold a mailbox

Provisioning a mailbox requires a license that includes Exchange Online. If you have a spare seat on an existing license you can use that; otherwise, buy one. As a standalone subscription, Exchange Online (Plan 1) is the minimal option.

Open Exchange Online (Plan 1) from the Marketplace in the Microsoft 365 admin center and the price is set by a combination of the term (1 month, 1 year, or 3 years) and the billing frequency (monthly, annual, or once every 3 years). Standard list price in Japan, as of July 2026:

Term	Billing	Price	Effective monthly
1 month	Monthly	¥719 / license / month	¥719
1 year	Monthly	¥629 / license / month	¥629
1 year	Annual	¥7,188 / license / year	¥599
3 years	Once every 3 years	¥21,564 / license / 3 years	¥599

Note that even on the same 1-year term, the billing frequency changes the unit price. Monthly billing is ¥629/month, but annual billing works out to ¥7,188/year (¥599/month effective), about 5% cheaper. A 3-year term paid up front is also ¥599/month effective: the more you prepay, the lower the unit price.

For a verification account that just needs to receive mail, Plan 1 is plenty. It comes with a 50 GB mailbox and Outlook on the web, and is the lowest-cost way to get standalone mail. Consider the higher-tier Exchange Online (Plan 2) only when you actually need a large mailbox, unlimited archiving, or data loss prevention (DLP); there is no need to jump to a higher tier up front. If you also need web Office and Teams alongside mail, an integrated plan that includes Exchange Online, such as Microsoft 365 Business Basic, is another option.

Choosing is simple. If it is verification work with a foreseeable end, take the 1-month term on monthly billing (¥719/month) and cancel when done to avoid waste. For permanent use, a 1-year term on annual billing or a 3-year term paid up front (both ¥599/month effective) keeps it about 5% cheaper than monthly billing.

Step 2: Assign the license to the user

Once you have a license, assign it to the target user.

Sign in to the Microsoft 365 admin center.
Go to “Users” → “Active users” and select the target account (e.g. adele.vance@contoso.onmicrosoft.com).
Open the “Licenses and apps” tab and check a license that includes Exchange Online (Plan 1).
Click “Save changes”.

Assigning the license provisions an Exchange Online mailbox automatically, configured from the corresponding mailbox plan. Propagation takes a little time: Microsoft notes it can take up to about 15 minutes for the mailbox and Outlook, Calendar, and People to become available. If Outlook is not there right after you save, wait a few minutes and check again.

Step 3: Send and receive email

Once the mailbox exists, it works like any other Microsoft 365 account. The easiest path is Outlook on the web, which needs nothing but a browser.

Sign in to Outlook on the web with the target account and the inbox is right there. No extra client configuration.
The desktop Outlook and the Outlook mobile apps connect the same way once you sign in with the account.
For older devices or a custom mail client, IMAP / SMTP also work (they are disabled by default in some tenants, so you may need to enable the authentication protocols for that mailbox in the Exchange admin center).

At this point you should be able to receive confirmation mail from Azure and elsewhere on the onmicrosoft.com address.

Pitfall: onmicrosoft.com has an outbound cap for external mail

Receiving is fine, but sending from an onmicrosoft.com address to external recipients runs into a restriction.

As part of Microsoft’s restrictions on sending from the onmicrosoft.com domain, outbound mail from onmicrosoft.com domains is capped at 100 external recipients per tenant within a rolling 24-hour window. Inbound is unaffected, but once you exceed the cap, external sends are rejected with a 550 5.7.236 NDR (non-delivery report). Enforcement rolled out in stages by tenant size and finished reaching every tier by the first half of 2026, so effectively every tenant is now subject to it.

The intent behind the cap is to discourage using onmicrosoft.com as a production sending domain. It is hard to build sending reputation on onmicrosoft.com to begin with, and it is an easy vehicle for spoofing and phishing, so Microsoft strongly recommends using a custom domain. A trickle of confirmation mail or verification is fine, but if you send business or notification mail to external recipients on an ongoing basis, move to one of these:

Add a custom domain to Microsoft 365 and change the default sending address to that domain.
Split bulk or notification mail onto a dedicated sending path such as Azure Communication Services.

Practical rules of thumb

Pulling it together, the onmicrosoft.com address sorts into clear uses.

If the goal is receiving (confirmation mail, notifications), assigning Plan 1 alone is enough.
A trickle of sending (replies, test sends) is fine too, but keep the 100-external-recipients-per-24-hours cap in mind.
It is not the domain to carry ongoing external sending. Add a custom domain and move the lead role there.

For a verification environment where the need is simply “the account should be able to receive mail,” assigning the minimal Plan 1 on monthly billing and canceling when done is the most cost-efficient way to run it.

Summary

An onmicrosoft.com address can’t send or receive because the Entra ID account exists but has no mailbox. Assign a license that includes Exchange Online (Plan 1 at minimum) and a mailbox is provisioned automatically, and you can send and receive from Outlook on the web right away. Just note that outbound external mail is now capped at 100 recipients per 24 hours, so understand up front that while it works for receiving and verification, a production sending domain should be a custom domain you move to.