Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2453
  • Last Modified:

CNAME in MX record (Urgent)

I failed to send mail to "", after i do the mail test in the, it shows the below content. I dont understand whta is means.  Any one can kinldy explain it to me and any advise? Many thanks. I am new to MX and DNS.

Getting MX record for (from local DNS server, may be cached)... Got it!

Host Preference IP(s) [Country] 10 [US] --------------------------------------------------------------------------------

Step 1:  Try connecting to the following mailserver:
         [ERROR: A CNAME appeared in the MX records; this is not valid (per RFCs 974 "Minor Special Issues" section, and 1034 section 3.6.2.
          Mailservers are not required to send E-mail to]
CNAME(s) I found are: [ CNAME] -

Step 2:  If still unsuccessful, queue the E-mail for later delivery.

Note: if you enter an entire E-mail address (such as, we will try to connect
to each mailserver to ensure that they are live and accept mail to the domain.NOTE: This tool does NOT attempt to determine if an E-mail address exists!
  • 3
  • 2
  • 2
  • +2
5 Solutions
Using nslookup(command line tool on most OS's, Mac OS X(10.4.10) in this case) to query DNS records:

First I set the type of record I am querying for, in this case an MX record.  An MX record is a Mail eXchanger record, these are pretty much the core of how email is routed all over the internet.
> set type=mx
Then I put in the address I would like an MX record for

Non-authoritative answer:       mail exchanger = 10

Authoritative answers can be found from:       nameserver =       nameserver =      internet address =    internet address =

This tells me that the MX record has a weight of 10 and an address of  Nothing special here, just a server name

Now I set the type back to 'a' which is the default type.  An 'A' Record is just a standard name record.  Generally an A record will point to an IP address.
> set type=a

Non-authoritative answer:        canonical name =

So the record for isn't actually an A record, but a CNAME record which means it points to another A Record, to be exact.  Basically, your MX record should just point directly to  MS has a decent article on it:

From that article:      MX 10    IN CNAME

When you address mail to "" with the above configuration, the sending host might detect the fact that the "" is an alias and rewrite the RCPT-TO command to "". Thus, the mail envelope written during SMTP mail transmission might be changed to "". If the mail system isn't configured to accept mail for "" the message may be returned as undeliverable. This issue can be difficult to detect since the body of the message with the TO: line is left unchanged.
You cannot have a CNAME in your MX record.  

It should look like this in your DNS hosts file for

 IN MX 10


 mymailserver  IN  A   ; = your numeric ip address

avoid defining mymailserver as a CNAME of another host.
yekoAuthor Commented:
Thanks for the advise.
when i use web mail, such as gmail, to sent a test mail to, the receiver can receive the mail.
My environment is using sendmail and bind as the smtp server and dns server. How can i do for make
it work as the gmail? Many thanks.
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

The above comments are all correct, but let me give you some perspective on what's going on here.

DNS is obvioulsy useful, or we would be using IP addresses in web sites and e-mail.  Can you imagine having to reach this question as

...or sending messages to george.w.bush@ instead of

So the basic DNS record is to translate a name to a number.

Mail needs special handling.  Why? A few reasons. First, it was very common to have the following servers:
file transfer -- ftp.****.com
web -- www.****.com
mail -- ****.com
Notice how most web servers started with www, ftp servers started with ftp, but mail addresses are not usually @smtp.****.com or @mail.****.com? People wanted the mail addresses simpler, so they typically wanted only one dot, not two (i.e., two parts in the name not three). But you don't want to "reserve" the whole top-level name just for the mail server!

Also, mail is typically the busiest server in a domain, because it processes all those individual mail messages. Web servers and ftp servers usually have less connections. Also, if a web server is down, people would generally try again later. If a mail server was down, a backlog was created. So technicians wanted to be able to specify multiple mail srevers for a domain, with different priorities (main, backup). So a special type of address was set up in DNS that satisfied these two needs, the MX record (for Mail eXchanger).

What the MX record does is that it sits outside the usual name/address set of records. I can have point to, yet put mail servers at and, even though the mail server also services This allows me to separate the functions of into mail-handling and "everything-else-handling" addresses. Also, with MX, I can add a priority (called an MX preference level).

OK, so now I can have my regular at (called an A record)
And my mail servers at priority 10 / priority 20

But the MX designers added one more trick. Since my mail server is also a regular computer, with unique names for the two different priority servers, I might have an A record associated with each one anyway. Why not allow the MX to point to the NAME instead of the NUMBER?  Otherwise, if I change the address of my server, I have to change it in two places -- the A record *and* the MX record. If I allow the MX to point to a name instead of an IP address, then I only have to change the A record if my mail server address changes. The MX stays the same, but everything still works, since MX -> A, and A -> new IP address anyway.

So, what's a CNAME? Well, it is sort of like an MX record for non-mail purposes. Let's say I have a web site. Same type of setup -- multiple servers, each with their own name, but also pointing to each of them. If I change IP addresses, I have to update their regualr names (say, and, but I also have to update both of the to point to the same two new addresses. With mail servers that was no problem, because the MX record pointed to the A, and I only had to change one A for each server. But here, I have to change each one twice.  Enter the CNAME. I only use A for the unique server names, one A per server. the CNAME,, points to the two A records. If the A record changes, the CNAME that matches up to the A names, automatically reflects the change.

So, an "A" type name always resolves to an IP address

And, an "MX" type name normally resolves to one or more A names (with priorities), and a second DNS check is done to get the final address form an A name

Finally, a CNAME always resolves to one or more A names, and a second DNS check is done to get the final address from an A name.

Notice how CNAMEs do almost the same thing as A names? Then why would you have an MX point to a CNAME instead of an A name? It would require a third DNS check, without providing that much benefit.  Truth is, I can see some good reasons for having MX point to CNAME, but it wouldn't be a major difference, and the speciifcations were never set up to allow it, so we just don't do it.  Once in a while, someone sets up an A name, and later changes it to a CNAME to avoid future update problems, and forgets that there was an MX pointing to the old A, ergo, the MX which still points to the same name, is now pointing to a CNAME instead of an A name, and is technically out of compliance.  That may be what happened to you!

To fix it, your MX should point to instead of Now I realize that means if your ISP,, ever changes the IP address of their SMTP relay that you rely on, you will have to update it at the same time that they update it. That's why I think the MX specification SHOULD allow CNAMEs. But it doesn't, so you should fix it.
Hmm, just realized, you are trying to SEND to They are the ones out of compliance.

Even so, if you are using a SendMail server, I believe you can configure it to allow CNAME lookups... I think it even does this by default (it just tries to open a socket to one of the MX targets, and that will work whether the target is an IP, or a name that reislves via either A or CNAME. So there may be a more complicated problem going on there.

Check your SendMail logs to see where it tried sending the message.
I think we need more information on your issue.

Where are you trying to send e-mail from that you are having a problem?  What other error messages are you getting besides the DNSstuff report?  I assume you don't control the domain  You are running a different server trying to send mail to that host, which you don't control?
So you don't control, you are just trying to get bind to disregard the DNS problems?

I believe you are looking for the following config option in Sendmail, adding define(`confDONT_EXPAND_CNAMES', `True') to your sendmail config.  Are familiar with sendmail config files?

confDONT_EXPAND_CNAMES      DontExpandCnames
                              [False] If set, $[ ... $] lookups that
                              do DNS based lookups do not expand
                              CNAME records.  This currently violates
                              the published standards, but the IETF
                              seems to be moving toward legalizing
                              this.  For example, if "FTP.Foo.ORG"
                              is a CNAME for "Cruft.Foo.ORG", then
                              with this option set a lookup of
                              "FTP" will return "FTP.Foo.ORG"; if
                              clear it returns "Cruft.FOO.ORG".  N.B.
                              you may not see any effect until your
                              downstream neighbors stop doing CNAME
                              lookups as well.
From RFC 2821 @

CNAME is clearly allowed, but it is unclear whether the CNAME can only vector INTO the MX, or whether the MX can also vector to a CNAME.

. Address Resolution and Mail Handling

   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.  If
   no MX records are found, but an A RR is found, the A RR is treated as
   if it was associated with an implicit MX RR, with a preference of 0,
   pointing to that host.  If one or more MX RRs are found for a given
   name, SMTP systems MUST NOT utilize any A RRs associated with that
   name unless they are located using the MX RRs; the "implicit MX" rule
   above applies only if there are no MX records present.  If MX records
   are present, but none of them are usable, this situation MUST be
   reported as an error.

   When the lookup succeeds, the mapping can result in a list of
   alternative delivery addresses rather than a single address, because
   of multiple MX records, multihoming, or both.  To provide reliable
   mail transmission, the SMTP client MUST be able to try (and retry)
   each of the relevant addresses in this list in order, until a
   delivery attempt succeeds.  However, there MAY also be a configurable
   limit on the number of alternate addresses that can be tried.  In any
   case, the SMTP client SHOULD try at least two addresses.

Klensin                     Standards Track                    [Page 60]

RFC 2821             Simple Mail Transfer Protocol            April 2001

   Two types of information is used to rank the host addresses: multiple
   MX records, and multihomed hosts.

   Multiple MX records contain a preference indication that MUST be used
   in sorting (see below).  Lower numbers are more preferred than higher
   ones.  If there are multiple destinations with the same preference
   and there is no clear reason to favor one (e.g., by recognition of an
   easily-reached address), then the sender-SMTP MUST randomize them to
   spread the load across multiple mail exchangers for a specific

   The destination host (perhaps taken from the preferred MX record) may
   be multihomed, in which case the domain name resolver will return a
   list of alternative IP addresses.  It is the responsibility of the
   domain name resolver interface to have ordered this list by
   decreasing preference if necessary, and SMTP MUST try them in the
   order presented.

MX record should point to IN A record
CNAME or IP literal will fail.

That works this way because SMTP was on internet before CNAME

Maabu answered question,
If recipients are important then while explaining problem to them you can manually add smarthost for their domain to their IP.

I have two such entries for ~1500 users in my domain.
If you have both CNAME and MX it leads to dual interpretation.
Firsthand mailer should look up MX record then A record.
But DNS resolver in case of CNAME should direct all further requests to CNAME destination.

As a result your mailer may get MX and A from CNAME destination without ability to distinguish.

Only use for CNAME is when WWW server uses virtual hosting somewhere else like CNAME
nobody will send mail to and nobody will run into unclear interpreation of DNS content
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
  • 2
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now