In Office 365 end users can sign up for trial subscriptions for service. These services may include PowerBI or Azure Rights Management as an example. The services that users were trialing often required cloud storage or services in order to service the trial. Prior to October 2021 when users signed up for these trials a “viral” or “unmanaged” Office 365 tenant was created on behalf of the trial and the user. The email domain utilized for the trial, if not associated with another Office 365 tenant, would be added to this unmanaged Office 365 instance. After October 2021 this behavior no longer occurs and has been replaced with a one time passcode process. For more information see Email one-time passcode authentication on by default starting October 2021 | Azure updates | Microsoft Azure.

 

Many administers discover that there exists a viral tenant when they choose to use the domain in the unmanaged tenant within their Office 365 instance. If the domain exists in an unmanaged tenant, it cannot be added and validated to another tenant through the standard domain add process. We have two self-service options that allow administrators to assume ownership of this domain. Admin takeover of an unmanaged directory – Microsoft Entra | Microsoft Learn. In many cases the self-service options are sufficient to allow the administrator to remove the domain and successfully validate it in the tenant of their choice.

Administrators may also test for the existence of a domain registered in Office 365 using the following link:

https://login.microsoftonline.com/common/userrealm/domain.com?api-version=2.1

Administrators replace domain.com with the domain they wish to test. If the domain is not found the following is displayed:

 

{

“NameSpaceType”: “Unknown”,

“Login”: “domain.com”,

“cloud_instance_name”: “microsoftonline.com”

}

 

If the domain is found the following information is displayed:

 

{

“NameSpaceType”: “Managed”,

“Login”: “contoso.com”,

“DomainName”: “contoso.com”,

“FederationBrandName”: “Contoso, Ltd”,

“TenantBrandingInfo”: null,

“cloud_instance_name”: “microsoftonline.com”

}

 

I recently encountered an interesting scenario where the self service options did not work. The customer that I worked with had a registered domain in their production tenant contoso.com. They also had a subdomain domain.consoto.com that they had previously used for other purposes. This domain had a legitimate external DNS namespace and an MX record pointing to Office 365. In Exchange Online the customer has configured an accepted domain contoso.com and enabled the option to accept email for this domain and all subdomains. In essence email should have been routed correctly into Office 365 and the email addresses at this subdomain functioning.

 

When the customer chooses to utilize this sub domain they noted that NDRs were generated to these addresses.

 

451 4.4.4 Mail received as unauthenticated, incoming to a recipient domain configured in a hosted tenant which has no mail-enabled subscriptions. ATTR5 [DM3NAM02FT022.eop-nam02.prod.protection.outlook.com 2023-05-10T16:06:51.301Z 08DB5127CEBAA8D8]

 

Why did this NDR occur? In this case the customer was relying on the accept mail for all subdomains feature to accept mail into their Exchange Online environment where the subdomains were not verified and added to the tenant explicitly. When mail arrives in Exchange Online, we attempt to attribute the mail to a particular tenant. In this instance the message arrived in Exchange Online due to the MX record pointing to the MX of the customers production tenant and parent domain, but the domain was attributed to the viral tenant. The viral tenant had no mail enable subscriptions, so the message was not delivered.

 

It was the non-delivery report that started the investigation of the domain and the determination it was registered to a viral tenant. The customer, having researched this began the process of asserting ownership of the domain to their production tenant. In order to assert ownership of the domain you must be able to receive email at the domain or be able to add the domain and validate it forcefully with a DNS entry. This is where things got slightly complicated.

 

The domain namespace was set to route email to the customers only email solution Exchange Online. Exchange Online was already rejecting the requests. This prevented the customer from using the internal takeover method and simply providing validation and accessing the viral tenant. To use the email option the customer would have had to find another place to route the domain email and subsequently receive it. This was not an option.

 

This led us to investigate the user of the external admin takeover method. I generally prefer the external takeover method myself as it does not involve accessing the original tenant, cleaning it up, and then removing the domain. The external method essentially just allows us to add the domain, validate it, and move on. If this method exists, why did it not work in this particular instance. In Office 365 when you add a subdomain where the parent domain is registered the domain is automatically validated. The domain has the presence of the RootDomain attribute signifying the parent / child domain relationship exists in Office 365. Attempting to add the domain with new-msolDomain generated an “unknown error”. The error was actually known in that the domain could not be added and automatically validated since it existed in an unmanaged viral tenant. If you are unable to add the domain, you are unable to get the proof of domain ownership, and therefore unable to forcefully takeover the domain.

 

Add and verify custom domain names – Microsoft Entra | Microsoft Learn

 

Add subdomains of a custom domain

If you want to add a subdomain name such as ‘europe.contoso.com’ to your organization, you should first add and verify the root domain, such as contoso.com. The subdomain is automatically verified by Azure AD. To see that the subdomain you added is verified, refresh the domain list in the browser.

If you have already added a contoso.com domain to one Azure AD organization, you can also verify the subdomain europe.contoso.com in a different Azure AD organization. When adding the subdomain, you are prompted to add a TXT record in the DNS hosting provider.

 

The self-service instructions were not going to easily work in this instance. Where there is a will there is a way! In order to self service the takeover of this domain where email could not be received by another solution we needed to use a tenant where the parent / child relationship did not exist. Fortunately for us the customer we were working with had a development tenant where the parent domain contoso.com did not exist (obviously because it existed in their production tenant). We were able to use the development tenant to add the domain, secure the ownership validation, and verify domain ownership forcefully using the external admin takeover method. Once the domain was successfully added to the development tenant it was then removed. Removing the domain freed the domain from all tenants. The customer could then add the domain explicitly to their production tenant where automatic validation was able to succeed, and the domain was added as an automatically verified subdomain of an existing parent domain. We also assume that if necessary, a trial tenant could have been utilized in place of the development tenant for these purposes.

 

I decided to write this up because it was a first for me. When I saw this in the past the customers I was working with had the ability to receive email at an alternate location for the domain. This allowed us to proceed with the internal admin takeover. The inability to receive email was a unique variable to this scenario. Although there is not necessarily a best practice recommendation, I encourage customers to add the domains to their tenants that they want to ensure are protected from being registered in other tenants. This was more of a relevant recommendation prior to October 2021 when domains would be added to unmanaged tenants but doing so even after ensures that domain ownership has been validated and is locked to the tenant where the domain resides. This may or may not be possible depending on the number of domains that a customer owns as there is an upward limit of 5000 domains.