We're using a 3rd-party service provider to send transactional email. I recently noticed increased failure rates for a given receiving domain.
The sends fail with the error "498 No MX for example.com".
The sends are retried after a given delay and then usually succeed after a couple retries. But sometimes, they exceed the retry limit and are dropped permanently.
I contacted the support of the provider and they told me that this is due to the receiving domain declaring MX from different providers.
$ dig mx example.com
;; ANSWER SECTION:
example.com. 859 IN MX 25 mail05.example.com.
example.com. 859 IN MX 20 mail11.example.net.
They are referring to the fact that one MX is using example.com
and the other is using example.net
and that is apparently bad practice and can lead to the error described above.
This is the first time I'm hearing something like that and I would instantly call BS on it, but I thought I'd give them the benefit of the doubt and hear what others have to say on the topic.
They are mostly wrong.
It is not a bad practice to have more than one MX, and it's equally not a bad practice to have one or more of them with a hostname in another domain. In fact, it used to be quite common that people would set up their own mailserver in their own domain as their primary MX, and then have their ISP's mailserver as secondary MX.
The one tiny part that might conceivably be relevant is that if the MX in the other domain doesn't resolve properly, e.g. if domain
example.net
is having DNS issues, that would be an issue. But that's why you have more than one MX - if one fails, the others will still work.You should respond to the provider and point them at RFC 5321, section 5.1. It's a bit too long to quote, but the gist of it is that if there's more than one MX, the sender must try at least the first two, and there's no restriction on having them in separate domains.
No, this is BS. Having this option is one of the main reasons why you can specify multiple MXs with different priorities in the first place.
There must be another problem.