This is a Canonical Question about Active Directory domain naming.

After experimenting with Windows domains and domain controllers in a virtual environment, I've realized that having an active directory domain named identically to a DNS domain is bad idea (Meaning that having example.com as an Active Directory name is no good when we have the example.com domain name registered for use as our website).

This related question seems to support that conclusion, but I'm still not sure about what other rules there are around naming Active Directory domains.

Are there any best practices on what an Active Directory name should or shouldn't be?

Anton Gogolev
  • 1,582
  • 4
  • 16
  • 22

5 Answers5


This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.

I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.

So, if you own foo.com, use ad.foo.com or some such.

The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com into their browser would be redirected to www.foo.com by these IIS installations. Utter silliness!

Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)

Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)

I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.

Anthony Geoghegan
  • 2,875
  • 1
  • 24
  • 34
Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • 2
    But then NetBIOS name of the domain is not... well, pretty :) `corp` is not as descriptive as `foo`. – Anton Gogolev Oct 21 '09 at 13:26
  • 36
    You can assign whatever NetBIOS name you want, though. Many of my Customers have names like "ad.example.com", but the NetBIOS name is "EXAMPLE". DCPROMO will prompt you for what you'd like the NetBIOS name to be during creation of the domain. – Evan Anderson Oct 21 '09 at 13:32
  • 5
    if you do this watch out for problems with domains that have wildcards. When you have *.foo.com, host.internal.foo.com will match it in some situations – JamesRyan Oct 21 '09 at 15:12
  • What about e-mail? If the domain is `ad.company.com`, all domain users will automatically get addresses like `login@ad.company.com`. – ivan_pozdeev Jul 04 '15 at 14:38
  • 2
    I am not aware of any email server product that requires you to use the AD domain name as the users' email address suffix. Exchange has _never_ required any kind of correlation between the AD domain name and email address suffixes. – Evan Anderson Jul 04 '15 at 19:46
  • What about Office365? =) – Jerome Haltom Jul 22 '15 at 19:47
  • @wasabi - I'm not aware of Office365 having any dependence on the AD domain name. Granted, I have limited experience with it, only having assisted in migrations to off-premise Exchange for only a couple of Customers, but the integration with the on-site AD is reasonably arms-length (through ADFS, DirSync, etc). – Evan Anderson Jul 23 '15 at 03:01
  • 3
    Office365 only requires that your users logon with their UPN with a suffix matching your tenant domain. Since the default Exchange mailbox address policy can be defined to be anything, as can your UPN suffix, it is trivial. We have EXAMPLE.COM as our company name (and tenant in Office365), EXAMPLE.NET (also registered) as the forest, CORP.EXAMPLE.NET as the primary account domain (with other regional sub-domains, e.g. EU.EXAMPLE.NET) with EXAMPLE as the NetBIOS name, all users in the forest Exchange org use Name@EXAMPLE.COM for UPN and for email. Office365 is perfectly happy with this. – Ryan Fisher Sep 09 '15 at 23:16
  • Given that it has no effect on anything else if chosen at the start, but is painful to change later, a descriptive, short, a whole word, and unlinked from the board of directors could be a good idea. Having a NetBIOS name of `ad`, `corp`, or maybe better `work` is not such a bad idea, and is growing on me. It would survive the company directors musical chairs with company names. Plus explaining why `rndshrtcmpnynme\ ` is needed before their username when they log in sometimes is painful, instead just tell them if they want to log in to work, always use `work\username`. – BeowulfNode42 Jan 16 '19 at 23:29
  • 1
    If we are creating an AD domain and forest from scratch, should the forest root domain name be `example.com`, or `ad.example.com`? I know that the domain should be `ad.example.com`, but I'm asking specifically about the forest. – longneck Jun 02 '22 at 16:37
  • 1
    @longneck - The forest root domain would be `ad.example.com` in my scenario. – Evan Anderson Nov 29 '22 at 18:18

There are only two correct answers to this question.

  1. An unused sub-domain of a domain that you use publicly. For example, if your public web presence is example.com your internal AD might be named something like ad.example.com or internal.example.com.

  2. An unused second-level domain that you own and don't use anywhere else. For example, if your public web presence is example.com your AD might be named example.net as long as you have registered example.net and don't use it anywhere else!

These are your only two choices. If you do something else, you're leaving yourself open to a lot of pain and suffering.

But everyone uses .local!
Doesn't matter. You shouldn't. I've blogged about the use of .local and other made up TLDs like .lan and .corp. Under no circumstances should you ever do this.

It's not more secure. It's not "best practices" like some people claim. And it doesn't have any benefit over the two choices that I've proposed.

But I want to name it the same as my public website's URL so that my users are example\user instead of ad\user
This is a valid, but misguided concern. When you promote the first DC in a domain, you can set the NetBIOS name of the domain to whatever you want it to be. If you follow my advice and set up your domain to be ad.example.com, you can configure the domain's NetBIOS name to be example so that your users will log on as example\user.

In Active Directory Forests and Trusts, you can create additional UPN suffixes as well. There's nothing stopping you from creating and setting @example.com as the primary UPN suffix for all accounts in your domain. When you combine this with the previous NetBIOS recommendation, no end user will ever see that your domain's FQDN is ad.example.com. Everything that they see will be example\ or @example.com. The only people that will need to work with the FQDN are the systems admins that work with Active Directory.

Also, assume that you use a split-horizon DNS namespace, meaning that your AD name is the same as your public-facing website. Now, your users can't get to example.com internally unless you have them prefix www. in their browser or you run IIS on all of your domain controllers (this is bad). You also have to curate two non-identical DNS zones that share a disjoint namespace. It's really more hassle than it's worth. Now imagine that you have a partnership with another company and they also have a split-horizon DNS configuration with their AD and their external presence. You have a private fiber link between the two and you need to create a trust. Now, all of your traffic to any of their public sites has to traverse the private link instead of just going out over the Internet. It also creates all kinds of headaches for the network admins on both sides. Avoid this. Trust me.

But but but...
Seriously, there's no reason not to use one of the two things that I've suggested. Any other way has pitfalls. I'm not telling you to rush to change your domain name if it's functioning and in place, but if you're creating a new AD, do one of the two things that I've recommended above.

Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • 100,734
  • 32
  • 197
  • 329
  • 2
    A small point - one can use something much smaller, faster and secure than IIS to serve the redirect. Even haproxy or nginx are probably overkill - let alone a full-featured server like apache2. – OrangeDog Jan 29 '13 at 17:21
  • 9
    This is true, but *all* of that is sloppy and unnecessary. – MDMarra Jan 29 '13 at 18:08
  • Uuuuw yeah, it was so painful when someone suddenly registered the domain local.net and all the printers who silently got NXDOMAIN before that date suddenly did not answer anymore. That was some funny investigation... – Johannes Kohnen Aug 26 '13 at 20:49
  • May I just note that .local is not "made up" it is in fact reserved; just not for this type of use: http://en.wikipedia.org/wiki/.local – mikebabcock Mar 11 '15 at 14:25
  • At the time this was written, it was not reserved. – MDMarra Mar 11 '15 at 19:47
  • in your #2, you say an unused second-level domain... isn't example.com and example.net two different domains with different TLD's. Wouldn't a second-level domain be sample.com (with the same TLD as example.com)? or am I really confused in the domain naming scheme? – Reece Mar 10 '16 at 02:25
  • @ReeceDodds "net" "com" "edu" are all top level domains. Namespaces one level deeper are second-level. In my example, some companies choose to buy .com and .net and use .com on the Internet and .net internally. Does that make sense? It doesn't really matter what the suffix is, it's just an example. The point is you should be using a namespace that you own that isn't used elsewhere. – MDMarra Mar 10 '16 at 02:28
  • yeah it does make sense. That's what I thought - I was just being pedantic I think... I was trying to clarify that a 2nd level domain would be different (eg. example and sample) regardless of what the TLD and prefix/sub-domain was. The main thing of your point is that it has to be different and not used anywhere else. Cheers – Reece Mar 10 '16 at 02:51
  • +1 for the `.local` misconception. – Michael-O Mar 04 '20 at 12:41

To assist MDMarra's answer:

You should NEVER use a single-label DNS name for your domain name either. This was/is available prior to Windows 2008 R2. Reasons/explanations can be found here: Deployment and operation of Active Directory domains that are configured by using single-label DNS names | Microsoft Support

Don't forget to NOT use reserved words (a table is included in the "Naming Conventions" link at the bottom of this post), such as SYSTEM or WORLD or RESTRICTED.

I also agree with Microsoft in that you should follow two additional rules (that aren't set in stone, but still):

  1. You should NOT name your domain based on something that will change or become outdated. Examples include naming your domain after a product line, operating system, or anything else that is likely to change over time. Stick with something either geographical or concrete enough to make sense 5 or even 10 years down the road.
  2. Stick with short names of 15 characters or less, this will allow for the NETBIOS name to easily be the same as the domain name.

Finally, I would recommend that you think long term as much as possible. Companies do go through mergers and acquisitions, even small companies. Also think in terms of getting outside help/consultation. Use domain names, AD structure, etc. that will be explainable to consultants or people here on SF without much effort.

Knowledge links:




Microsoft's current (W2k12) recommendation page for the root forest domain name

  • 32,627
  • 26
  • 132
  • 191

I disagree with using:

  • example.com - for reasons already stated in other answers

I could accept using:

  • ad.example.com - - for reasons already stated in other answers

But I wouldn't do it myself or recommend it. During company takeover, rebranding all hell breaks loose especially when management at that point wants things to change right away. Renaming migrations, changes are very hard or expensive.

Best way I would recommend is to buy domain that's irrelevant to company name and also irrelevant to company's brand. SIMPLE.CLOUD or similar should do just fine as long as you can own it.

I've seen big companies with 150k users using AD that's still referencing old company they bought years ago, or companies that changed names and even though it doesn't matter in the long run that you are using \login (if you can't use UPN) it's still looks bad in front of management who doesn't understand why it's not trivial to change it.

  • 3,725
  • 15
  • 63
  • 94

I always do mydomain.local.

local is not a valid TLD, so it never competes with an actual public DNS entry.

For example, I like being able to know that web1.mydomain.local will resolve to the internal IP of a web server, while web1.mydomain.com will resolve to the external IP.

  • 5,271
  • 4
  • 28
  • 31
  • 8
    FWIW, [`.local` queries hammer on the root L-server](http://stats.l.root-servers.org/cgi-bin/dsc-grapher.pl?window=604800&plot=qtype_vs_all_tld&server=L-root) -- ~800/sec when I looked. – jscott Sep 23 '10 at 20:11
  • 2
    dot.Local, AKA dot.Fail – PnP Apr 13 '15 at 08:23
  • 3
    Using an invalid TLD (or an unregistered domain) isn't a best practice, it's a worst practice, for all the reasons mentioned above. I'll admit that I have used .local, but that was before I knew better. – Jonathan J Sep 09 '16 at 20:05