Malformed MX records after DNS configuration for Exchange Online

As part of activating an Exchange Online tenant, a change to your Office 365 MX records has to be perfomed. Upon doing so in my lab environment, things seemed pretty alright, but after some more time, my mail-flow failed and incoming e-mails got bounced. Here is what’s happened and how I fixed it.

During the domain set-up, you’re asked to create an MX record for Exchange Online:


Who am I not to? So here’s what I did:


Because I did not nessecarily wanted to remove my original MX record, I decided to create an additional MX record for the Exchange Online platform with the cost of 0, which takes precedense over the original record, so mail gets routed to the Exchange Online platform. In addition, I’m not using autodiscover in this lab, so no autodiscover records for me. At this stage, sending a mail to my public domain address and my tenant-address worked as expected. So far so good.

After a couple of days though, mail flow to my public domain address stopped working. What happened? These mails got bounced saying there wasn’t such a recipient. This is weird for many reason, but the root cause turned out to be even weirder. Apparently there’s a scenario in which a DNS host does some processing on the DNS records of a specific type (in this case: MX) and they stop merging the named records when it finds a trailing dot (.) If you leave it out, it seems to merge the record with the next found record in the table.

Please note that not all DNS hosts experience this behavior, so check before you act!

In my case the DNS host did perform this action and the resulting MX record was skewed:


For obvious reasons I can’t show the exact domain names, but as you can see, the second MX record shows a . after and there’s my mail entry, what happens in-fact is: the high cost record is pasted after the low cost record, resulting in 1 long faulty MX record. This record is obviously wrong and doesn’t resolve to any e-mail platform.

Thanks to my collegue Jaap Wesselius, I found out that there’s a solution to this issue. It requires you to manually add a trailing dot to the … record, like so:


This is a bit unfortunate because these records need to propogate through DNS and this takes quite some time. Should you retry a nslookup at this stage, you’ll find nothing has changed, so be patient. Eventually, it will be fixed:


Now guess what? E-mails sent to both my tenant address and my public domain address arrive, again: as expected.

Various DNS hosts run different software and there’s apparently quite some intricate processing taking place. Be sure to verify what you configure.

This blog post is converted from my discontinued blog:

Leave a reply

Your email address will not be published. Required fields are marked *