How are DNS records managed during Microsoft 365 migration?

DNS records are managed during a Microsoft 365 migration by treating the organisation’s DNS zone as a controlled dependency rather than changing records informally at the point of cutover. The process establishes who controls the domain, which provider hosts its DNS, which services depend on each record, and how changes will be approved, tested and reversed if necessary.

Before making changes, the migration plan should distinguish between the domain registrar and the authoritative DNS host. These may be different organisations, and access to one does not necessarily provide access to the other. Administrative access, multi-factor authentication, recovery details and the relevant DNS permissions should be confirmed in advance. If the DNS host is managed by a third party, its change process and escalation route should also be recorded.

The existing zone should be reviewed for more than Microsoft 365-related entries. Websites, web applications, VPNs, remote access platforms, telephone systems, customer portals and other hosted services may rely on DNS records that must remain unchanged. A record inventory should therefore include the record type, name, value, purpose, owner and any known dependency. This helps prevent an apparently minor edit from interrupting an unrelated service.

DNS changes are normally separated into planned stages. Domain ownership and service configuration can be prepared before users are moved, while records that direct production traffic are changed only when the relevant migration step is ready. This separation reduces the chance of directing users or mail systems towards a destination that has not yet been fully configured. It also makes it easier to identify whether a problem relates to DNS, account configuration, authentication or the application itself.

Propagation requires particular care. Different recursive DNS resolvers may retain answers for different periods, based on the time to live (TTL) attached to a record and their own caching behaviour. A change can therefore appear active from one location while an older answer is still being returned elsewhere. Migration planning should allow for this inconsistency and avoid assuming that a successful lookup from one device proves that the change is visible everywhere.

Validation should be performed from more than one network and, where appropriate, with more than one DNS lookup method. Checks can confirm that the intended names resolve to the expected destinations, that obsolete destinations are no longer being returned, and that records unrelated to the migration are still intact. Email testing should examine both inbound and outbound delivery, while service testing should cover the domain names used by staff, devices and integrated applications.

Security records need careful interpretation. Sender policy must reflect the systems that are authorised to send mail, and duplicate or conflicting policy entries should not be created. Signing and reporting controls should be checked against the final mail-routing design, particularly where another service still sends messages on the organisation’s behalf. A migration can appear technically successful while legitimate messages fail authentication if these dependencies are overlooked.

Some organisations use internal DNS as well as public DNS. In that situation, internal resolvers may return different answers from public resolvers, especially for services that use split-horizon DNS or internal-only names. Both views should be assessed, including the effect on laptops, mobile devices, remote workers and sites connected through private networks. A public lookup alone cannot confirm that internal users will receive the correct result.

Records should be changed through an agreed change-control process. The request should identify the exact name, type, value and reason for each alteration, along with the planned sequence, test criteria and rollback action. Screenshots or exported zone information can provide a useful before-and-after record, but sensitive credentials and private keys must not be copied into general migration documentation.

Rollback is not simply the act of restoring an earlier value. Cached responses may continue to direct traffic according to the previous or new answer, depending on when each resolver obtained it. A rollback plan should therefore state which services can be reverted, which configuration must also be changed at the destination, and how delivery or access will be monitored while DNS caches converge.

After the migration, the DNS zone should be reviewed for temporary entries, legacy destinations, duplicate policies and permissions that are no longer required. Unused records can disclose information about old systems or create confusion during future changes, but removal should take place only after confirming that no business service still depends on them. The final record set and ownership details should then be added to the organisation’s technical documentation.

For a small or medium-sized organisation without dedicated DNS expertise, this work often forms part of the wider Microsoft 365 migration plan. S2 Technology Group can help businesses around Stourbridge, Kinver, Wordsley, Kingswinford, Kidderminster, Halesowen, Dudley and neighbouring areas assess DNS dependencies, coordinate controlled changes and validate the resulting configuration alongside the wider IT environment.