Any downside to adding a UPN instead of trying to correct our AD domain name?

Unfortunately I inherited an Active Directory domain whose name is a DNS name the company does not own - we'll call it ABC.com. I would like it to be something under company.com instead (per MDMarra's answer on AD naming I'd probably use ad.company.com since you never want to use a DNS name you use for anything else), but the hard requirement for now is to be able to move email to Office 365 this year and using Directory Synchronization. For that, it looks like at a minimum I need a matching UPN to our email domain (company.com). Ok, the process for adding a second UPN seems simple enough. Testing it and moving accounts over until they are all on the desired UPN seems reasonable enough.

Is there any downside to just doing this? Will the technical debt grim reaper eventually arrive if we stay on this 'non-owned' domain name of ABC.com indefinitely?

For reference, we have a single forest, single domain with everything (forest, functional level, all DCs) at 2012R2 level and Exchange 2010 on this domain. There are around 150 users and 450 computers in AD (lots of dev/test automation). While I've safely navigated us from 2003 forward to 2012R2, I would by no means call myself an expert at AD.

It doesn't look like domain renames are generally advised, and since we have Exchange 2010 on our domain I don't believe it would even be an option.

As I see it, I could either:

• add a second UPN and be done. I can deal with having to manually set the UPN on things as we create/add them...
• add a second domain to the forest, move everything over, and always have this legacy root domain forever that I can't remove
• create a second forest, forest <-> forest trust, do everything the way I really want it on this new forest from the ground up...move everything, and eventually remove the original forest. Really slow, really carefully, tested forwards and back, and probably at great expense (at a minimum in time spent). In a dream world this seems best, but I am not sure I can justify a business case for this (unless someone states a grim reaper arrival will occur).
• ??? something else I haven't thought of

Solution 1:

So, existential crisis about not owning the domain you're using internally aside - from an Office 365 perspective this is fine. Office 365 cares about verifying the email domains that you have in use, not your AD domain. So the approach that you've taken by changing the UPNs to match the users' email addresses is appropriate and correct.

Now, from a purely AD perspective, you will never be able to get a third party certificate for that internal DNS domain since you don't own it. This may or may not be an issue for you. You'll also never be able to make a trust with another domain that shares the same name, so in the unlikely event that you merge with the company that owns that domain and they are also using that name, you'll have migration nightmares. I'd imagine the probability of this is somewhere close to 0.

It's a lot of work and potentially very disruptive to end users to rename or migrate out of a domain. At this point, I'm typically of the opinion that you should just leave the poorly named domain unless one of those edge cases is causing you heartache and just make sure you get it right on the next go-around :)