Multiple Email Domains: Alias or Mailbox?

First decide whether the brands belong in one tenant

Microsoft supports multiple custom domains in one tenant—typically up to 5,000. Once a domain is verified and its mail

• DNS is pointed to Microsoft 365, addresses on that domain can be assigned to recipients in the tenant.
• That is operationally convenient for brands under common ownership. It also creates a shared security and administration boundary.
• Global administrators, compliance controls, address-book visibility, data location decisions, and incident impact all sit inside one tenant.
• If the domains represent legally or operationally independent organisations, choose the tenant architecture first. Cheap mailboxes are not a good reason to collapse boundaries that later need a tenant-to-tenant migration.

Option 1: aliases for one inbox

Suppose info@north.example, hello@south.example, and contact@group.example should all reach the same people and do not need separate histories. Add the addresses as proxy addresses on one mailbox. This creates one mailbox, one set of folders, one retention context, and one search history. It is the lowest-maintenance design. Use aliases when: incoming messages can be mixed in one inbox; one permission set is acceptable; reporting does not need clean mailbox separation; the primary user or team should manage a single archive. Test outbound behaviour. Exchange Online can support sending from aliases when the tenant setting and client scenario support it, but client behaviour and reply-address expectations must be validated. Do not promise brand separation until Outlook, mobile, automated replies, signatures, and third-party applications are tested.

Option 2: shared mailboxes for distinct queues

Create separate shared mailboxes when each address needs its own inbox, folders, delegates, rules, auto-reply, or sent-item history. For example: support@brand-a.example

• support@brand-b.example
• accounts@holding.example
• The shared mailbox can normally store up to 50 GB without its own Exchange licence. Every person accessing it must use their own licensed Exchange Online mailbox. Grant delegation; do not distribute the shared mailbox account password or sign in directly as the mailbox.
• Additional licensing is required when the shared mailbox exceeds the baseline or uses features such as a 100 GB primary mailbox, expanded archive, Litigation Hold, or advanced security and compliance capabilities.

Practical checks

This is often the right design for a small multi-brand group because it preserves separation without creating fake employees.

Option 3: a licensed user mailbox

Use a licensed user mailbox where there is a real person with an individual

• identity, or where the workload explicitly requires a supported licensed account rather than delegation.
• A licensed user is also the right answer when that identity needs OneDrive, Office apps, Teams, Intune, Conditional Access
• benefit, or another user service. An email address that can
• technically authenticate is not automatically a valid service-account architecture.

Practical checks

Avoid turning info@ accounts into shared credentials. It weakens attribution, complicates MFA, and makes offboarding impossible to audit.

Four examples

If all mail can be mixed, use aliases on

• the founder’s licensed mailbox. If each brand needs
• a clean inbox and sent history, use three
• shared mailboxes delegated to
• the founder’s licensed account.

One founder, three trading names

If all mail can be mixed, use aliases on the founder’s licensed mailbox. If each brand needs a clean inbox and sent history, use three shared mailboxes delegated to the founder’s licensed account. Five support agents, two brands Create one shared mailbox per brand, grant the five licensed agents access, and set brand-specific signatures and reply behaviour. Confirm whether a helpdesk platform would be more appropriate before building complex mailbox rules. A newly acquired company Do not start with aliases. Assess identity, compliance, accepted domains, mail flow, data separation, and migration. The correct answer might be a staged coexistence rather than immediately placing both brands in one tenant. An application that sends invoices Choose a supported application-mail model. A shared mailbox delegated to a human is not automatically suitable for unattended authentication. Review Exchange Online application access, SMTP submission alternatives, service principals, and the application vendor’s supported method.

DNS and cutover mistakes to avoid

Verify the domain with a TXT record before changing mail flow. Create the

• required recipients before switching the MX record; once the MX points to
• Microsoft 365, all mail for that domain starts arriving there. Configure and
• validate SPF, DKIM, and DMARC for every sending domain, including third-party senders.
• Also inventory aliases and addresses before moving a domain between tenants. A verified custom domain cannot be

Practical checks

attached to two Microsoft 365 tenants at the same time, and overlooked proxy addresses can block removal.

A decision rule that stays useful

Same inbox and same permissions: alias.

• Separate queue, shared access, no direct sign-in: shared mailbox.
• Personal identity or user services: licensed user mailbox.
• Separate legal/security boundary: consider a separate tenant before choosing recipients.
• Axeti can review multi-domain mail designs as part of a tenant consolidation or CSP

Practical checks

engagement, especially where licences, security boundaries, and future divestment need to be considered together.

Sources and scope: Microsoft Learn, Domains Frequently Asked Questions: multiple-domain support and tenant behaviour. Microsoft Learn, Add a custom domain to Microsoft 365: verification, recipient preparation, and DNS cutover. Microsoft Learn, About shared mailboxes in Microsoft 365: delegate, sign-in, storage, and licensing rules. Microsoft Learn, Enable or disable sending email from aliases: tenant control for send-from-alias behaviour. Mail authentication and application sending requirements vary by sender and protocol. Validate the exact client, application, domain, and recipient configuration before changing production DNS.