Microsoft 365 Custom Domains & Tenant Health
Add and verify custom domains, configure service DNS and email authentication, and monitor Microsoft 365 service health without relying on stale DNS targets.
Overview
A Microsoft 365 custom domain must be added to the tenant, verified through public DNS, and configured for every service that will use it. Verification proves control of the DNS namespace; it does not automatically configure Exchange Online, Teams, Intune, identity, third-party senders, or email authentication.
DNS records must be created at the domain's authoritative DNS provider. The registrar and DNS host can be different. For example, a domain registered at one provider can use Cloudflare nameservers, in which case Microsoft 365 records belong in Cloudflare.
Changing the tenant's default domain affects defaults for newly created objects. It does not automatically rename existing users, groups, aliases, SharePoint URLs, or application identifiers.
---
Domain Onboarding Sequence
- Inventory all services that currently use the domain:
- websites and subdomains
- mailboxes and aliases
- third-party mail senders
- federation or application redirect URIs
- certificates and DNS validation records
- In the Microsoft 365 admin center, add the domain.
- Copy the exact TXT verification record Microsoft displays.
- Create the TXT record at the authoritative DNS host.
- Wait for public DNS propagation and select Verify.
- Add only the Microsoft 365 service records required for the intended workload.
- Validate mail flow and email authentication before changing the default domain or primary addresses.
- Keep the original
onmicrosoft.comdomain available for recovery and service dependencies.
Microsoft 365 admin center (https://admin.microsoft.com)
└── Settings > Domains
├── Add domain
├── Verify ownership
├── Review DNS records
└── Set as default where appropriate---
DNS Records
Use the values shown in the tenant because service targets and tenant identifiers can differ.
| Record | Purpose | Important notes |
|---|---|---|
| TXT verification | Proves domain ownership | Temporary verification record can normally remain without affecting mail flow. |
| MX | Routes inbound mail | Lower preference value is preferred. Remove legacy MX records only after migration planning. |
| SPF TXT | Authorizes sending sources | Publish one SPF record per sending domain and include all legitimate senders. Multiple SPF records cause evaluation failure. |
| CNAME/SRV | Service discovery and client configuration | Create only the records required by the tenant's current setup wizard. |
| DKIM CNAME | Delegates signing-key selectors to Microsoft 365 | Copy both selector targets exactly from the Defender/Exchange configuration for the domain. Do not hard-code an old target pattern. |
| DMARC TXT | Defines alignment policy and reporting | Start with monitored reporting, fix legitimate senders, then move deliberately toward quarantine/reject. |
A subdomain that sends mail needs its own authorization/authentication design. Do not assume the parent domain's SPF record automatically covers every sending subdomain.
---
SPF, DKIM, and DMARC
SPF
Start from the current Microsoft guidance and add every approved third-party sender without exceeding SPF DNS-lookup limits.
v=spf1 include:spf.protection.outlook.com -allThe example is valid only when Microsoft 365 is the sole authorized sender. Marketing, ticketing, ERP, scanners, and application relays might require additional includes or dedicated subdomains.
DKIM
- Open the email-authentication settings in the Microsoft Defender portal.
- Select the custom domain.
- Create the two CNAME records shown for selector1 and selector2.
- Wait for DNS resolution.
- Enable DKIM and confirm outbound messages include a passing aligned DKIM signature.
DMARC
DMARC evaluates alignment between the visible From domain and SPF and/or DKIM authentication domains.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100"Use p=none for initial visibility, analyze aggregate reports, correct all approved senders, and then implement quarantine or reject according to the organization's risk decision. A p=none record monitors; it does not stop spoofing.
Enforcing DMARC before inventorying legitimate third-party senders can reject valid business mail. Conversely, leaving DMARC indefinitely at p=none provides reporting but no receiver-side enforcement request.
---
Mail-Flow Verification
After DNS changes:
- send inbound and outbound messages through representative paths
- inspect message headers for
spf=pass,dkim=pass, anddmarc=pass - test aliases and shared mailboxes
- confirm third-party systems use supported authenticated submission or relay
- check Exchange Online message trace and Defender Explorer where licensed
- verify no legacy MX or connector creates unintended routing
PowerShell output complements public DNS and message-header testing; it does not prove that every external sender aligns.
---
Service Health and Message Center
Microsoft 365 admin center
└── Health
├── Service health
└── Message center- Service health shows active incidents, advisories, affected services, status history, and tenant-specific impact where available.
- Message center announces planned changes, retirements, feature rollouts, and required administrator actions.
For automation, Microsoft Graph service communications can query health-overview, service-announcement, and message-center data with the documented permissions. Do not build monitoring around undocumented HTML scraping or assume the portal retains every historical item indefinitely.
Operational monitoring should:
- distinguish Microsoft incidents from local DNS/network/identity failures
- record incident ID and update timestamps
- subscribe the correct administrators to notifications
- track message-center items with owners and due dates
- avoid reporting a service as healthy merely because no API result was returned
---
Troubleshooting
| Symptom | Likely cause | Action |
|---|---|---|
| Domain verification fails | TXT record is at the wrong DNS host, wrong name/value, proxy/flattening issue, or propagation is incomplete | Query authoritative and public resolvers, confirm nameservers, and copy the exact Microsoft value. |
| Inbound mail still reaches old provider | MX cache/priority or old connector | Confirm authoritative MX records and message headers; allow migration coexistence only when designed. |
SPF returns PermError | Multiple SPF records, syntax error, or more than 10 DNS-producing lookups | Merge into one record and simplify approved sender paths. |
| DKIM cannot be enabled | CNAME targets or selectors do not match the tenant | Use the exact values displayed for the domain and verify public CNAME resolution. |
| DMARC fails despite SPF pass | SPF authenticated domain does not align with visible From domain | Enable aligned DKIM or redesign the third-party sender/return path. |
| New users receive wrong suffix | Default domain or user-creation workflow is not configured as expected | Review tenant default and provisioning rules; existing objects require explicit updates. |
| Service-health API returns no data | Permission, consent, endpoint, or service issue | Treat as monitoring failure, not proof of health; validate in the admin center. |
---
Production Practices
- Keep DNS ownership, registrar, nameservers, emergency access, and renewal contacts documented.
- Protect registrar and DNS-provider accounts with phishing-resistant MFA.
- Use low TTLs only during controlled migrations, then restore normal caching.
- Separate bulk/application mail onto dedicated subdomains when it simplifies reputation and authentication.
- Publish SPF, enable DKIM, and progress DMARC toward enforcement.
- Review accepted domains, connectors, aliases, and third-party senders regularly.
- Assign Message center actions and test service-health alerting.
---
MS-102 Exam Notes
- Domain verification uses public DNS and only proves ownership.
- DNS records belong at the authoritative DNS provider, not necessarily the registrar.
- SPF authorizes senders; DKIM signs mail; DMARC evaluates alignment and requests receiver policy.
- One sending domain should have one SPF record.
- Service health covers incidents; Message center covers planned changes and administrator actions.
---