DOCUMENT:Q153001  09-MAR-2001  [exchange]
TITLE   :XFOR: DNS MX Records and CNAMEs
PRODUCT :Microsoft Exchange
PROD/VER::4.0,5.0,5.5
OPER/SYS:
KEYWORDS:kbusage exc4 exc5 exc55

======================================================================
-------------------------------------------------------------------------------
The information in this article applies to:

 - Microsoft Exchange Server, versions 4.0, 5.0, 5.5 
 - Microsoft Exchange 2000 Server 
-------------------------------------------------------------------------------

SUMMARY
=======

Though Domain Name System (DNS) entries for Mail Exchanger (MX) records can be
pointed to canonicalized (CNAME) host records, doing so is not advised, and is
not a Microsoft recommended best practice. Increased administrative overhead and
the possibility of misrouted messages can result.

Microsoft recommends Mail/DNS administrators to always link MX records to fully
qualified principal names or domain literals.

MORE INFORMATION
================

DNS is used to identify computers on the Internet. The Internet Mail Connector
(IMC) uses DNS to resolve Internet Protocol (IP) addresses when sending mail. A
sending Simple Mail Transfer Protocol (SMTP) server also uses DNS to determine
which host on the destination network is appropriate to receive mail. To
determine mail hosts, the sending server checks for an MX record. Next, the
sending server resolves the MX record to an IP address by checking for an
address record (A record). If an A record is found, the address is fully
canonicalized and mail can be delivered.

However, if an alias record (CNAME) is used for the hostname listed in the MX
record, the sending host might re-write the envelope and redirect the RCPT
command to the alias hostname and not the original recipient. This might cause
the destination SMTP host to reject the message.

Example:

company.com.      MX 10       mail.company.com.
mail.company.com.    IN CNAME    server.company.com.

When you address mail to "admin@company.com" with the above configuration, the
sending host might detect the fact that the "mail.company.com" is an alias and
rewrite the RCPT-TO command to "server.company.com". Thus, the mail envelope
written during SMTP mail transmission might be changed to
"admin@server.company.com". If the mail system isn't configured to accept mail
for "server.company.com" 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.

Desired Configuration:

company.com.      MX 10       mail.company.com.
mail.company.com.    IN A     127.127.127.127

In the above example, the MX record resolves directly to an IP address. This
causes the sending host to realize that the resolved address is canonical and
the final destination. Alias records (CNAME) aren't needed because the
connection can be redirected to the desired CNAME's IP address directly instead
of using an alias record.

RFC 1123 explicitly states that SMTP mail should be addressed to canonical name
hosts. To be canonical, the DNS entry must be an A record or an MX record. CNAME
records are not canonical and should not be mixed with MX records.

Note that most SMTP servers do not rewrite the message envelope when resolving
through aliases. Usually this configuration issue can be detected if there are
complaints that a user receives the majority of their SMTP mail but mail from a
particular host is rejected even though the addressing is the same.

Additional query words: smtp

======================================================================
Keywords          : kbusage exc4 exc5 exc55 
Technology        : kbExchangeSearch kbExchange500 kbExchange550 kbExchange400 kbZNotKeyword2 kbExchange2000Search kbExchange2000Serv
Version           : :4.0,5.0,5.5
Issue type        : kbhowto

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.  MICROSOFT DISCLAIMS
ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  IN NO
EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR
ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF
MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.  SOME STATES DO NOT ALLOW THE EXCLUSION
OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES
SO THE FOREGOING LIMITATION MAY NOT APPLY.

Copyright Microsoft Corporation 2001.