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       1.2.3.4

   [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:

	52.0.0.10.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.