Our new ISP asked us to transfer our domain name. Now we have problems with Internet email. Our old ISP says our problem stems from our mail exchanger (MX) record setup, but it can’t help us because it no longer controls our domain name. Suggestions?

A. Yours is a common situation that touches on an important subject. Many Web-hosting providers intentionally or unintentionally mislead customers into believing that they must move their DNS hosting to move their Web sites. In fact, moving a Web site requires only that you alter the address (A) or Canonical Name (CNAME) record in the DNS domain zone file that points to the Web server so that the file points to the IP address the new provider assigns to the Web site. Enduring the pain and aggravation of relocating your DNS domain to a new ISP is unnecessary. And such DNS-hosting transfers can result in problems with other services, including email.

The typical setup for an inhouse mail server is to list the DNS name or IP address of the company's mail server as the highest-preference mail server—represented by the DNS MX record with the lowest preference value. For fault tolerance and availability reasons, you also need to use DNS MX records to list alternate mail servers for the domain; preferably, at least one of these servers will be offsite (in case, for example, the WAN link is down when a mail delivery is attempted). For example, my ISP, Sonic.net, acts as a backup for my Internet mail services by letting me include it as a secondary preference DNS MX record for my domain.

If a mail server on the Internet needs to send mail to a user on my domain, the server first attempts to deliver to the highest-preference mail server (i.e., my internal server). If that server is unreachable, the sending server then goes down the line to the next-highest-preference DNS MX record host and so on until it delivers the message or exhausts the list of available mail servers (in which case the message bounces back to the sender). If the server successfully delivers the mail to one of the listed backup mail servers, SMTP delivery mechanisms cause that server to hold the waiting mail and deliver it to my inhouse mail server when the original server comes back online.

In a perfect world, a new ISP or DNS-hosting provider would examine the contents of a customer's current DNS zone file and duplicate those contents as closely as possible on its systems. In the case of email, the new ISP must restructure the DNS MX record configuration (i.e., the records that determine which hosts handle the domain's mail) in the zone file so that the configuration duplicates the existing zone's functionality. But this world isn't perfect, and ISPs can make mistakes that cause problems with certain services or DNS names.

Several things can go wrong when a company transfers a DNS domain name to a new ISP. That ISP might change the MX configuration in such a way that one or more of the listed MX records is invalid or that no MX record points to a configured backup mail server. As a result, email might not be delivered properly.

The new ISP controls your DNS zone file, so you need to work with the ISP to correct the MX records and to point those records to the right servers. If possible, make sure that at least one lower preference (i.e., higher preference number) MX record points to a server (at the ISP) that can provide backup mail services for your domain. This setup will prevent bounces if your primary inhouse mail server is unavailable. After you resolve your email problems, I strongly recommend that you document your working DNS domain zone file configurations so that you'll have these records if you transfer your domain name again or if your ISP accidentally damages or deletes your zone files.