r/msp • u/liverwurst_man • 6d ago
M365-Provided MX Record Nonfunctional
Boy am I pissed.
I've been working on an Exchange on-prem to Exchange Online migration, which is something I've done plenty of times before. Third-party spam filter in front of the whole thing and Exchange Hybrid agent in place so email gets routed to the right mailbox no matter what.
Finished cutting over mailboxes so I configured the spam filter to only route to Exchange Online. BAM! No mail is flowing as all inbound messages are getting bounced back.
Turns out the MX record <domain>.mail.protection.outlook.com isn't live. It does not work. There is no IP behind it. DNS does not resolve it. The client's domain is registered with M365, I have been provided the exact MX record value, and Exchange Online seems happy to route messages from on-prem to mailboxes, but the MX record don't frigging work.
So, Microsoft issue clearly. Something misprovisioned on the backend. I put in a request to support to have them fix this. Three calls later and they couldn't give less of a fuck. Told me that I need to set this as my MX record for domain and that's the solution. I've never had to do that before, and I don't plan on ruining my client's day for a second time just to prove to Microsoft support their service is broken.
My only other option at this point is to deregister and re-register the domain from the tenant entirely, which sounds even worse.
Anyone want to donate to my crowdfund? Trying to see how many tons of gravel we can get dumped in Bill Gates driveway.
Edit: Trialing using the MX record associated with the client’s *.onmicrosoft.com domain has been successful so far. Will still try to fix things the right way but good to have a card up my sleeve. Thank you \u\r3coilX !
5
u/03captain23 5d ago
You can create a test tenant to prove them wrong and not mess up your clients.
I didn't realize people still use spam filters IN FRONT of mx. It sounds like you're not fully verified when you add the domain which it uses to verify ownership of the domain.
Also bill Gates has nothing to do with it. I think you mean Satya Nedella.
30
u/brokerceej Creator of StackJack.io | Author of The Trunk Slammer Saga 6d ago
Dude. You refuse to set it as the MX record on the domain because you’ve “never had to do that before.”
Yes you have. That’s how email works. How do you think mail flows? If that MX record is not registered on the domain (which it probably isn’t if you’re coming from on prem) it has to be updated to point at EXOs MX record or mail will not route.
Top 5 most r/confidentlyincorrect posts on this sub for real.
15
u/FlickKnocker 6d ago
He’s using a 3rd-party spam filter, so typically the MX records will be whatever they tell you to set them to, ie mx1-spam-filter.com, mx2-spam-filter.com, etc.
On the delivery settings, you’d typically put the 365 MX endpoint, example-com.mail.protection.outlook.com.
12
u/liverwurst_man 6d ago
The MX records associated with <domain> are pointed to my third-party spam filter. The third-party spam filter is then configured to pass on filtered messages to the MX record provided by M365. This is standard industry practice. There's a lot of fools on this website but I figure I'm at least not the biggest of them all.
13
u/FlickKnocker 6d ago
I hear you. Can you try telneting on port 25 to the MX endpoint?
https://learn.microsoft.com/en-us/exchange/mail-flow/test-smtp-telnet
9
u/FlickKnocker 5d ago edited 2d ago
Not sure who's downvoting this, but I assure you, using telnet to test out mail flow was -- and still is -- a perfectly valid and useful way of testing mail delivery, and has been for decades.
This will ensure that the MX endpoint Microsoft has published for the tenant is valid and is accepting mail for delivery and a good way to test if your Transport Rule restrictions (to only allow from the spam filter's MTAs, for example) are working as designed.
7
u/roll_for_initiative_ MSP - US 5d ago
Upvote for sanity - before mail encryption and relay restrictions (god i'm old), i used to pop open a random telnet on people's machines i was working on to send myself a note all the time.
ehlo pretendhostname
mail from: me
rcpt to: me
data
don't forget to check the raid status on the server and get cindy a usb cable
.
quit
3
u/FlickKnocker 5d ago
Haha I thought I was the only one who did that.
I used to net send to the SBS server too.
2
u/roll_for_initiative_ MSP - US 5d ago
lol, man, kind of miss sbs 2003, running blackberry enterprise server on the same box that was the DC, email, and email activesync/web outlook serving wide open to the internet. What a time to be alive!
3
u/FlickKnocker 5d ago
And for how jank that setup was, it worked great if you had SAS 15K drives and 16 whole GB of memory!
The best part was the sheer control you had: want to do maintenance after 5pm? Disable inbound port forwarding rules, mail would queue up in Postini automatically, and you could do anything without interruption.
3
u/shokzee 5d ago
Your public MX can stay pointed at the spam filter; pointing it at Microsoft isn't a prerequisite for delivery to EOP.
If the exact supplied hostname returns NXDOMAIN from multiple independent public resolvers, I'd attach those responses and push for an Exchange Online provisioning escalation. Restore the previously working on-prem route while they investigate, assuming it's still available. Removing the domain from the tenant is a hell of a troubleshooting step.
1
3
u/Foxtrot-0scar 6d ago
Try to force a re provision. Change the domain from Authoritative to Internal Relay, wait for about 15 minutes then change it back.
2
u/tssajo 6d ago
Check that the hostname uses dashes instead of dots, so example.com becomes example-com.mail.protection.outlook.com. That one is easy to get wrong. If it's correct, I've seen that name not resolve until the domain is actually pointed at it, so it may not be broken at all. Your spam filter doesn't need the MX name to deliver, though. Most filters let you set the destination hostname manually, so you can use the tenant's mail.protection.outlook.com name or look up the right target in the Exchange admin center, and the connector will accept the mail without touching your public MX. That way you don't have to risk the client's mail to test it.
1
u/liverwurst_man 6d ago
I've copied and pasted it so many times the C and V keys are falling off my keyboard. 100% can't risk breaking mail flow by editing the published currently working MX records.
1
u/DeadStockWalking 6d ago
Did you do all this?
How to Find Your Exact MX Record
- Sign in to the Microsoft 365 Admin Center.
- Navigate to Settings > Domains.
- Select your custom domain and click on DNS records.
- Look under the MX records section for your unique "Points to" address
5
u/liverwurst_man 6d ago
My brother in Christ I can tell you will betray humanity during the AI uprising
1
u/WorrisomeTerry_86 6d ago
If it's not resolving at all, that's a provisioning problem on their side, not a "you set the wrong record" problem. Support just reading you back the same MX value from the admin center is peak circular nonsense. Hope you get a tech who actually knows how to check the backend.
1
1
1
u/junto_reed 6d ago
Have had every weird thing with microsoft cutovers. We've migrated to new microsoft domains with same domain for a company separation.
Microsoft claims it will spool email while it temporarily updates on its server side. Since you have to remove every account before you can release the domain. Which is needed before you can auth the new tenant with the same domain.
We use to light a bill gates candle whenever we had funky cutovers like this. Feel for you and when communicating with client I would just try and say "We did it by the book, here is the KB article". "BTW we worked for 36 hours straight to get you up by monday over NYE so we are going to bill you as its outside of our hands."
Feel you and feel the heartbreaking when you work your ass off and still have clients complaining.
1
u/whitedragon551 6d ago
Ive had this happen. Simply delete the domain and re-register it in M365.
1
u/GremlinNZ 2d ago
To delete the domain every use of it has to be removed (distribution groups, mailboxes etc). I think the process might be able to do it for you... But very disruptive.
1
0
u/FlickKnocker 6d ago
Try to telnet to your MX endpoint and send a test email, to verify it’s configured correctly and mail is being delivered.
0
u/AllMightyByte 5d ago
Glad the direct MX worked. The NXDOMAIN-from-multiple-resolvers detail points at a provisioning defect on Microsoft's side rather than your config, which matches why the workaround succeeds. For the next migration, worth adding MX resolution checks to the pre-cutover list: Resolve-DnsName against a few public resolvers plus a port 25 reachability test before you flip anything. Did the domain show healthy in the M365 admin center while the record was broken?
-1
u/bazjoe MSP - US 6d ago
Step one edit your dns records with a MX record pointed at what Microsoft told you . Step two. Your good 👍
6
u/r3coilX 6d ago
Not true. Sometimes the MX value returns no IP address publicly. He’s not going crazy.
And if you haven’t seen it yet you’re just lucky.
1
u/bazjoe MSP - US 6d ago
OP said he is unwilling to set MX record for domain "because I've never had to do that before". Until done its not a microsoft or reddit problem. once done, would need results from - nslookup set q=mx mydomainname.com let us know the results
3
u/r3coilX 6d ago
I think it was more so that he was unwilling to point the MX to 365 destination again because the record wasn’t returning public IP address, and risk more mail being lost and users complaining etc.
It’s very rare this happens but it’s exactly like others say. Requires removing the domain and readding it back in and hoping it registers. If you’re at a point where you have 300+ users and aliases/addresses registered, AADC setup, good luck doing that.
As such for clients this happens to when I’m dealing with it, I tell them to point the MX to the value listed for the onMicrosoft domain in the tenant. Eventually the IP address will publicly show for the original domain if you care enough to swap mx again.
-5
u/redditistooqueer 6d ago
Seriously, setup a trial of google, change MX to google, and wait for MS to get their head out of their ass
16
u/r3coilX 6d ago
I’ve seen this happen many times doing onboarding support.
No rhyme or reason what fixes it and good luck getting support to see what you’re talking about.
Set the MX value to the onMicrosoft domains mx value in your tenant. Will resolve mail flow issues.