DNS Crash Course, Part 2: MX Records

In this post, I'll be discussing the functionality of the MX record. "MX" stands for mail exchanger, and as you might imagine, has a big impact on how mail gets delivered. Without MX records, you'd never be able to receive email on your Gmail, Yahoo, Hotmail, accounts or your business email account. To make things easy to understand, I'll be using Gmail as an example throughout this post, however, the same basic principles apply to all email hosts.

Syntax

A typical MX record looks something like this:

The MX record is comprised of four unique parts to help direct email:

  • The root hostname (gmail.com.)
  • Record type (MX)
  • Priority (5)
  • Target hostname (gmail-smtp.in.l.google.com.)

Each bit of information that goes into the MX record holds a critical role to help mail servers send and receive email. I bet you're thinking that MX records might only affect email receipt, not sending. Read on...

How Email Servers Use MX Records

When you send an email to someone, some awesome things happen when you click "Send". Let's say you want to send an email to john@classicyuppie.com from your Gmail account. First, the Gmail server does a DNS lookup on the email address you're sending the email to. In this case, Gmail would see that the mail exchanger records for the classicyuppie.com domain are:

classicyuppie.com.    MX  10 mx01.getsecuremx.com.  
classicyuppie.com.    MX  10 mx02.getsecuremx.com.  
classicyuppie.com.    MX  10 mx03.getsecuremx.com.  

Gmail will then establish delivery to one of those three servers. It's up to the server receiving the message to match the mailbox name (john@classicyuppie.com) to an active mailbox on its end. The conversation goes a bit like this:

Gmail:       What server handles email for classicyuppie.com?  
DNS Server:  It's mx01.getsecuremx.com.  
Gmail:       Where is mx01.getsecuremx.com located?  
DNS Server:  At 208.52.186.229.  
Gmail:       Hello, 208.52.186.229, I have an email for you.  
MX01:        Ah, I see it's for john@classicyuppie.com. I'll put this in their mailbox now.  

The double DNS lookup is due to the fact that MX records point to a hostname, and not directly to an IP address. This is what's called a canonical lookup, which I'll give a more in-depth explanantion of how CNAME records work in a future post. For now, just trust me.

The Importance of Priority

The priority number I mentioned above is critcal in ensuring proper mail delivery, before the message even gets to the recipient's mail server. The priority number can help load balance, failover or spam filer incoming email loads. It may seem like a finite distinction, but it is the priority of the MX record that determines whether the records aimed toward load balancing or failover, and not the quantity of the records.

Priority and Failover

Suppose you have a single mail server processing email for an organization of 50 users. If the server were to be taken offline for routine maintenance, a power outage, or a DoS attack, any emails being sent to that server would bounce back to the sender. Most mail services like Gmail or even Hosted Exchange providers will offer multiple MX records to help with failover.

A proper failover configuration of multiple MX records in the same root domain are those that have different priority numbers. The priority number can be anything ranging from 1-50, the smaller the number the higher the priority it has. The important part is that the numbers are different. Gmail's MX records are a good example of this:

gmail.com.        MX  40 alt4.gmail-smtp-in.l.google.com.  
gmail.com.        MX  20 alt2.gmail-smtp-in.l.google.com.  
gmail.com.        MX  10 alt1.gmail-smtp-in.l.google.com.  
gmail.com.        MX  5 gmail-smtp-in.l.google.com.  
gmail.com.        MX  30 alt3.gmail-smtp-in.l.google.com.  

In this example, the primary mail server for Gmail.com is gmail-smtp-in.l.google.com. because it has the smallest priority number (5). If that server should fail receiving an email message for any reason, it will try the next lowest number server (alt1.gmail-smtp-in.l.google.com.). If that one fails it will try the next and so on, until one of the servers acknowledges receipt of the message.

Priority and Load Balancing

Load balancing of mail servers is done primarily in larger organizations, where a domain may receive a large amount of email traffic. Load balancing protects the integrity of the email servers enough that the entire hierarchy doesn't crash under extreme loads. This keeps your your network security teams from going crazy and your email administrator a happy camper.

With smaller organizations, it is possible to overwhelm a mail server with extremely heavy traffic loads. This is easily done with flooding a mail server with tons of messages until the mail process running on the server crashes due to running out of memory. Larger organizations can also fall victim to this type of behavior without the proper safeguard of load balancing their mail servers (among employing other security methods).

Mail server load balancing isn't done only to keep pranksters at bay. Balancing is done to keep servers happy and healthy, as well as recipients and senders from yelling at their email applications (or more importantly, the administrator) when they can't send an important message. It helps keep servers from getting backed up with a flood of legitimate messages being delivered to their intended recipients, which can happen from time to time under heavy periods of usage.

An good example of records that display a load-balanced configuration are the first two records of Comcast's Hosted Exchange mail servers:

10 mx01.biz.comcast.net  
10 mx02.biz.comcast.net  
50 mx03.biz.comcast.net  

The first two records are both weighed with 10. Because the records are weighted the same, they are in a load-balanced configuration, which it is intended to evenly distribute the load of incoming email between two receiving mail servers (called MTAs - message transfer agents). If one server experiences a high amount of incoming load, the sender's machine will ask for another MX record to attempt delivery of the message. Being weighed the same, it will use the record in the load-balanced configuration before moving to another record with a lower priority.

Priority and Spam Prevention

A technique called no-listing can be used to trick junk mail senders into essentially giving up delivery after an initial failure. True no-listing involves a MX configuration of with an unresponsive single primary MX record with one or more responsive lower priority MX records.

The no-listing method relies on a spammer using non-standard SMTP translations to send their email. As such, it's not a reliable long-term solution to curb spam messages. A no-listing configuration would look like this:

classicyuppie.com.    MX  10 dummy-mail-server.example.com.  
classicyuppie.com.    MX  20 real-mail-server.example.com.  

The advantage in the above configuration is that most spammers will hit only the hostname in the primary MX priority spot and ignore the rest, since the primary record is usually the one with the best chance of being available to receive messages. It's a spammer's goal to deliver as many messages as possible as quickly as possible, which is why they will generally only hit the primary record. Spam software doesn't keep retrying for a legitimate record because that would slow down the rate of bulk messages they can send.

Unfortunately, this thinking is tantamount to security through obscurity and isn't a reliable method of blocking spam. A spammer can hit another record manually or subvert the no-listing process by reconfiguring their sending software to recover from the error thrown by the dummy server record.

When Good Email Goes Bad

What if the receiving server can't find a mailbox that matches the address you're trying to send an email to? One of three things can happen:

  • The message will be rejected, resulting in a bounceback message being returned to you, or...
  • The message will be recieved by the server, queued for delivery to an alternate mailbox depending upon mail rules in place by the server, or...
  • The message will be delivered to /dev/null/.

How message delivery is handled is determined by the receiving server in most cases.

If a message is rejected and a bounceback email is returned to you, it's usually because the mailbox you're trying to send to does not exist. The most likely cause for this is due to a mistyped address when you composed the message. Check the address and try again.

If you send a mail message and it's delivered to the junk mail folder of your recipient's mailbox, it's most likely due to the recipient's email host flagging the message as spam. This could be due to the receiving server matching your message to criteria pre-determined in it's junk mail filter, or because the recipient doesn't want to receive email from you. This happens frequently with businesses who send mass email - newsletters, campaign emails, surveys - that matches up against spam filter heuristics.

If you are lucky enough to be sending email to individual or an an organization who had the foresight to put email aliases in place, then your email may still be delivered to its intended destination. Say, for example, I write an email to Joseph Smith over at Smith Co., but I can't remember the naming scheme of the company's email addresses. It could be jsmith, josephsmith, JoeS, joseph_smith, or any one of dozen other combinations. If a domain has email aliases in place, it won't matter.

Suppose that the actual email address of Joe is joe@smithco.com, but I accidentially sent it to jsmith@smithco.com. If an email alias is set up for the primary address, a conversation between your email server and the recipient's email server might look like this:

Gmail:     Here's a message for jsmith@smithco.com  
MX01:      I have no mailbox by that name. I'll queue the message until I find a place to deliver it... Oh, jsmith@smithco.com is another name for joe@smithco.com. I'll put it there!  

A variant of the alias is the forwarder. Set up as a true redirect, rather than an alias, forwarders aren't attached to a physical mailbox. They exist more as a rule on the mail server that directs the flow of an incoming message. Say for example joe@smithco.com isn't a mailbox at all, but one of these forwarders, set to redirect email to joesmith@hotmail.com. The conversation would look a bit different on the mail server.

Gmail:         Here's a message for jsmith@smithco.com.  
MX01:          Any messages for for that address I'm supposed to send to joesmith@hotmail.com. What server handles email for hotmail.com?  
DNS Server:    It's mx1.hotmail.com.  
MX01:          Where is mx1.hotmail.com located?  
DNS Server:    At 65.54.188.110.  
MX01:          Hello, 65.54.188.110. I have an email for you.  
MX1:           Ah, I see it's for joesmith@hotmail.com. I'll put this in their mailbox now.  

An Inbox Doesn't Equal Email

An anonmaly I've seen in troubleshooting receiving issues is that a mailbox (or mailboxes) will be set up on the mail server with given provider, but the MX records will point to a different service provider. It may seem obvious, but without your MX records pointing to the server that your mailboxes exist on, no email will flow to them. It's important to ensure that if you're mailboxes are on server A, your DNS records point to server A. Pointing them to server B, even inadvertently, won't help you get your email.

Be Careful How You Troubleshoot

When DNS records are set incorrectly, mailboxes on the same domain may still be able to send email to each other. This happens because because when you send a message between mailboxes on the same server, the message never actually hits the Internet in most cases. The message is transferred between inboxes on the same server.

This happens because most mail servers use internal DNS lookups to determine the shortest path between the sender's and receiver's mail servers. If they happen to be the same, that information is picked up during the message routing process. This is why a majority of the time it’s not adviseable to test email delivery by emailing yourself or another mailbox on the same domain.

Checking Server Ports

If you're running your own email server, data center connections generally won't be blocking the standard ports used for email: 993, 995, 25, 587, and 465. If you're having issues sending or receiving, you or your email administrator may need to check the respective ports by direct testing or dumping log files to determine if the necessary ports are opened on the server and able to receive traffic.

Most home-based or small-business connections provided by your local ISP may restrict access to port 25 for sending email. Access to port 25 can cause SMTP relay to affect your ability to send email. SMTP relay essentially allows unauthorized senders to bounce email from your mail server to either another mail server (to attempt to mask the origin of the email) or direct to it's destination (a method of piggybacking for those who aren't running their own mail server). Since all service providers have a Terms of Service agreement which states you users cannot operate services aimed at abusing their bandwidth, ISPs can place a block or restriction on port 25 if a high amount of activity is determined to be transmitting from your IP address.

To avoid this hassle, it's best to only allow authenticated connections with either SSL (port 465) or TLS (587) encryption to your mail server. However, if for some reason you need access to port 25 with a home-based or small-business connection, it's best to consult your ISP's technical support or security department to ensure this port isn't blocked.

How Third-Party Spam Filters Affect Mail Flow

Inbound Filtering

In my travels around the Internet, I've seen spam filtration cause all sorts of weird things with both sending and receiving email to a domain.

Third-party spam filters are a great way to combat the rising tide of junk email, especially for large organizations. A spam filter running on the receiving mail server of an extremely large organization can do more that just slow things down, it can in some cases cause a crash of the email system or present other security hazards.

However, spam filtration software, while powerful at what it does, is extremely dumb at some obvious things. It has one function: to scan email for matches against a pre-determined set of criteria and, if it passes, deliver that message to the domain's mail server for handling by that machine. If an organization's mail server has a mailbox for joe@smithco.com set up, but the admin forgets to add that address to their spam filter software, the message will most likely be rejected. Because the spam filter doesn't recognize joe@smithco.com as a recipient, it doesn't know it's suppose to forward that on to the organization's mail server. The address must both be set up on the mail server and in the SPAM filter in order for mail to flow smoothly.

See, I told you SPAM filters were powerful but dumb.

Outbound Filtering

A spam filter can also be used to scan outbound email from your domain to a recipient to scan for things like spamminess, bad headers, and virus scans on attachments. This can cause an issue when sending email that never arrives in a recipient's mailbox.

Generally, you won't get an error message although sometimes you might. This is due to the fact that if someone were to gain access to a mailbox on your domain, they could send out spam or virus-laiden emails without the administrator immediately noticing. They'd have to check the logs to determine if some nefarious work is going on under their nose.

Outbound messages may be stuck in quarantine, deleted completely, severely delayed, or delivered by flagged as spam by the recipient's filter. The behavior would be determined by the sender's filter first, with a re-scan of the message by the recipient's filter, causing message handling to be unpredictable at times.

Querying These Records

To query MX records:

Linux/Unix/Mac OS

dig mx <hostname>  

Windows (all versions)

nslookup type=mx <hostname>  

Conclusion

MX records are an important part of how we send and receive email across the Internet. Without them, we'd probably still be stuck using a BBS or paying for a Usenet subscription to converse for business and personal reasons.

A properly configured MX record can ensure you'll receive email for a long time. A poorly configured one can wreak havoc on your personal or business life. Be sure to set up your MX records (and any accompanying CNAME records) the way your email provider recommends. Doing this has the added advantage of making things a bit easier to troubleshoot when something does go wrong, as an improper DNS configuration can easily be ruled out. I've seen improper priorities, invalid hostnames and incomplete records used in all sorts of ways. When in doubt, refer to your technical support for the best method to set these up.

My next post in the DNS Crash Course series will be on CNAME records, due out in a week or two. Until then, you can recap with my previous post covering A, AAAA, and PTR records.