One of my good AD aware friends pinged me yesterday while I was at work asking about what was the specific AdFind command to find out the additional (or alternate) UPN Suffixes that may be defined for a domain. I responded back with a quick answer off the top of my head that it was on the Partitions container in the configuration container. I don’t usually like giving short answers like that but I was at work and that is the time I had available.
Once off work I did a quick google to find where someone had written this up before so I could share it. The several top links I kept clicking on just talked about how to do this from Domains and Trusts so I thought, WTH, I will write it up and hopefully this post will become one of the top posts for adding or viewing additional (or alternate) UPN Suffixes so people know you don’t have to use the GUI.
So the quick (and possibly wrong depending on your actual need, more on that later) answer is that you can find the additional (or alternate) UPN Suffixes defined in AD with the following query.
adfind -partitions -s base upnsuffixes
Or if you want to point to an AD Forest that isn’t your default forest you can use
adfind -h domainname -partitions -s base upnsuffixes
Why is that possibly wrong? Let’s walk through it.
So first the way most sites and instructions seem to be giving you for adding additional (or alternate) UPN Suffixes is to open Domains and Trusts (domain.msc) and right click on the top line that shows what you are connected to and then click on Properties which will give you the following dialog box which you can then populate with the additional (or alternate) UPN Suffixes you care to use.
What is placed there can indeed be found with the command shown above as so:
[Mon 02/13/2017 19:30:23.13]
E:\DEV>adfind -h k16tst.test.loc -partitions -s base upnsuffixes
AdFind V01.50.00.00cpp VS BETA Joe Richards (joe@joeware.net) February 2016
Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2016
Base DN: CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc
dn:CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: cloud.joeware.org
1 Objects returned
Further if you want to add an additional (or alternate) UPN Suffix from the command line you can rather simply accomplish that with AdMod like so:
[Mon 02/13/2017 19:30:26.77]
E:\DEV>admod -h k16tst.test.loc -partitions upnsuffixes:+:cloud.joeware.net
AdMod V01.18.00cpp Joe Richards (joe@joeware.net) March 2012
DN Count: 1
Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2008 R2
Base DN: CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc
Modifying specified objects…
DN: CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc…
The command completed successfully
And holy crap I just realized I haven’t released a new version of AdMod in 5 years. Ugh.
Anyway now it looks like:
[Mon 02/13/2017 19:34:54.22]
E:\DEV\>adfind -h k16tst.test.loc -partitions -s base upnsuffixes
AdFind V01.50.00.00cpp VS BETA Joe Richards (joe@joeware.net) February 2016
Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2016
Base DN: CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc
dn:CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: cloud.joeware.net
>uPNSuffixes: cloud.joeware.org
1 Objects returned
And in domain.msc
So what does it look like when you want to create a new user in ADUC (dsa.msc) now?
It looks like this:
Wow totally cool right? 
But wait, I don’t see why anything above could possibly be wrong per your earlier parenthetical declaration.
So a little known fact and likely even less used (probably a good thing) configuration you can put into place is to set the additional (or alternate) UPN Suffixes at the OU level and have those additional (or alternate) UPN Suffixes only “take effect” in ADUC at that one and only level of the OU hierarchy in the forest. It will actually override the forest level additional (or alternate) UPN Suffixes that are displayed in in ADUC.
Though you can still use a tool that lets you specify an arbitrary UPN to set it to anything you choose, this configuration only forces validation within ADUC’s main user creation/modification forms and not within the Directory Service itself.
For example:
[Mon 02/13/2017 19:36:04.17]
E:\DEV>admod -h k16tst.test.loc -default -rb ou=users2,ou=testou upnsuffixes:+:deviantsoftware.net
AdMod V01.18.00cpp Joe Richards (joe@joeware.net) March 2012
DN Count: 1
Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2008 R2
Base DN: ou=users2,ou=testou,DC=k16tst,DC=test,DC=loc
Modifying specified objects…
DN: ou=users2,ou=testou,DC=k16tst,DC=test,DC=loc…
The command completed successfully
[Mon 02/13/2017 19:37:45.50]
E:\DEV>adfind -h k16tst.test.loc -default -rb ou=users2,ou=testou upnsuffixes
AdFind V01.49.00.00cpp Joe Richards (joe@joeware.net) February 2015
Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server Threshold
Base DN: ou=users2,ou=testou,DC=k16tst,DC=test,DC=loc
dn:OU=Users2,OU=TestOU,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: deviantsoftware.net
1 Objects returned
Here is what it looks like when you try to create a user via ADUC in that specific OU.
But here is what happens if you go to a subOU of the OU that you set the additional (or alternative) UPN Suffix value. Note that the additional (or alternative) OU specific UPN Suffixes are not displayed.
Again, though you can still use a tool that lets you specify an arbitrary UPN to set it to anything you choose, this configuration only forces validation within ADUCs main user creation/modification forms and not within the Directory Service itself.
You may recall, as it was only seconds ago for you, that I mentioned that you can set the UPN Suffix on a user’s UPN to ANY value you choose. That is generally true but isn’t correct in all use cases. It works perfectly in a single forest where you are not expecting anyone to use the values outside of that forest – say in the case of a cross forest trust. In a cross forest trust the external forests need to know where to route the userid authentication requests to and it does that via the domain names combined with the registrations of the UPN Suffixes on the Partitions object in the Configuration container. Anything NOT listed there will not be able to be used across a cross-forest trust.
And that also means the additional (or alternate) UPN Suffixes ONLY stamped on OUs cannot be routed across a forest trust either. In fact when you try to establish a trust after you have set some suffixes up as we did here in this post, you will see a message like this:
Note the lack of the extra additional (or alternate) UPN Suffix I had assigned to the OU?
If you need the routing you can set the additional (or alternate) UPN Suffix on the Partitions container AND on the OU. The setting at the OU level tells ADUC (or any tool smart enough to look for that attribute on the OU) to limit the UPN Suffix display and the setting on the Partitions container tells the rest of the world who has a forest trust where to go to resolve the ID to a principal to perform the authentication.
But joe, you say fervently and with no trust, what if you just deleted that extra OU level additional (or alternate) UPN Suffix prior to creating that trust and we just didn’t see that step? Well you have to trust me that I didn’t. Alternately I guess I can show you let see what AdFind says because, you know, trust but verify…
[Tue 02/14/2017 8:01:05.20]
E:\DEV>adfind -h k16tst.test.loc –gcb -f upnsuffixes=* upnsuffixes -e ad
AdFind V01.50.00.00cpp VS BETA Joe Richards (joe@joeware.net) February 2016
Using server: K16TST-DC1.k16tst.test.loc:3268
Directory: Windows Server 2016
Base DN: DC=k16tst,DC=test,DC=loc
0 Objects returned
Err wait… what?? Maybe I did lie!!! Or wait, maybe AD is lying???
How about this then…
[Tue 02/14/2017 8:06:12.55]
E:\DEV>adfind -h k16tst.test.loc -prb -f upnsuffixes=* upnsuffixes
AdFind V01.50.00.00cpp VS BETA Joe Richards (joe@joeware.net) February 2016
Using server: K16TST-DC1.k16tst.test.loc:389
Directory: Windows Server 2016
Base DN:
dn:CN=Partitions,CN=Configuration,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: cloud.joeware.net
>uPNSuffixes: cloud.joeware.org
dn:OU=Users2,OU=TestOU,DC=k16tst,DC=test,DC=loc
>uPNSuffixes: deviantsoftware.net
2 Objects returned
If you don’t have AdFind V01.50.00 VS BETA which is everyone but me as I write this then you can use -pr with -null in the place of -prb.
Did you catch that?
In the category of leaving them wanting more… I will now end this post. The –pr(b) switch vs the –gc(b) switch is a good discussion for later. 
joe
p.s. It is nice to knock the rust off and get the old blog post fingers running again.
Nice write-up joe!
One of the big reasons people care about alternate UPN suffixes is because many AD forests have non-resolvable FQDNs like dogfood.local or root.ad. When migrating to Office 365, they want people to log in with their email address because, well, it saves a ton of communication and configuration. This means adding an alternate UPN suffix which matches your email domain. There’s another step that’s not obvious, in a trusted multi-forest environment – especially if you want to use those suffixes in other forests (for example, with ADFS). After adding a suffix, you must go into the other forest, ON THE PDC, and enable Name Suffix Routing for that new UPN suffix. I’m not sure if there’s more info easily obtainable with adfind to see suffixes for which routing is enabled or disabled. But this is not an obvious step.
very good article joe..