DNS/毒盛/CNAME/MX+CNAMEについて、ここに記述してください。

https://news.ycombinator.com/item?id=7293512

The problem doesn't have much to do with particular mail servers, but rather with the order in which queries may be made. Let's say the following two records are allowed to co-exist:
{{{
    example.com 60 IN MX mail.example.com
    example.com 60 IN CNAME foo.example.org
}}}
and that the MX record takes precedence over the CNAME when queried.
 Imagine a client, C, behind resolver R, and it makes the following queries;
{{{
    1. C looks up qname=example.com qtype=MX, R returns the MX record
    2. C Looks up qname=example.com qtype=A, R follows the CNAME
    3. C looks up qname=example.com qtype=MX, R follows the CNAME
}}}

3 のMXでCNAMEに行くかどうかは疑問だ。

-- ToshinoriMaeno <<DateTime(2017-06-19T22:40:20+0900)>>

The resolver will first resolve the MX record, and cache that correctly, passing the result back to the client. The second query though will result in a CNAME, which will likely invalidate the cached MX record, and the resolver will then follow the CNAME and chase that. The third query may now also follow the CNAME, even though there may not be an MX record at the CNAME target (foo.example.org).

Any non-MX query behind resolver R effectively poisons R's cache, and the MX becomes unreachable. If R gets no queries other than MX queries, or if the MX and CNAME target answers are cacheable for identical periods of time, then it can sometimes work - but it's a tenuous and non-deterministic stroke of luck. If there's even one lookup behind R - from any of its clients for a non-MX, things break again. Some mail servers do perform an A lookup before an MX lookup (which is valid RFC822) and so things never work for those mail servers, as they always poison the cache, but that correlation isn't really the cause of the problem. The configuration is unreliable even in the best of circumstances.