Why You Shouldn’t Mix CNAME and MX

You may recall our recent cautionary tale about DNS configuration. Adding a CNAME record to a domain can cause some mail servers to ignore the MX records. Instead, they simply follow the CNAME pointer and try to deliver the email there. In our example, they tried to deliver email to the Web server!

RFC 2821 defines how email should be delivered. Its specifications for what should happen only hint at this behavior. Sections 2.3.5, 3.6, and 5 really could be more clear on this:

A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology [22]) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set [1]. Domain names are used as names of hosts and of other entities in the domain name hierarchy. For example, a domain may refer to an alias (label of a CNAME RR) or the label of Mail eXchanger records to be used to deliver mail instead of representing a host name.
Only resolvable, fully qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or A RRs (as discussed in section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs.
Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name [22]. The names are expected to be fully qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification and, due to a history of problems, are generally discouraged. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name.

The standard assumes you're already familiar with RFC 1034, which defines how DNS records work. In section 3.6.2, it recommends not mixing CNAME records with any other type of record:

If a CNAME RR is present at a node, no other data should be present

Even that is a little ambiguous -- in the jargon of the IETF, "should" usually denotes a recommendation, as opposed to "must," which denotes a mandate. Perhaps this would have been better reworded, "If a CNAME RR is present at a node, other data must not be present."

... Richi Jennings, with thanks to Cloudmark's Dave Kelly and Oracle's John Haxby

One Comment

  1. Posted September 11, 2008 at 6:08 AM | Permalink

    These two blog posts don’t say what our friend should have done to safely achieve what he wanted.

    As you may have guessed, there’s a third blog post in the sequence, which will add this final part. Stay tuned…

  2. Bachsau
    Posted August 9, 2011 at 5:45 PM | Permalink

    I think the RFC is clear at this point. As CNAME is an overarching alias, an MTA should deliver mail to the target’s MX.

Post a comment

You must be logged in to post a comment. To comment, first join our community.