Registration
Registrar, registrant, expiration, auto-renew, payment, transfer lock, and recovery.
Microsoft 365 domain and DNS governance
Microsoft 365 Domain Lifecycle and DNS Ownership Review Guide
Protect the full chain behind a Microsoft 365 custom domain: legal registration, registrar access, authoritative DNS hosting, Microsoft 365 verification, email routing and authentication, controlled change, renewal, transfer, and retirement.
Registrar ownershipDNS authorityMail continuityDecommissioning evidence
Review objective
Prove who owns every control plane
A custom domain depends on organizations and systems outside the Microsoft 365 tenant. Losing registrar access, missing renewal, changing nameservers without a zone copy, or editing MX and email-authentication records without validation can interrupt sign-in, mail flow, device enrollment, applications, websites, and customer trust.
Legal ownerRegistrant identity and business authority are current and documented
Technical ownerRegistrar, DNS host, Microsoft 365, and mail records have named owners
Recovery pathStrong authentication, backup contacts, recovery codes, and vendor escalation
Lifecycle evidenceRenewal, change, transfer, and retirement decisions remain traceable
Delegation
Authoritative nameservers, DNS host, DNSSEC, zone access, API tokens, and exports.
Microsoft 365
Verified/default domain, accepted-domain behavior, identities, aliases, groups, and apps.
Service records
MX, Autodiscover, SPF, DKIM, DMARC, verification TXT, third-party senders, and web records.
Registrar and DNS host are not always the same provider. Document both systems and the authoritative nameservers. A registrar login alone may not provide access to the active DNS zone.
Domain inventory
Minimum record for every business domain
| Area | What to record | Owner and evidence | Review trigger |
|---|---|---|---|
| Business identity | Domain purpose, legal/business owner, brands, production status, business services, criticality. | Domain register, owner approval, service map. | Acquisition, rebrand, divestiture, new service, or annual review. |
| Registrar | Provider, account/tenant ID, registrant, admin/technical contacts, expiry, auto-renew, payment, transfer lock. | Registrar export/screenshots, recovery test, named business owner. | Contact/payment change, renewal, provider transfer, or access failure. |
| DNS hosting | Authoritative nameservers, provider/account, zone ID, DNSSEC state, API credentials, access roles, export/backup. | NS query, provider configuration, access review, zone export. | Nameserver, provider, credential, DNSSEC, or automation change. |
| Microsoft 365 | Verification status, default use, accepted-domain type, identities, aliases, groups, applications, and tenant purpose. | Admin-center/Exchange reports, object queries, architecture record. | Tenant migration, domain removal, UPN/SMTP change, or merger. |
| Email routing | MX targets/priority, connectors, gateways, hybrid path, third-party filtering, continuity dependencies. | DNS query, mail-flow diagram, test messages, connector evidence. | Mail migration, gateway change, incident, or vendor termination. |
| Email authentication | SPF sources/lookup budget, DKIM selectors and enablement, DMARC policy/addresses, reporting owner. | Published records, Microsoft settings, aggregate reports, test results. | New sender, provider change, key rotation, or DMARC policy change. |
Lifecycle runbook
Seven controlled stages from acquisition to retirement
Domain work crosses legal, financial, identity, messaging, web, security, and vendor teams. Use a cross-functional record rather than treating DNS as an isolated technical task.
Acquire and register
Use a business-controlled account, accurate registrant details, role-based access, MFA, recovery contacts, auto-renew, approved payment, transfer lock, and domain inventory entry.
Delegate DNS
Confirm authoritative nameservers and DNS host ownership. Enable supported security controls, restrict API tokens, export the zone, and document recovery and change paths.
Verify in Microsoft 365
Add the custom domain and publish the tenant-specific verification record. Record the tenant, verification method, default-domain decision, and intended services.
Prepare identities and mail
Create required users/mailboxes and plan UPN/SMTP, accepted domains, coexistence, connectors, third-party senders, Autodiscover, and support communication before changing MX.
Publish and validate
Change records under approval, honor TTL/propagation, query multiple resolvers, test inbound/outbound mail, validate SPF/DKIM/DMARC, and monitor user/business impact.
Operate and renew
Monitor expiration, contacts, nameservers, DNS changes, certificates, mail authentication, third-party senders, vendor access, and recovery readiness.
Retire or transfer
Inventory every Microsoft 365 and external reference, move identities/services, preserve required data, change routing, remove tenant dependencies, and retain ownership defensively where appropriate.
Microsoft 365 DNS records
Review purpose, source of truth, and change impact
| Record | Purpose | Review checks | Common failure |
|---|---|---|---|
| TXT verification | Proves domain ownership to Microsoft 365 without routing production traffic. | Tenant-specific value, change record, whether obsolete verification records can be removed. | Wrong zone, copied value, stale multi-tenant proof, or use of MX verification with unsafe priority. |
| MX | Routes inbound email to Exchange Online or an approved gateway. | Targets, priorities, old provider records, gateway/connector alignment, TTL, failover assumptions. | Competing MX paths, stale former provider, unexpected gateway bypass, or wrong priority. |
| Autodiscover CNAME | Helps supported Outlook clients locate Exchange Online configuration. | Correct target, hybrid design, legacy conflicts, resolver results, certificate implications. | Legacy server target, conflicting A/CNAME, split-DNS difference, or cached stale record. |
| SPF TXT | Declares authorized sending infrastructure for the domain. | Single SPF record, all approved senders, mechanisms/qualifier, DNS lookup budget, ownership of includes. | Multiple SPF records, missing vendor, excessive lookups, broad mechanisms, or stale include. |
| DKIM CNAME | Delegates Microsoft 365 DKIM selectors and supports cryptographic signing. | Both selectors, tenant-specific targets, DKIM enabled, selector rotation, alignment and message tests. | Copied from another tenant/domain, one missing selector, DNS present but DKIM disabled. |
| DMARC TXT | Publishes alignment policy and reporting destinations. | Policy, percentage, subdomain policy, report addresses, authorization for external destinations, reporting owner. | Enforcement before sender discovery, unread reports, invalid syntax, or unmanaged report mailbox. |
SPF rule: do not create a second SPF record for Microsoft 365. Microsoft recommends maintaining one SPF TXT record that includes every authorized sender. Test lookup count and message alignment before enforcement changes.
Security and recovery
Harden the registrar and DNS control planes
Registrar security
- Business-owned account and current legal registrant
- Phishing-resistant MFA where supported
- Least-privileged users and no shared credentials
- Transfer lock and registry lock where justified
- Auto-renew, approved payment, and expiry alerts
- Tested recovery contacts and vendor escalation
DNS-host security
- Separate roles for read, change, and administration
- Short-lived or scoped automation/API credentials
- Change logs, alerts, approvals, and zone backups
- DNSSEC ownership and rollover documentation
- Nameserver and high-risk record monitoring
- Emergency rollback and provider support path
Microsoft 365 ownership
- Least-privileged domain and Exchange roles
- Protected emergency tenant access
- Accepted-domain and identity dependency inventory
- Mail-flow connector and gateway ownership
- SPF/DKIM/DMARC reporting and response owners
- Tenant-to-tenant removal runbook
Change control
Use a DNS change plan that can be rolled back
Before the change
- Record current authoritative answers and export the zone.
- Identify resolver/TTL behavior and lower TTL only when justified well in advance.
- Map dependent mail, identity, web, certificate, VPN, SaaS, and validation services.
- Prepare exact old/new values, approval, maintenance window, communication, and rollback.
- Verify target service readiness before changing routing records.
During and after
- Apply one controlled set of changes and capture provider audit evidence.
- Query authoritative and public recursive resolvers; do not rely on one local cache.
- Validate Microsoft 365 domain health, inbound/outbound mail, Autodiscover, and sender authentication.
- Monitor queues, non-delivery reports, help-desk demand, DMARC results, and business workflows.
- Close with propagation evidence, results, residual risk, and restored TTL where planned.
MX cutover: Microsoft recommends creating users and mailboxes before moving MX to Microsoft 365. A DNS change is not a mailbox migration or mail-flow design by itself.
Common failure modes
Risks to find before an outage or takeover
Former employee or vendor owns access
Registrar, DNS host, recovery email, payment, or API control remains tied to an external or departed person.
Renewal is fragile
Auto-renew is off, payment is expired, notices go to an unmonitored mailbox, or no secondary owner validates renewal.
Nameservers are undocumented
The registrar points to a DNS host no one owns, or a planned provider transfer lacks a complete zone and DNSSEC plan.
Mail path is unclear
MX, gateway, connector, hybrid, third-party filtering, and accepted-domain behavior do not match the documented architecture.
Email authentication is stale
Former senders remain in SPF, DKIM is not enabled or rotated, DMARC reports are unread, or enforcement exceeds sender readiness.
Domain cannot be removed
Users, admin sign-ins, aliases, mailboxes, contacts, groups, applications, or accepted-domain dependencies still reference it.
Retirement and transfer
Remove dependencies before removing the domain
Microsoft requires a custom domain to stop being the default and to be removed from identities and messaging objects before tenant removal. Large environments require queries and evidence beyond what a single portal page can show.
Microsoft 365 objects
- User sign-in names and admin accounts
- Primary/secondary SMTP proxy addresses
- Shared and resource mailboxes, contacts
- Distribution lists, Microsoft 365 groups, Teams
- Applications, service principals, and federation
- Accepted domain, connectors, policies, rules
External services
- Websites, redirects, certificates, CDN/WAF
- SaaS verification and single sign-on
- Marketing, CRM, ticketing, bulk senders
- VPN, remote access, monitoring, APIs
- Partner allowlists and customer workflows
- DNSSEC, CAA, and delegation dependencies
Safe closure
- Move identities and mail with communication
- Preserve required mail/data and legal holds
- Change MX and sender authentication deliberately
- Validate no remaining tenant references
- Retain domain registration defensively when needed
- Document final disposition and rollback limits
Removing a custom domain can cause accounts to revert to the tenant’s onmicrosoft.com domain. Validate the current Microsoft removal behavior, user impact, mail routing, and migration sequence before approving the change.
Evidence package
Evidence for an audit-ready domain record
Ownership
- Registrant and business owner
- Registrar/DNS accounts and current contacts
- Access-role and MFA review
- Renewal/payment and recovery validation
Technical state
- Nameserver and zone export
- Microsoft 365 domain/accepted-domain inventory
- MX, SPF, DKIM, DMARC, Autodiscover results
- Mail-flow and third-party sender map
Lifecycle
- Change approvals and validation
- Transfer/renewal records
- Incident and rollback evidence
- Retirement dependency and closure checklist
Related ecosystem guides
Continue into DNS, email authentication, and Exchange ownership
Authoritative Microsoft references
FAQ
Microsoft 365 domain and DNS ownership FAQ
Is the domain registrar always the DNS host?
No. The registrar manages the domain registration and delegation, while a different provider can host the authoritative DNS zone. Record both providers and confirm the nameservers actually delegated at the registry.
Can Microsoft 365 manage DNS for every custom domain?
Management depends on the registrar/DNS integration and chosen setup. Many organizations retain DNS with a third-party provider and publish the Microsoft-provided records there.
Should we create a second SPF record for Microsoft 365?
No. Microsoft advises maintaining a single SPF TXT record that includes Microsoft 365 and every other approved sender. Multiple SPF records can cause SPF evaluation errors.
What should be tested after an MX change?
Validate authoritative and public DNS answers, inbound and outbound mail for representative recipients, gateways/connectors, non-delivery reports, Autodiscover, SPF/DKIM/DMARC alignment, queues, monitoring, and user/business impact.
What prevents a domain from being removed from Microsoft 365?
The domain cannot be default or remain referenced by users, admin sign-ins, aliases, mailboxes, contacts, groups, Teams, distribution lists, and other tenant objects. Query and remediate every dependency before removal.
Protect the domain behind Microsoft 365
IT Perfection helps Orange County and Southern California organizations document registrar and DNS ownership, plan Microsoft 365 domain changes, secure email records, validate mail flow, prepare transfers, and retire domains safely.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience. DNS, registrar, Microsoft 365, email, and contractual behavior change; validate current provider documentation and test in context. This guide is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review.
