What Does Accepted domain Mean?

Think of an accepted domain like adding a new phone number to your smartphone. Your phone already has a default number assigned to it, but you can add additional numbers that people can use to call you. In the same way, Microsoft 365 comes with a default domain like yourorg.onmicrosoft.com, but you likely want to use your own custom domain like yourcompany.com for professional email.

When you add an accepted domain, you are telling Microsoft 365, "I own this domain, and I want to use it for email." But simply telling Microsoft is not enough. You also need to prove ownership by adding a special DNS record, usually a TXT record, which acts like a secret handshake. Once Microsoft verifies the record, the domain becomes an accepted domain.

There are three types of accepted domains in Exchange Online: authoritative, internal relay, and external relay. An authoritative domain means that all email addresses ending with that domain belong to your organization, and Exchange Online will only deliver messages to mailboxes it knows about. An internal relay domain is used when you have some mailboxes on-premises and some in the cloud, so email is routed to both. An external relay domain lets you forward email for addresses that are not hosted inside your organization, such as for a partner company.

In everyday business, this is critical because without an accepted domain, any email sent to someone@yourcompany.com would bounce back as undeliverable. The accepted domain system ensures that your email flows correctly and securely to the right destination.

An accepted domain in Exchange Online is a configured namespace that defines the SMTP address space for which the Microsoft 365 organization is responsible. Technically, it is an entry in the organization's transport configuration that tells the Exchange Online transport pipeline how to handle messages addressed to recipients in that domain.

When an email arrives at Exchange Online, the transport service checks the recipient's domain against its list of accepted domains. If the domain is found, the system applies the domain type: authoritative, internal relay, or external relay. For authoritative domains, Exchange Online checks if the recipient mailbox exists within its directory. If it does, the message is delivered. If not, a non-delivery report (NDR) is generated. This is the default behavior and is the most common setup for businesses that use only cloud mailboxes.

For internal relay domains, the transport service will look for the recipient both in Exchange Online and in any on-premises Exchange servers via a configured Send connector. This is typical in hybrid deployments where some mailboxes remain on-premises. The internal relay type ensures that email destined for a mailbox still in the on-premises environment is forwarded correctly without being rejected.

External relay domains are used less frequently but are important for scenarios where the organization needs to forward email to external email systems, such as a partner's SMTP server. In this case, Exchange Online accepts the message and relays it out to the external mail system. This requires careful configuration to prevent the system from becoming an open relay, which could be exploited to send spam.

Accepted domains are managed through the Exchange admin center or using PowerShell cmdlets like New-AcceptedDomain, Set-AcceptedDomain, and Get-AcceptedDomain. Each accepted domain must be verified by adding a DNS TXT record, and the domain must be added to the Microsoft 365 tenant before it appears in the accepted domains list. Accepted domains are closely tied to email address policies and user mailbox configuration, as they determine the primary SMTP addresses assigned to users.

Accepted domains are fundamental to email operations in Microsoft 365 because they directly control whether your organization can send and receive emails using your own brand. Without configuring accepted domains, your users would be stuck with the default onmicrosoft.com domain, which looks unprofessional and can cause deliverability issues because many spam filters treat unknown domains suspiciously.

For IT professionals, understanding accepted domains is crucial for planning hybrid migrations. When you move mailboxes from an on-premises Exchange server to Exchange Online, you must configure the accepted domain as internal relay so that email flows correctly between the two environments during the transition. Misconfiguring this can lead to email loss or bounces, which directly impacts business communication.

Security is another major reason. Accepted domains with the external relay type must be carefully secured to prevent open relay abuse. If an external relay domain is misconfigured, attackers can use your email system to send spam, which can get your domain blacklisted and ruin your organization's email reputation.

From a compliance standpoint, accepted domains help you control the scope of your email system. Only domains that are accepted are processed by Exchange Online, reducing the risk of data leakage through unmanaged domains. For example, if you accidentally add a misspelled domain, you could inadvertently receive emails meant for another organization, leading to data privacy issues.

In short, accepted domains are the gatekeeper of your email system. They decide which emails are your responsibility and which should be rejected. Properly managing them is a foundational step in maintaining a healthy, secure, and professional email environment.

Accepted domain questions on the MS-102 exam appear in three main patterns: configuration scenarios, hybrid migration scenarios, and troubleshooting scenarios.

Configuration scenarios: You are asked to add a new custom domain for email. The question might describe a company that just bought a new domain, let's say fabrikam.com, and wants to use it for email addresses. You are given options: Add the domain as external relay, add it as authoritative, or verify ownership first. The correct approach is to verify ownership first, then add it as authoritative if all mailboxes are in the cloud. The question might also ask which DNS record to use: a TXT record with a verification code provided by Microsoft 365.

Hybrid migration scenarios: A company has on-premises Exchange and is moving some mailboxes to Exchange Online. The domain contoso.com is already an accepted domain. After moving half the mailboxes, some emails to on-premises users bounce. The question asks why and what to change. The answer is that the accepted domain type needs to be changed from authoritative to internal relay so that Exchange Online forwards emails to the on-premises server for users not yet migrated.

Troubleshooting scenarios: Users report that emails sent to a new domain, support@newcompany.com, are being rejected. You check the accepted domains list and see that newcompany.com is missing. The question asks: 'What is the first step to resolve this?' The correct answer is to add and verify the domain as an accepted domain. Another troubleshooting question might involve an NDR with error '550 5.1.1 User unknown' even though the mailbox exists. This suggests that the accepted domain is set to external relay instead of authoritative, so Exchange Online is not checking the directory for the recipient.

Scenario questions with multiple steps: You are given a requirement to set up email for a subsidiary using a different domain. The question asks for the correct order of operations: verify domain, add accepted domain, configure email address policy, assign licenses. The sequence matters because you cannot configure an email address policy for a domain that is not yet accepted.

Finally, you might see comparison questions asking you to identify the correct domain type for a given requirement. For example, 'Which accepted domain type should be used when you want to forward email to an external email system that is not part of your organization?' The answer is external relay.

In all cases, the exam rewards precise knowledge of the domain types and their use cases, as well as the verification and configuration steps.

Accepted domains are a fundamental building block of email routing in Microsoft 365, and every IT professional managing Exchange Online must understand them thoroughly. In practice, you will most often encounter authoritative domains for standard cloud-only organizations. When a domain is authoritative, Exchange Online performs directory lookup for every recipient in that domain. If the recipient mailbox exists, the message is delivered; if not, an NDR is sent. This prevents email from being lost.

In hybrid deployments, internal relay is the most critical domain type to understand. When you have a mix of cloud and on-premises mailboxes, the internal relay type allows Exchange Online to query the on-premises directory via the hybrid configuration. It essentially trusts the on-premises server to know about all recipients. If you mistakenly set the domain to authoritative, on-premises mailboxes are invisible to Exchange Online, causing bounces for emails sent to them from the internet.

External relay domains are useful for very specific scenarios, like a company that hosts emails for a subsidiary on a third-party platform. However, external relay is often misused. A common mistake is to set a domain to external relay thinking it will magically forward emails to another service, but without proper connectors and routing, the emails will simply be relayed outside the organization, which can create security risks. Always ensure that external relay is accompanied by a corresponding Send connector pointing to the external email system.

Configuration via PowerShell is a skill you should develop. For example, to create an authoritative accepted domain, you might run: New-AcceptedDomain -Name 'contoso.com' -DomainName 'contoso.com' -DomainType Authoritative. To change it later: Set-AcceptedDomain -Identity 'contoso.com' -DomainType InternalRelay. Understanding these commands is useful for automation and troubleshooting.

What can go wrong? The most common issue is adding a domain to the tenant but forgetting to add it as an accepted domain. Users may have email addresses with the domain assigned via email address policies, but incoming emails will bounce because Exchange Online does not see the domain in its accepted list. Another issue is DNS propagation delays: after adding the TXT record, it can take up to 72 hours for DNS to fully propagate, though it usually takes much less time. Prematurely trying to use the domain before verification can cause failures.

In production, you should document all accepted domains and their types, especially if you have multiple domains. When a new domain is added, update your email address policies, configure any required connectors, and monitor mail flow for the first few days. This ensures a smooth transition and prevents email loss for end users.