Active Directory Domain Naming Best Practices
For a new Active Directory Domain Services forest, the safest default is a short, stable subdomain of a DNS name your organisation has registered. If the public domain is example.com, use an AD DS name such as ad.example.com or corp.example.com, then give users a verified sign-in suffix such as user@example.com.
Recommended starting point
- Registered parent domain:
example.com - AD DS forest root domain:
ad.example.com - NetBIOS domain name:
AD - User sign-in name:
alex@example.com - Public DNS zone:
example.com, hosted separately from the AD-integrated zone
Example domains are reserved for documentation. Replace them with a domain your organisation actually owns.
Start with the correct terminology
The original version of this article treated the Active Directory domain name and DNS name as separate concepts. That is incorrect. An AD DS domain has a fully qualified DNS name, while Windows also maintains a shorter NetBIOS name for compatibility.
| Name | Example | Purpose |
|---|---|---|
| AD DS DNS domain name | ad.example.com | The directory namespace used by domain controllers, Kerberos, LDAP and AD-integrated DNS. |
| NetBIOS domain name | AD | The legacy short name used in sign-ins such as AD\alex. |
| User Principal Name | alex@example.com | The modern user sign-in name. Its suffix can differ from the AD DS DNS domain name. |
| Computer primary DNS suffix | ad.example.com | Normally matches the AD DS domain in a contiguous namespace. |
A disjoint namespace exists when a domain member’s primary DNS suffix does not match its AD DS domain name. Windows Server supports this design, but Microsoft warns that it is more complex and that applications which assume the names match may fail. Do not create one accidentally.
The preferred design: a subdomain of a registered name
Microsoft’s current guidance is consistent: use a globally unique DNS name registered to your organisation, or a subdomain beneath one. For a public name such as example.com, suitable AD DS forest root names include:
ad.example.comcorp.example.comds.example.com
Choose a functional, durable prefix. Avoid a product, office location, business unit or abbreviation that may become obsolete after a reorganisation, merger or divestment. The forest root name remains foundational for the lifetime of the forest, so a boring name is usually a good name.
Microsoft’s forest-root planning guidance recommends registered suffixes, warns against single-label names and unregistered suffixes such as .local, and suggests stable prefixes such as corp or ds.
Designs that can work, but cost more to operate
Using the same name internally and externally
You can name the AD DS domain example.com while also publishing a public example.com zone. This is commonly called split-brain, split-horizon or split-view DNS. It is not inherently unsupported, but the internal DNS servers become authoritative for the internal copy of the zone. Public records needed by internal users—such as www, mail services and validation records—must also exist in that internal view.
The design creates more coordination and a greater chance of inconsistent answers. Microsoft’s DNS namespace planning guidance therefore recommends avoiding overlapping internal and external namespaces in most cases. A dedicated AD subdomain is usually easier to explain, delegate and troubleshoot.
Using a different registered domain
An organisation may use example.com publicly and a second registered name such as example.net for AD DS. This remains globally unique, but it increases naming and identity complexity. Users may see one domain in email, another in service URLs and a third in legacy sign-ins. Use this pattern only when the separation has a clear operational purpose.
Names to avoid for a new AD DS forest
Single-label names
Do not create a domain named only CORP or CONTOSO. Single-label DNS domains cannot be registered, require special DNS behaviour and are incompatible with some applications. Current Windows Server deployment tools block new single-label AD DS domains. Microsoft also describes moving away from one as a non-trivial migration rather than a simple rename.
.local
Do not use company.local for a new enterprise AD DS forest. The .local suffix has special link-local meaning in Multicast DNS. RFC 6762 explicitly recommends against using it as a private unicast DNS suffix because clients may send queries to multicast DNS, creating delays, inconsistent answers and interoperability problems.
Invented suffixes such as .lan or .corp
An invented suffix is not guaranteed to remain collision-free. Devices move between networks, companies merge, VPNs join namespaces and the public root evolves. Names that appear private can leak into other resolvers or collide with another organisation’s internal design.
What about .internal?
In July 2024, the ICANN Board reserved .INTERNAL for private-use applications and directed that it must never be delegated in the public DNS root. That removes the risk of a future public .internal top-level domain, but it does not make private uses globally unique. Two companies can still create the same name and collide during a merger, VPN connection or shared-service project. Microsoft’s AD DS guidance continues to recommend a registered namespace, so .internal is not the default choice for a new enterprise forest.
Documentation and special-use names
Names such as .test, .example, .invalid, .localhost, and example.com, example.net and example.org are reserved for special use or documentation. They are useful in articles and laboratories, not as production AD DS namespaces. The IANA Special-Use Domain Names registry is the authoritative list.
Plan user sign-in names separately
The AD DS DNS name does not need to be the suffix users type when signing in. If the forest is ad.example.com, add example.com as an alternative UPN suffix and assign users names such as alex@example.com. This gives users a familiar sign-in while retaining a dedicated directory namespace.
For Microsoft Entra ID and Microsoft 365, the UPN suffix must be added and verified as a custom domain. Otherwise, synchronised users may receive the tenant’s .onmicrosoft.com suffix. Microsoft’s Entra Connect sign-in guidance explains how on-premises UPN suffixes are matched to verified cloud domains.
DNS zones are not security boundaries
Names such as dmz.example.com or extranet.example.com can make a design easier to understand, but the label itself provides no isolation. Protect DMZ, partner and internal services with separate network controls, firewall policy, identity boundaries and appropriately placed authoritative DNS servers. Do not join an exposed server to the production forest merely because its DNS name sits under a “DMZ” subdomain.
Domain members should normally use the organisation’s internal DNS resolvers, which host or can locate the AD-integrated zones. Those resolvers can forward unresolved public queries upstream. Pointing domain members directly at public DNS resolvers prevents reliable discovery of domain controllers and other AD services.
Naming checklist for a new forest
- Choose a DNS parent domain that the organisation has registered and controls.
- Select a short, stable AD DS prefix such as
ad,corpords. - Confirm that the resulting name is not already used internally, externally, by an acquired company or by a connected partner.
- Use letters, numbers and hyphens in DNS labels; avoid underscores, spaces and non-standard punctuation.
- Keep the AD DS FQDN reasonably short. Microsoft documents a 64-character limit, and a prefix of 15 characters or fewer allows the NetBIOS name to match.
- Decide which verified UPN suffix users will use for Microsoft Entra ID and Microsoft 365.
- Document ownership of the internal and public zones, forwarders, conditional forwarders and split-DNS records.
- Test certificates, VPN clients, device management, Linux integration, applications and merger scenarios before deployment.
Microsoft’s current AD naming-conventions reference documents the supported characters, length constraints, reserved names and collision risks in detail.
If the existing domain already uses a poor name
A working .local or single-label forest is not an emergency that should be renamed without a business case. Domain rename has broad application dependencies, and Microsoft’s current guidance notes that current Microsoft applications do not support domain renaming. Treat remediation as a migration programme: inventory applications and certificates, add a verified alternative UPN suffix where appropriate, test hybrid identity, and compare a supported forest migration with the risks of renaming in place.
Official references
- Microsoft: Selecting the forest root domain
- Microsoft: Naming computers, domains, sites and OUs
- Microsoft: Active Directory domains that use single-label DNS names
- Microsoft: DNS namespace planning
- Microsoft: Entra Connect user sign-in and UPN planning
- RFC 6762: Multicast DNS and
.local - ICANN: Reserving
.INTERNALfor private use
Article rewritten in June 2026. The original article did not clearly distinguish between AD DS, DNS and NetBIOS naming and did not reflect current Microsoft, Entra ID and DNS guidance.
