21

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.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
Oliver Salzburg
  • 4,505
  • 16
  • 53
  • 80
  • 11
    It's even explicitly allowed to _not_ have an MX record, so that error message is senseless. Your service provider needs a lot of help. – Michael Hampton Apr 05 '18 at 15:40
  • 4
    Of course this has to work. Consider the case where site `example.com.` uses any third party email provider, such as G Suite, so they have an MX record of `aspmx.l.google.com.`. – user253751 Apr 05 '18 at 23:13
  • 1
    Maybe it was about the MX record being at a different (and faulty) provider (eg missing glue records, slow zone updates, something wrong with the A records, standards compliance issues like mx-as-cname)? – rackandboneman Apr 06 '18 at 11:46
  • The issue was that the provider didn't understand anything. They thought my issue was when using their service to *receive* email, where they recommend to use *only* their MX. But I was asking about *sending* emails and the MX of a receiving domain. I assure you, this was incompetence on their part. My issue description was very clear and this misunderstanding would have been impossible if they actually looked into the issue for even a second. – Oliver Salzburg Apr 10 '18 at 10:40

2 Answers2

44

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.

Community
  • 1
Jenny D
  • 27,358
  • 21
  • 74
  • 110
24

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.

Sven
  • 97,248
  • 13
  • 177
  • 225