RFC1912 says: Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS. (PTR is an exception if you want to implement classless in-addr delegation.) For example, this is strongly discouraged: podunk.xx. IN MX mailhost mailhost IN CNAME mary mary IN A 18.104.22.168 [RFC1034] in section 3.6.2 says this should not be done, and [RFC974] explicitly states that MX records shall not point to an alias defined by a CNAME. This results in unnecessary indirection in accessing the data, and DNS resolvers and servers need to work more to get the answer. If you really want to do this, you can accomplish the same thing by using a preprocessor such as m4 on your host files. I disagree with RFC1912 for the following reasons: Yes, RFC1034 says it should not be done. It does not say it must not be done. The reason it gives is that it saves DNS queries, not because software will break. In fact, it says that if it is done, software should accept it: Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. For example, the address to name RR for the above host should be: 22.214.171.124.IN-ADDR.ARPA IN PTR C.ISI.EDU rather than pointing at USC-ISIC.ARPA. Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error. The second objection RFC1912 gives is based on a misinterpretation of RFC974. RFC974 does not in fact say that MX records shall not point to an alias defined by a CNAME. It does say: RFC974: Minor Special Issues Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. Under sendmail, when a host was unaware of all its aliases, it would be unable to handle mail that was addressed to an alias and not to its canonical name. This would appear as the dreaded "local configuration error: mail loops back to me (MX problem?)". However, we do not expect mail to be addressed to any of the aliases. Therefore, in our situation, RFC974's objection is simply not a cause for concern. The phrasing of that paragraph tends to evoke an overcautious response in most people. RFC974 basically says "under circumstances ABC, if you do X, you will have problems". Most people take away from that, "never do X ever" which, though erring on the side of safety, overstates the case. RFC1912 erroneously publicizes the overbroad interpretation. (BTW, RFC974 has since been obsoleted by RFC2821, which is silent on the matter.) True, RFC1033 does say, in reference to CNAMEs, that "There must not be any other RRs associated with a nickname of the same class." But I take that to mean that RRs of the form alias IN CNAME foo alias IN MX bar alias IN A baz are prohibited; using the alias on the right side of a resource record does not constitute an "association" in the sense used throughout RFC1033. RFC2181 section 10.3 provides a more detailed argument against MX->CNAME, but I am unable to reproduce the "additional section processing" behaviour it uses as a basis for its argument. Chapter 17 of the Bat Book (1st ed.) says, without justification, "MX Must Point to an A Record", then qualifies: "Note that sendmail is possibly more forgiving than other MTAs. It also accepts an MX record that points to a CNAME record. The presumption is that the CNAME correctly points to an A record." The real problem lies with such mailers, labeled "unforgiving", who only perform an A lookup of the MX server and neglect to explore CNAME alias alternatives when the A lookup fails. Sendmail, postfix, qmail, and exim are not "more forgiving" but in fact merely do the right thing, in compliance with RFC1034: CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. If so, the name server includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. The one exception to this rule is that queries which match the CNAME type are not restarted. For the above reasons, I am convinced that MX records may point to CNAMEs. Objections based on local misconfiguration are specious. Allegedly widespread implementation incompatibilities are in fact far less numerous than feared. In fact, since IBM corrected its SMTP module in 1995 I have not seen any any mail delivery software fail due to MX->CNAME. Therefore, even though MX->CNAME links are enshrined as errors by dns-checking software, these warnings can be safely ignored.