This chapter covers custom domain management in Microsoft 365, a critical topic for the MS-102 exam. You will learn how to add, verify, and manage custom domains for your tenant, including DNS configuration, domain federation, and troubleshooting. This topic comprises approximately 10-15% of exam questions in the Tenant Management objective domain (1.1). Mastery of custom domain management is essential for configuring a professional email environment and enabling single sign-on (SSO) with on-premises identity systems.
Jump to a section
Imagine you run a company that moves into a large office building (Microsoft 365). Initially, your mailroom (email system) uses the building's default address: 'Suite 4B, Building 365, Cloud City' (onmicrosoft.com). But you want your own branded address: '123 Main Street, YourTown' (contoso.com). To achieve this, you must prove you own '123 Main Street' by registering the deed with the city (domain registrar) and then updating the building's directory (DNS records). The city (registrar) holds the official record of who owns that address. You instruct the city to add a verification code (TXT record) to the property's public file. The building's security (Microsoft 365) checks the public file for that code. Once confirmed, you update the building's mail forwarding rules (MX record) so all mail addressed to '123 Main Street' is redirected to your mailroom. You also add an SPF record to tell other mailrooms that only your building is authorized to send mail from '123 Main Street'. If you fail to update these records properly, mail might be lost or your mail could be rejected as spam. This entire process—proving ownership, updating forwarding, and authorizing senders—is what custom domain management in Microsoft 365 entails.
What Is a Custom Domain in Microsoft 365?
A custom domain is a personalized domain name (e.g., contoso.com) that you own and want to use with Microsoft 365 services like Exchange Online, SharePoint Online, and Teams. By default, every Microsoft 365 tenant is assigned an initial domain in the format <tenantname>.onmicrosoft.com. While you can use this domain, it is not professional for external communication. Custom domains allow you to present a branded email address (user@contoso.com) and control your namespace.
Why Custom Domains Are Necessary
Microsoft 365 requires that all user principal names (UPNs) and email addresses be associated with a verified domain. Without a custom domain, your users would have UPNs like user@contoso.onmicrosoft.com, which is not suitable for business. Additionally, custom domains are required for: - Email delivery: The MX record for your domain must point to Exchange Online. - Single sign-on (SSO): Federated domains enable seamless authentication with on-premises Active Directory Federation Services (AD FS) or Azure AD Connect. - Branding: Custom domains appear in SharePoint URLs, Teams meeting invites, and other services.
Domain Verification Process
Verification proves you own the domain. The process involves:
1. Add the domain in Microsoft 365 admin center (Domains > Add domain).
2. Obtain a TXT record value from Microsoft 365 (e.g., MS=msXXXXXXXX).
3. Create a TXT record at your domain registrar with that value.
4. Wait for propagation (typically a few minutes to 72 hours).
5. Click Verify in Microsoft 365 admin center.
Microsoft 365 checks for the TXT record. If found, the domain is marked as verified. The TXT record can be removed after verification, but it is recommended to keep it for future re-verification.
DNS Record Configuration
After verification, you must add DNS records to route services to Microsoft 365. The required records depend on which services you plan to use. Common records include:
- MX record: Points to Exchange Online (e.g., contoso-com.mail.protection.outlook.com) with priority 0.
- CNAME records:
- autodiscover → autodiscover.outlook.com (for Outlook client auto-configuration)
- lyncdiscover → webdir.online.lync.com (for Skype for Business Online, if used)
- sip → sipdir.online.lync.com (for SIP traffic)
- msoid → clientconfig.microsoftonline-p.net (for Office 365 client authentication)
- TXT records:
- @ with v=spf1 include:spf.protection.outlook.com -all (SPF to authorize Microsoft 365 to send email)
- _dmarc with v=DMARC1; p=reject; (optional, for email authentication)
- SRV records:
- _sip._tls → priority 100, weight 1, port 443, target sipdir.online.lync.com
- _sipfederationtls._tcp → priority 100, weight 1, port 5061, target sipfed.online.lync.com
Domain Types: Standard vs. Federated
Standard (Managed) domain: Microsoft 365 handles user authentication. Passwords are stored in Azure AD. This is the default.
Federated domain: Authentication is delegated to an on-premises identity provider (e.g., AD FS). Users sign in with their on-premises credentials. This requires Azure AD Connect and federation trust configuration.
To convert a domain from managed to federated, use PowerShell cmdlets like Convert-MsolDomainToFederated. The domain must first be verified as a standard domain.
Adding Subdomains
You can add subdomains (e.g., sales.contoso.com) to your tenant. Subdomains inherit the verification of the parent domain but require separate DNS records. For example, if contoso.com is verified, you can add sales.contoso.com without re-verifying ownership. However, you must configure DNS records (MX, SPF, etc.) for the subdomain.
Removing a Custom Domain
To remove a custom domain, you must first remove all dependencies:
Remove or change all user UPNs and email addresses that use the domain.
Remove or change group email addresses (distribution groups, mail-enabled security groups).
Remove or change SharePoint site URLs if they use the domain.
Remove any federated trust if the domain is federated.
Then, in the admin center, select the domain and choose Remove. The domain will be unverified and can be reused elsewhere.
Domain Health and Troubleshooting
Microsoft 365 provides a Domain Health dashboard in the admin center. It shows the status of DNS records (correct, missing, or misconfigured). Common issues: - MX record missing: Email will not be delivered to Exchange Online. - SPF record missing or misconfigured: External email servers may reject or mark email as spam. - Autodiscover CNAME missing: Outlook clients cannot automatically configure email settings. - Duplicate TXT records: Multiple SPF records can cause email failures.
PowerShell for Domain Management
Use the Azure AD module or Microsoft Graph PowerShell SDK to manage domains. Example commands:
# Connect to Azure AD
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
# List all domains
Get-MgDomain
# Add a domain
New-MgDomain -Id "contoso.com"
# Verify a domain (initiate verification)
Confirm-MgDomain -DomainId "contoso.com"For federation:
Convert-MsolDomainToFederated -DomainName "contoso.com"Interaction with Azure AD Connect
If you use Azure AD Connect to sync on-premises AD, custom domains in Microsoft 365 must match the UPN suffix in on-premises AD. Azure AD Connect will automatically verify the domain if it is already verified in Microsoft 365. If not, you must verify it manually. For federated domains, Azure AD Connect can configure federation during setup or later via PowerShell.
Default Values and Timers
TXT record value format: MS=msXXXXXXXX (where XXXXXXXX is a unique alphanumeric string).
Verification check interval: Microsoft 365 checks for the TXT record every few minutes; propagation can take up to 72 hours.
DNS record TTL: Typically 1 hour (3600 seconds); reduce to 5 minutes during changes.
Domain removal: After removing dependencies, the domain is removed immediately.
Exam-Relevant Details
You can add up to 900 custom domains per tenant.
Each domain must be unique across all Microsoft 365 tenants (no two tenants can have the same verified domain).
The initial .onmicrosoft.com domain cannot be removed or changed.
Federated domains require a federation trust (e.g., AD FS) and cannot be used for all users if the identity provider is unavailable.
Subdomains do not require separate verification if the parent domain is verified.
SPF record is required for email delivery; include all sources that send email on behalf of the domain.
Add the Custom Domain
Navigate to Microsoft 365 admin center > Settings > Domains > Add domain. Enter the domain name (e.g., contoso.com). Select the services you plan to use (Exchange, SharePoint, Teams, etc.). Microsoft 365 will generate a TXT record value for verification. Do not proceed until you have access to your domain registrar's DNS management interface.
Verify Domain Ownership
At your domain registrar, create a TXT record with the name `@` (or your domain) and the value provided by Microsoft 365 (e.g., `MS=ms12345678`). Save the record. Wait for DNS propagation (check using tools like `nslookup -type=txt contoso.com`). In the admin center, click Verify. Microsoft 365 queries the DNS for the TXT record. If found, the domain status changes to Verified. The TXT record can be removed after verification, but keeping it allows re-verification without re-entering the value.
Configure Required DNS Records
After verification, the admin center shows a list of recommended DNS records. Add each record as instructed: MX record pointing to Exchange Online, CNAME records for Autodiscover, Lync, and SIP, TXT records for SPF and DMARC, and SRV records for Skype for Business. Use the exact target values provided. Incorrect values may cause service disruption. For example, the MX record target is `contoso-com.mail.protection.outlook.com` (replace `contoso-com` with your domain with hyphens).
Update User UPNs and Email Addresses
Once DNS records are propagated, update user UPNs to use the new domain. In the admin center, select a user, edit the UPN, and choose the custom domain. Alternatively, use PowerShell: `Set-MgUser -UserId user@contoso.onmicrosoft.com -UserPrincipalName user@contoso.com`. For bulk updates, consider Azure AD Connect. If you change the UPN, the user's sign-in name changes. Ensure users are informed.
Set as Default Domain (Optional)
If you want all new users to automatically get the custom domain, set it as the default domain. In the admin center, go to Domains, select the custom domain, and choose Set as default. The default domain is used for new user creation. The initial `.onmicrosoft.com` domain remains as a secondary domain. You cannot remove the initial domain.
Scenario 1: Migrating from On-Premises Exchange to Exchange Online
A mid-sized company with 500 users is migrating from on-premises Exchange 2016 to Exchange Online. They own contoso.com and have been using it for email. The IT team needs to add the domain to Microsoft 365, verify ownership, and configure DNS records. The MX record must be changed from the on-premises server to Exchange Online at the cutover time. To avoid email loss, they lower the TTL of the MX record to 5 minutes a few days before migration. They also add SPF record to include both on-premises and online sources during transition (v=spf1 include:spf.protection.outlook.com include:mail.contoso.com -all). After migration, they remove the on-premises include. Common pitfall: forgetting to update Autodiscover CNAME, causing Outlook clients to fail auto-configuration. They verify Autodiscover by running the Microsoft Remote Connectivity Analyzer.
Scenario 2: Multi-Domain Enterprise with Federated Authentication
A large enterprise with 10,000 users and multiple subsidiaries (e.g., contoso.com, fabrikam.com) wants to use custom domains with single sign-on. They use AD FS for authentication. Each domain must be added and verified in Microsoft 365, then converted to federated using Convert-MsolDomainToFederated. They configure Azure AD Connect to sync on-premises UPNs that match the custom domains. For each domain, they must update the federation trust metadata. Performance consideration: AD FS should be load-balanced and highly available; otherwise, authentication failures occur. They also configure the domain_hint parameter in Azure AD to bypass the home realm discovery page for federated users. A common misconfiguration is not updating the AD FS relying party trust after adding a new domain, causing sign-in errors.
Scenario 3: Start-Up Using Only Microsoft 365
A start-up with 20 employees uses Microsoft 365 exclusively. They purchase a new domain, startup.io, and want to use it for email and SharePoint. They add the domain, verify with TXT record, and configure DNS records. They set the domain as default. However, they also want to use a subdomain, blog.startup.io, for a separate SharePoint site. They add the subdomain without verification (parent is verified) and configure separate DNS records. They encounter an issue where email to blog.startup.io is not delivered because they forgot to add an MX record for the subdomain. They realize that subdomains require their own MX record if they want email. They also need to add an SPF record for the subdomain to avoid spoofing.
MS-102 Objective Alignment
This topic aligns with Objective 1.1: Manage tenants, specifically:
Add and configure custom domains
Verify domain ownership
Configure DNS records for Microsoft 365 services
Manage domain health
Understand federated vs. managed domains
Common Wrong Answers and Why Candidates Choose Them
Using an A record instead of a CNAME for Autodiscover: Candidates think Autodiscover needs an A record pointing to an IP. However, Autodiscover requires a CNAME pointing to autodiscover.outlook.com because Exchange Online uses a hostname, not an IP. An A record would break client configuration.
Setting the MX record priority too high: Some set priority to 10 or higher, thinking higher is better. In DNS, lower priority is preferred. The correct priority is 0 for Exchange Online. If set to 10, mail may be routed elsewhere first.
Removing the TXT verification record immediately after verification: While allowed, exam questions emphasize that keeping it helps with future re-verification. Removing it is not recommended.
Assuming subdomains require separate verification: Many think every domain must be verified. Actually, subdomains of a verified domain inherit verification. The exam tests this distinction.
Exact Numbers and Terms on the Exam
Maximum custom domains per tenant: 900
Default initial domain format: <tenantname>.onmicrosoft.com
TXT record prefix: MS=ms
MX record target pattern: <domain-hyphenated>.mail.protection.outlook.com
SPF record for Exchange Online: v=spf1 include:spf.protection.outlook.com -all
Autodiscover CNAME target: autodiscover.outlook.com
Edge Cases and Exceptions
If a domain is already verified in another tenant, you cannot add it to yours. You must remove it from the other tenant first.
Federated domains cannot be used for users who are not synced from on-premises (cloud-only users must use a managed domain).
When removing a domain, you cannot remove it if it is the default domain. You must first set another domain as default.
If you have multiple domains, each must have its own SPF record; do not include multiple SPF records in the same TXT record.
How to Eliminate Wrong Answers
If a question asks about verification, look for the TXT record option. Never choose a CNAME or MX for verification.
For email routing, the MX record is the key. If email is not flowing, check MX first.
For Outlook client issues, check Autodiscover CNAME.
For spam issues, check SPF record.
For federated sign-in issues, check federation trust and domain conversion.
Custom domains must be verified via TXT record before use.
Subdomains of a verified domain do not require separate verification.
The MX record for Exchange Online must point to <domain-hyphenated>.mail.protection.outlook.com with priority 0.
SPF record must include include:spf.protection.outlook.com to authorize Microsoft 365 to send email.
Autodiscover requires a CNAME record pointing to autodiscover.outlook.com.
Maximum 900 custom domains per tenant.
The initial onmicrosoft.com domain cannot be removed or changed.
Federated domains require on-premises identity infrastructure.
Domain removal requires removing all dependencies (users, groups, etc.).
Domain health dashboard shows DNS record status.
These come up on the exam all the time. Here's how to tell them apart.
Managed Domain
Authentication handled by Azure AD.
Passwords stored in the cloud.
No on-premises infrastructure required.
Easier to manage for cloud-only organizations.
Default domain type when added.
Federated Domain
Authentication delegated to on-premises identity provider (e.g., AD FS).
Passwords stored on-premises.
Requires Azure AD Connect and federation server.
Enables single sign-on with on-premises credentials.
Must be converted from managed using PowerShell.
Mistake
You can have multiple SPF records for the same domain.
Correct
DNS allows only one SPF record per domain. Multiple SPF records cause SPF failure (PermError). Combine all authorized senders in a single SPF record using include statements.
Mistake
Subdomains must be verified separately even if the parent domain is verified.
Correct
Subdomains inherit verification from the parent domain. You can add a subdomain without re-verifying, but you must configure its own DNS records.
Mistake
The onmicrosoft.com domain can be removed or changed.
Correct
The initial tenant domain (e.g., contoso.onmicrosoft.com) is permanent and cannot be removed or renamed. It remains as a secondary domain.
Mistake
You can add any domain even if another tenant has verified it.
Correct
Each custom domain can be verified in only one Microsoft 365 tenant. If another tenant has verified it, you must remove it from that tenant first.
Mistake
Federated domains work for cloud-only users.
Correct
Federated domains require the user to be synced from on-premises and authenticated against the on-premises identity provider. Cloud-only users cannot use a federated domain.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Verification typically completes within a few minutes after the TXT record is added to DNS, but DNS propagation can take up to 72 hours. You can speed it up by reducing the TTL of the TXT record to 5 minutes before adding it. Microsoft 365 checks for the record every few minutes.
No. A custom domain can be verified in only one Microsoft 365 tenant at a time. If you need to move it, you must remove it from the current tenant first. However, you can add subdomains to different tenants if the parent domain is not in use there.
Nothing immediately. The domain remains verified. However, if you later need to re-verify (e.g., after a domain transfer), you would need to add the record again. It's recommended to keep the TXT record.
Use the Azure AD module for Windows PowerShell: `Convert-MsolDomainToFederated -DomainName "contoso.com"`. This requires an existing federation trust (e.g., AD FS) and that the domain is already verified. The domain must be set as 'Standard' initially.
Check the MX record: it must point to Exchange Online with priority 0. Also ensure SPF record includes `include:spf.protection.outlook.com`. Use the Microsoft Remote Connectivity Analyzer to test email flow. Common mistake: MX record pointing to on-premises server or incorrect target.
No. The initial tenant domain (e.g., contoso.onmicrosoft.com) is permanent and cannot be removed. It remains as a secondary domain and can be used for internal services.
'Verified' means ownership is confirmed. 'Provisioned' means the domain is fully configured with DNS records and ready for use. A domain can be verified but not provisioned if DNS records are missing.
You've just covered Custom Domain Management in Microsoft 365 — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?