2.2 Implementing and Managing Domains

Quick Answer: Adding a custom domain in Microsoft 365 means proving ownership via a DNS TXT (or MX) record, then adding the service-specific DNS records that route mail (MX), enable client auto-config (CNAME Autodiscover), authenticate senders (SPF TXT, DKIM CNAME, DMARC TXT), and enable Teams/Skype federation (SRV). Exchange Online classifies each accepted domain as Authoritative, Internal Relay, or External Relay. Setting a domain as default changes the UPN suffix used for new users.

Adding a Custom Domain

Every tenant ships with the initial *.onmicrosoft.com domain. Most organizations add one or more custom public domains (e.g., contoso.com) so email, SharePoint, and Teams use the org's own namespace. The high-level flow in the Microsoft 365 admin center → Settings → Domains → Add domain is:

1. Enter the domain name (e.g., contoso.com)
2. Choose verification method — Microsoft recommends a TXT record, but an MX record is also supported
3. Add the provided DNS record at your DNS hosting provider (GoDaddy, Cloudflare, Azure DNS, Route 53, etc.)
4. Click Verify — Microsoft queries public DNS for the record and, if found, marks the domain verified
5. Choose which services to configure (Exchange, Teams, Intune) and add the additional DNS records the wizard provides

Verification proves you own the namespace. It is a one-time step per domain; the verification record can be left in place or removed after verification succeeds (leaving it is harmless and simplifies re-verification).

Tip: If your DNS provider is one of the supported registrars integrated into the M365 admin center (GoDaddy, Cloudflare, and several others), the wizard can write the records for you after you sign in. Otherwise you copy the records manually.

DNS Records Required for Microsoft 365 Services

After verification, each service you enable needs specific DNS records. The M365 admin center's domain setup wizard lists exactly what to add. The following table is the authoritative reference shape — know it for the exam.

| DNS record | Purpose | Typical value | ||--|--|--| | TXT (verification) | Proves domain ownership | Random token provided by M365, e.g., MS=ms12345678 | | MX | Routes inbound email to Exchange Online | Points to <tenant>.mail.protection.outlook.com, priority 0 or 10 | | TXT (SPF) | Authorizes sending mail servers for the domain | v=spf1 include:spf.protection.outlook.com -all | | CNAME (Autodiscover) | Lets Outlook/mobility clients auto-configure | autodiscover → autodiscover.outlook.com | | CNAME (DKIM) | Enables DKIM signing for the domain — two records, selector1 and selector2 | selector1._domainkey → selector1-contoso-com._domainkey.contoso.onmicrosoft.com (and selector2._domainkey → selector2-…). Newly created domains are issued the modern …-v1.dkim.mail.microsoft form instead. | | TXT (DMARC) | Instructs receivers how to handle SPF/DKIM failures | v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@contoso.com | | SRV (SIP federation) | Enables Teams/Skype for Business federation and IM presence | _sipfederationtls._tcp → port 5061, target sipfed.online.lync.com | | CNAME (MDM/Intune enrollment) | Enables mobile device management enrollment | enterpriseregistration → enterpriseregistration.windows.net |

MX Record Specifics

The MX record for Exchange Online always points to <tenant-name>.mail.protection.outlook.com, where <tenant-name> is the part of the initial .onmicrosoft.com domain before the suffix. The MX priority should be lower (higher priority) than any on-premises mail server's MX if you are running a hybrid configuration, or the only MX for the domain in a cloud-only setup. Do not point the MX at a specific mailbox server — it points at the Exchange Online Protection (EOP) edge.

SPF, DKIM, and DMARC — Modern Email Authentication

Email authentication is a recurring exam theme. Three DNS-based mechanisms work together:

• SPF (Sender Policy Framework) — a TXT record listing which IP addresses/services are authorized to send mail for the domain. For M365-only senders: v=spf1 include:spf.protection.outlook.com -all. The -all is a hard fail; ~all is a soft fail used during rollout.
• DKIM (DomainKeys Identified Mail) — adds a cryptographic signature to outbound mail. Mail sent from the tenant's initial *.onmicrosoft.com domain is DKIM-signed automatically, but for each custom domain you must publish the two selector CNAMEs and then enable DKIM in the Microsoft Defender portal → Email authentication settings → DKIM. Note the boundary: enabling DKIM here signs mail that leaves through Exchange Online. It does nothing for a third-party bulk-mail service sending as your domain — that provider must publish its own DKIM selector records and be added to your SPF record.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) — a TXT record at _dmarc.<domain> that tells receivers what to do when SPF or DKIM fail: p=none (monitor), p=quarantine (send to junk), p=reject (drop). DMARC also defines reporting addresses (rua/ruf).

The recommended rollout order is SPF → DKIM → DMARC p=none (monitor) → tighten to quarantine → reject. Skipping to reject before SPF/DKIM are aligned causes legitimate mail to be dropped.

Exchange Online Accepted Domains

Once a verified custom domain is used for email, it appears as an accepted domain in Exchange Online (managed in the Exchange admin center → Mail flow → Accepted domains). Three types exist:

Accepted domain type interacts with email address policies (the rules that stamp the primary SMTP address on each mailbox) and with outbound connectors that route mail to on-premises or partner systems.

Default Domain and UPN Suffix

Each tenant has one default domain — the domain used to complete a new user's UPN and primary email address when no domain is explicitly chosen. Initially the default is the .onmicrosoft.com domain. After you add and verify a custom domain, you can set it as the default in Settings → Domains → (select domain) → Set as default.

Changing the default domain changes the UPN suffix assigned to new users. It does not retroactively change existing users' UPNs — those must be updated separately, either in the M365 admin center user edit flow or in bulk with Microsoft Graph PowerShell (Update-MgUser -UserId <id> -UserPrincipalName <new UPN>). Do not reach for the legacy Set-MsolUserPrincipalName: the MSOnline module is retired (see section 6.2). Aligning UPN with the user's email address simplifies sign-in and reduces support tickets, because users can use one value for both M365 sign-in and email.

Domain Health and Troubleshooting

The Domains page in the M365 admin center shows a health/status column per domain. Common issues:

• DNS propagation delay — new or edited DNS records can take minutes to 48 hours to propagate globally; verify with nslookup or dig against public resolvers
• Misconfigured MX — mail flow stops or bounces; the Domains page flags missing or wrong-priority MX records
• SPF too restrictive or too loose — -all with missing authorized senders drops legitimate mail; +all or missing SPF invites spoofing
• DKIM not enabled — outbound mail fails DMARC alignment; enable DKIM in the Defender portal for each custom domain
• DMARC set to reject prematurely — drops mail from unconfigured sending services; start with p=none and review reports
• Removed or changed verification record — generally harmless after verification, but some flows require the record to be present

Removing and Replacing Domains

You can remove a custom domain from the tenant, but only after you reassign all users, groups, and resources that reference it (UPN suffixes, primary SMTP addresses, SharePoint sharing URLs). The .onmicrosoft.com initial domain cannot be removed. Microsoft also blocks removing a domain that is still set as the default — you must first set another domain as default.

Key Takeaways

• Verify domain ownership with a TXT (preferred) or MX record at your DNS provider
• Each M365 service needs specific DNS records — know the MX/SPF/Autodiscover/DKIM/SRV set
• Accepted domains are Authoritative, Internal Relay, or External Relay; Internal Relay is the hybrid case
• Setting a custom domain as default changes the UPN suffix for new users, aligning sign-in with email
• Enable SPF, then DKIM, then DMARC starting at p=none; do not jump to reject until alignment is verified