What Does Custom domain Mean?

Think of a custom domain like the nameplate on your office door. When you rent an office in a big building, the building management might give you a generic nameplate that just says Room 304. That works, but nobody knows who you are just by seeing Room 304. A custom domain is like having your own personalized nameplate engraved with Your Name and Your Job Title. When clients walk down the hall, they see your name and immediately know it’s you.

In the online world, Microsoft gives every tenant a default domain like yourcompany.onmicrosoft.com. That is functional, but it doesn’t look professional. If you own a website domain, like yourcompany.com, you can add that custom domain to your tenant. Then your login pages, email addresses, and other services can use yourcompany.com instead of the default one. This makes everything look clean and branded.

But you cannot just tell Microsoft you own that domain. You have to prove it. This is done by adding a special text record (like a TXT record or MX record) to your domain’s DNS settings. DNS is like a phonebook for the internet. By placing a secret code in that phonebook, Microsoft can look it up and confirm that you really control the domain. Once verified, you can set the custom domain as your primary domain or add more domains for different regions or brands.

Having a custom domain also helps with trust. When users see yourcompany.com in an email address or a login page, they know it’s authentic. Scammers often use generic or misspelled domains, so a clean custom domain is a sign of legitimacy. For IT professionals, understanding how to add, verify, and manage custom domains is a critical skill for identity and governance tasks.

A custom domain in the context of Microsoft 365 and Azure Active Directory (Microsoft Entra ID) refers to a DNS domain name that you own and register with your cloud tenant, replacing or supplementing the initial onmicrosoft.com domain. When you create a tenant, Microsoft provision a default domain, such as contoso.onmicrosoft.com, which serves as the initial namespace for user principal names (UPNs) and email addresses. However, for production environments, you almost always want to use your own domain, like contoso.com, for user identities and services.

To use a custom domain, you must add it to the tenant and then verify ownership through DNS verification. The verification process typically involves adding a specific TXT record or MX record to the domain's DNS zone. Microsoft provides a unique verification string that you copy and paste into your DNS hosting provider’s management interface. Once the record is published and propagated across the internet, Microsoft queries the DNS and confirms that the record matches. This proves that you control the domain. After verification, you can set the custom domain as the default domain for new users, or you can use it for specific scenarios like email routing with Exchange Online.

In technical terms, when a user signs in with a UPN like admin@contoso.com, Azure AD first resolves the domain suffix. If the domain is verified and associated with the tenant, the authentication request is routed to the correct tenant. Custom domains also play a role in federated identity scenarios, where the domain’s DNS records may point to an external identity provider. For email, MX records direct incoming mail to your tenant. SPF, DKIM, and DMARC records further secure email delivery and reduce spoofing. IT professionals must manage DNS records carefully because misconfigured records can break email delivery, authentication, or domain verification.

Custom domains can be added in the Microsoft 365 admin center (Setup > Domains) or in Azure AD (Custom domain names). For Azure AD, you can also use PowerShell or Microsoft Graph API to programmatically manage domains. Each tenant can have up to 500 custom domains, though that limit may vary by subscription. Once added, domains are categorized as either verified or unverified. Only verified domains can be used for user accounts and services. It is also possible to use multiple custom domains for different business units, brands, or geographies. In hybrid deployments, custom domains must match the on-premises UPN suffixes for seamless synchronization with Azure AD Connect. Any mismatch will cause sync errors or authentication failures for federated users. Understanding custom domain management is essential for the MS-102 and AZ-104 exams, as questions often test the DNS verification flow, the impact on user creation, and troubleshooting domain issues.

Custom domains matter because they are the public face of your organization in the cloud. When users sign in to Microsoft 365 or Azure, the domain in their username tells the authentication system where to route the request. If you use the default onmicrosoft.com domain, every user’s UPN will be something like jdoe@contoso.onmicrosoft.com. That looks unprofessional and can cause confusion, especially if your organization has multiple brands or if you are a service provider with many tenants. By using a custom domain, you present a consistent, branded identity to customers, partners, and employees.

From a technical and security perspective, custom domains are the foundation for many critical services. Email delivery depends on MX records pointing to your tenant. SPF and DKIM records prevent spoofing. Federated authentication with another identity provider requires the custom domain to be verified and configured correctly. If you neglect to add a custom domain or misconfigure the DNS records, you can break email, cause authentication failures, or even allow domain takeover attacks where an attacker verifies a domain you no longer control.

For IT administrators, managing custom domains is a daily task. You might need to add a new domain after a merger, remove a domain that is no longer used, or troubleshoot why users cannot sign in after a domain change. The process seems simple, but mistakes like forgetting to remove a domain from all users before deleting it, or using the wrong verification method (TXT vs MX), can lock you out of your own tenant. This is why exams like MS-102 and AZ-104 emphasize the verification flow and the importance of DNS records. A solid understanding of custom domains ensures that you can set up identity and governance correctly from the start, avoiding costly migrations later.

Custom domain questions appear in multiple formats across the MS-102 and AZ-104 exams. One common pattern is a scenario question where you are given a fictional company, like Contoso Ltd., that has just subscribed to Microsoft 365. The company owns contoso.com and wants to use it for employee email and sign-ins. The question asks you to select the correct sequence of steps to add and verify the domain. The options might include steps like Add domain in admin center, Create user accounts, Add TXT record to DNS, Wait for propagation, Verify domain. You must order them correctly, usually starting with adding the domain, then adding the TXT record, waiting, then verifying.

Another pattern involves troubleshooting. For example, an admin reports that users cannot sign in with their custom domain, even though the domain shows as verified. The question might ask what is wrong. The answer could be that the domain is verified but not set as the default domain, or that DNS records (like CNAME or MX) are missing for other services. Alternatively, the admin might be attempting to delete the custom domain, but the delete button is grayed out. The correct answer is that the domain is still assigned to users, groups, or is the default domain.

In AZ-104, you might see a question about creating a new user with a custom domain. The scenario: an IT pro tries to create a user with UPN jdoe@contoso.com, but the domain contoso.com is not verified. The system returns an error. The answer is that you must first verify the domain by adding a TXT record, then wait for propagation, and only then can you create users with that domain. A variant question asks about the impact of removing a custom domain from the tenant without first unlinking it from users. This leads to user sign-in failures.

There are also comparison questions where you must choose between using the default domain or a custom domain for specific scenarios like federation. For example, if you want to set up federated identity with an on-premises AD FS, you need a custom domain. The exam might ask, Which domain type is required for federation? The answer: a custom domain verified in the tenant. These questions test not just recall but the ability to apply the concept in a real-world IT task. Practicing with step-by-step domain addition exercises in the Microsoft 365 test environment will prepare you for these questions.

Custom domains are the bridge between your organization’s identity and the cloud. As an IT professional, you will routinely add, verify, and manage custom domains for tenant onboarding, mergers, and rebranding. The process sounds simple, but there are several practical pitfalls that can cause outages if you do not handle them carefully.

First, always keep a record of your DNS settings before making changes. If you add a TXT record incorrectly, you could break email delivery or other services. Many admins have accidentally overwritten existing MX records when adding verification records. The fix is to carefully add the new record without deleting existing ones. If you are using a DNS provider that uses a wizard, double-check that you are not in a mode that replaces everything.

Second, understand the difference between domain verification and domain configuration for specific services. Verification only confirms ownership. Once verified, you still need to configure additional DNS records for email (MX, SPF, DKIM, DMARC), for Teams (SIP, CNAME records for meeting join), and for Mobile Device Management (CNAME for enrollment). A common mistake is to verify the domain but forget the MX record, so email to the custom domain bounces.

Third, when removing a domain from the tenant, you must first remove it from all users, groups, and services. In the admin center, you can run a report to see which users are still using the domain. Then change their UPN to another verified domain. If the domain is the default, set another domain as default first. After reassigning, wait for any synchronization (if using Azure AD Connect) and then remove the domain. If you remove it too quickly, users will lose access to services.

Fourth, for hybrid environments where you synchronize on-premises AD with Azure AD, the custom domain in the cloud must exactly match the UPN suffix used in the on-premises forest. If the on-premises user has UPN jdoe@contoso.local but the cloud custom domain is contoso.com, Azure AD Connect will fail synchronization. You must either add the custom domain as an alternative UPN suffix on-premises or change the user UPNs to match the cloud domain. This is a common pain point in migration projects.

Finally, when setting up federation with a custom domain, the TXT record for verification is different from the federation records. You first verify the domain with a TXT record, then you configure federation by adding additional DNS records pointing to the federation service. The exam often tests that verification must happen before federation configuration can begin. Keep this order in mind: add domain, verify, then configure services. Skipping verification will break federation setup.