Web Hosting Blog

You have to configure MX entries when you prepare to send SMTP mail to a remote server. MX records are the responsibility for the domain name server.

How does it Work?

When SMTP client wants to send an e-mail message to the SMTP server at something.com, it has to see what MX records exist for this domain (something.com). If there are not any, then the mail won’t be delivered.

Let’s suppose that there are MX records for YOURDOMAIN.COM, and consider a few ways they might work. First, suppose that some folks figured that there ought to be an MX entry, just for the heck of it, and that it should point to their single, main, public computer. What they would do — and do in fact do — in this case is place an appropriate entry in their DNS control files so that a single MX “record” is returned for YOURDOMAIN.COM which points to NG.YOURDOMAIN.COM, whose IP address is the same as just good ole plain YOURDOMAIN.COM. Perhaps the curious user would like to see what this looks like; it goes like:

IN      MX     10 ng.yourdomain.com.

You can ask your own DNS to find out what the MX entries for YOURDOMAIN.COM are by using the command “NETCHECK/MX YOURDOMAIN.COM”.

When your SMTP client wants to send mail to dan@yourdomain.com, it asks its domain name server for the list of MX records associated with the domain “yourdomain.com”. The DNS responds “yes, there is 1: ng.yourdomain.com”. The SMTP client then translates (via another request to the DNS) ng.yourdomain.com to an ip address and proceeds to connect to the SMTP server at that ip address.

This example underscores the basic mechanism for sending mail from SMTP clients to servers but does little to help justify the existence of MX entries. Let’s take another example: a certain mail provider may have such a mountain of incoming mail that SMTP clients around the world are often experiencing connection timeouts because the mail server is so busy. To keep up with the traffic, they add a second computer to act as a mail server, and a second record in their DNS control file. The mx entries now look like this:

IN      MX     10 ng.yourdomain.com.
IN      MX     10 bundy.yourdomain.com.

Let’s walk that SMTP client through its mail task again. It needs to send mail to dan@yourdomain.com, so it asks the DNS for the MX records associated with yourdomain.com. “Yes”, says the eager DNS, “there are two of them: ng.yourdomain.com and bundy.yourdomain.com”. The client first tries to connect to ng.yourdomain.com, but the connection times out. So, in a determined effort to deliver the mail, the client tries the next mx entry, translates bundy.yourdomain.com to an ip address, and — voila — the connection is accepted! the mail goes through! The world is saved!

Before we slam into the end of this article, let’s take one more example of how MX records can be used. The nice folks at S&H have developed a working relationshipo with the even nicer folks at nashville.com, so that if both the S&H servers are down, the mail can still be delivered to the backup system. The revised MX records now look like this:

A backup mail server can be set just in case to ensure that your mails will be sent no matter of the load of the primary(ng.yourdomain.com) and secondary mail server (bundy.yourdomain.com).

IN      MX     10 ng.yourdomain.com.
IN      MX     10 bundy.yourdomain.com.
IN      MX     5 backupserver.com
The numeric codes assign “preference weights” to the mx entries. So is it really true that the higher codes are for the more preferred entries? Don’t take my word for it, I’m making that up! Really! I don’t have the DNS and Bind book here, you will have to look that up yourself! Have a nice day.