The servicedesk got complaints that email was not delivered to an organization, and that an NDR was never generated. The sending user never knew this, until the sender and receiver talked on the phone. Our organization was Exchange 2016 on-premises with a Cisco IronPort as a gateway to the Internet. The other (receiving) organization was in Exchange Online.

The receiving organization was in Exchange Online, and had already enabled DANE for inbound email messages (see my previous blog post on this). I checked multiple organizations in Exchange Online that have DANE enabled (including hotmail.nl) and they all failed.

One organization has a Fortra Clearswift in front of their environment that has DANE enabled, and we were able to send email to this particular domain.

And to make it more complex, other organizations with an IronPort gateway were able to successfully send email messages to these domains.

At this point still no clue whether it is a Microsoft issue, or an IronPort issue or something specific to our organization.

When checking the DANE SMTP service for the domains involved everything looks fine as shown in the following screenshot:

When checking the IronPort logs, the following cryptic and non-explaining error was logged:

MID 1614647 (DCID 600113) DANE failed for Hotmail.nl. Reason: 4.0 - Other network problem.

Also shown in the following screenshot:

The same error was logged for the other DANE enabled domains as well.

So, DANE fails on the IronPort, but the tools to check DANE all reported DANE was good. Also, I was able to send mail to these domains using Gmail. I always say when it works in Gmail, everything is ok.

When checking the DANE configuration on the command prompt on the IronPort it looks more like a DNS issue as shown in the following screenshot:

But when checking the DNS record (_25._tcp.exchangelabs-nl.y-v1.mx.microsoft)
with MXToolbox, everything is green again as shown in the following screenshot:

After checking with the network department it turned out that there was an IPS solution implemented and the network engineer knew about an old CVE, dating back to 2013 (CVE-2013-4466) that warns for a situation where a buffer flow can occur in the dane_query_tlsa function when more that four DANE entries are returned.

The CVE is 11 years old, but the IPS still had this implemented, and when more than four entries were returned, everything was discarded and the email was lost. Removing this from the IPS and everything works fine.

Note. The RFC for DANE does not mention the amount of entries that can be returned, so more than four should not be a problem.