It is possible to add a Domain Based Message Authentication Reporting and Conformance (DMARC) record for your onmicrosoft.com domain in M365. Is that a good thing?
Well, your viewpoint may depend on your experiences with this domain. If you actually use the onmicrosoft.com domain to send email, then yes! Adding the DMARC record enables the DMARC alignment check to pass and the mail to be successfully delivered as more and more organisations expect Sender Authentication to be in place.
However, there has been abuse of tenants which are used solely to send out spam and phishing messages. If that sender does not have a valid DMARC record, we can weed those examples out due to the failing DMARC. Most customers will not use their onmicrosoft.com address and will want to use a custom domain that is added and verified in their tenant in the vast majority of use cases, though there are some exceptions. A custom domain is the brand and identity that the organisation wishes to be known as or their visible online presence. We also want to block direct delivery to the onmicrosoft.com domain, especially when the MX records is set to a 3rd party system and does not point to Exchange Online Protection (EOP). In these cases it is common that the 3rd party solution is where the expected security controls are deployed and managed. We do not want them to be bypassed.
To help with the process of adding the onmicrosoft.com DMARC record there is a brief process here: Activate DMARC for MOERA Domain. MOERA stands for Microsoft Online Email Routing Address.
In older docs you may have seen MORD – Microsoft Online Routing Domain.
Note that this feature is scope to the creation of the DNS record. You still require a separate solution to actually perform the DMARC analysis and reporting.
Starting Position – No DMARC Record for OnMicrosoft.com Domain
As noted in the post How To Use NSLookup to Check DMARC Record we can check for the presence of a DMARC record without having to use any 3rd party tools or websites. While the mail hygine websites are great, it is still good to understand the subdomain format. You can see the format in the example queries below. The various DMARC test websites typically abstract that so you do not see it.
As a starting example, here is a valid DMARC record for a custom domain – wingtiptoys.ca.
We will query for:
_dmarc.wingtiptoys.ca
You can see that the record is returned.
What about the <tenantname>.onmicrosoft.com
_dmarc.wingtiptoyscanada.onmicrosoft.com
To add the necessary record, it is pretty straightforward.
Adding DMARC Record for OnMicrosoft.com Domain
In the main M365 admin portal (https://admin.microsoft.com) expand the left hand menu bar, then drill into Settings –> Domains.
You can see the status of the domains here.
Since we want to add the DMARC record to WingtiptoysCanada.onmicrosoft.com click to select that domain.
The navigate to the “DNS Records” tab. Here we can click the “+Add Record” button to add the DMARC record.
At the time of writing only text (TXT) records can be added.
Since the DMARC record exists in a subdomain it is entered in the format as shown below. Do NOT forget to add the underscore at the start of the record.
Click Save and wait a few minutes for the zone file to be updated.
Once that has been done, we can test.
Testing OnMicrosoft.com DMARC Record
Now that the record has been updated, we can run the same query as before.
_dmarc.wingtiptoyscanada.onmicrosoft.com
Note in the screenshot, the previous failure and then success is shown.
Why Is This Even A Thing?
Great that we can add this record, but this may also raise the question or why do we even have this onmicrosoft.com domain?
There is a bit of blurb in the document referenced below:
Domains Frequently Asked Questions | Microsoft Learn
Interestingly this article spins it in a very different way – it is a fallback domain.
There is also what we used to call the Service subdomain in Exchange hybrid. In Exchange 2010 SP1 days the recommended domain would be service.<vanitydomain>.com with an example being:
service.wingtiptoys.ca - note that this is a domain that the tenant admin had to carve out and manage. That was one of the reasons that the Exchange 2010 SP1 hybrid process was so long and painful. With Exchange 2010 SP2, the Exchange Hybrid Configuration Wizard (HCW) was added and the mail.tenantname.onmicrosoft.com domain was used in place of the traditional service domain. Since mail.tenantname.onmicrosoft.com is managed by Microsoft, we can automate the addition of records to the domain and the Exchange hybrid process was so much easier!
In semi related trivia, customers always seemed to use the exact same name for the service domain that was added to the documentation – “service”. This really should not have been a surprise as the same folks did exactly the same thing with the Exchange 2010 legacy name for the down level version of OWA. You could call that name anything, but there were so many times it was the word “legacy”.
Cheers,
Rhoderick
