I ran into an email delivery issue the other day that seems likely to come up here and there. My customer could receive email inbound from a domain of a vendor they do business with, but suddenly could no longer send messages to them outbound.
All I had to go on was the following NDR (modified to protect the innocent):
My customer uses Exchange Online (Office 365) with Barracuda Essentials for email security and archiving. I’ll call their domain senderdomain.com
I determined from the header of an inbound message from the vendor (calling it realdomain.com) that they too have mail hosted by 365. Their MX records indicated that mail was routed directly to Microsoft with no 3rd-party anti-spam service.
Obviously I had already checked that everyone was using valid addresses and proper spelling. realdomain.com was resolving for me without a problem, so I knew the NDR’s “domain doesn’t exist” to be bogus.
Noticing that the error reported in the NDR was sourced from Barracuda (*.cudaops.com), I called into their support line and opened a case.
As expected, the issue was on their end and was resolved in about 2 minutes. The issue was that realdomain.com was a “verified domain” within the Barracuda system. Realdomain must have been a previous Barracuda customer and moved their MX records back to 365 within the last few weeks – when the outbound mail problem began.
Barracuda was internally routing those messages (senderdomain.com is using Barracuda for outbound filtering as well as inbound) which were going nowhere!
I discussed the problem with the Barracuda support tech. From what he said, Barracuda has to manually remove former customer domains from their system. They don’t do any checking on the validity of (or changes made to) MX records.
Granted, this issue will only come up if you use Barracuda for outbound filtering and you try to email a former Barracuda customer domain still registered with their service. But considering Barracuda is a big provider, this might happen with some regularity.
It can also generate some confusion, as realdomain.com’s IT vendor was misunderstanding the situation and pointing blame at my customer. Conversely, the NDR from 365 states “it’s likely that only the recipient’s email admin can fix this problem” which could cause this all too familiar situation: