Message delivery fails due to wrong DNS resolution of mx server

[ArnoSen]

I am sending messages to support@mailtemi.com and I receive notifications that the message could not be delivered.

An example of the delivery errors are:

202 from:XXX to:support@mailtemi.com next 3m53s last 11m3s error "dialing smtp server: dial tcp 46.19.33.172:0->52.58.254.253:25: i/o timeout" 203 from:XXX to:support@mailtemi.com next 5m6s last 2m25s error "dialing smtp server: dial tcp 46.19.33.172:0->18.192.94.96:25: i/o timeout"

When I do a lookup of mx servers for this domain through [mxtoolbox](https://mxtoolbox.com/SuperTool.aspx?action=mx%3amailtemi.com&run=toolpage , it says the mailservers resolve to 103.168.172.216 and 64.147.123.51.

[mjl-]

Those wrong IPs have reverse DSN pointing to aws ec2 machines, so that's strange indeed.

Could you try commands like the ones below on the machine that runs mox? Dig uses the system resolver (the same one mox uses). And the mox commands use the DNS handling logic mox also uses for delivering.

Also, could it be you have "routes" configured for outgoing messages? So they are delivered through an external submission/smtp server?

$ dig mailtemi.com mx
[...]
mailtemi.com.           14400   IN      MX      20 in2-smtp.messagingengine.com.
mailtemi.com.           14400   IN      MX      10 in1-smtp.messagingengine.com.

$ dig in1-smtp.messagingengine.com a
[...]
in1-smtp.messagingengine.com. 3600 IN   A       103.168.172.217
in1-smtp.messagingengine.com. 3600 IN   A       103.168.172.219
in1-smtp.messagingengine.com. 3600 IN   A       103.168.172.221
in1-smtp.messagingengine.com. 3600 IN   A       103.168.172.220
in1-smtp.messagingengine.com. 3600 IN   A       103.168.172.216
in1-smtp.messagingengine.com. 3600 IN   A       103.168.172.218

$ dig in2-smtp.messagingengine.com a
[...]
in2-smtp.messagingengine.com. 3600 IN   A       64.147.123.51
in2-smtp.messagingengine.com. 3600 IN   A       64.147.123.52

$ mox dns lookup mx mailtemi.com
mx records (2, without dnssec):
- in1-smtp.messagingengine.com., preference 10
- in2-smtp.messagingengine.com., preference 20

$ mox dns lookup a in1-smtp.messagingengine.com
records (6, without dnssec):
- 103.168.172.219
- 103.168.172.221
- 103.168.172.220
- 103.168.172.216
- 103.168.172.218
- 103.168.172.217

$ mox dns lookup a in2-smtp.messagingengine.com
records (2, without dnssec):
- 64.147.123.51
- 64.147.123.52

[mjl-]

After some more offline discussion. The issue seems to be that the recipient domain has a cname record at its root. Mox follows it and tries to deliver to the domain followed. Have to dig into this. I was under the impression that cname records aren't allowed (or at least cause trouble) when used at the root of a zone. And at least my instance of bind doesn't allow anything "below" a cname.

[mjl-]

The code that decides which servers to dial for a delivery is at https://github.com/mjl-/mox/blob/v0.0.9/smtpclient/gather.go#L30

We carefully follow CNAMEs first, to get the DNSSEC-status from the resolver for each name followed. This is required to do DANE properly (given the constraints of the Go DNS resolver). By doing so, we'll never lookup the MX records before looking up the CNAME records. Once the DNS resolver I use (unbound) sees a CNAME for a domain, it won't even look up MX records anymore. That also makes it clear that having CNAME records while at the same time having MX records for the same name simply won't work (reliably) in practice. Since I don't see a way to do correct delivery with DANE with the Go DNS resolver for this case, I don't see a way to work around this situation. If anyone knows a workaround that keeps DANE working properly, we can use it.

ArnoSen found https://www.isc.org/blogs/cname-at-the-apex-of-a-zone/ which has more info. See the warning at the bottom.