Why MX records have a priority (and A and NS records don’t)

Unlike CNAME, which is a “Canonical Name” record that sets a particular subdomain as an alias of another domain name, NS, A, and MX records are all DNS record types that you can have more than one of for a given value.

But MX records are unique among these three record types because MX records have a priority.

So, why is that? And is it important?

Why MX records have a priority

An MX record (or “Mail eXchanger” record), for the uninitiated, are used to indicate your domain name’s email servers. In addition to standard DNS record fields like Name, TTL (time to live), Type, and Value, MX records also have a “Priority” field. The lower the value in the Priority field, the higher the priority.

A typical MX record implementation would have 2+ MX records, with varying levels of priority. For example, here’s the MX records required for Gandi’s email service:

@ 1800 IN MX 50 fb.mail.gandi.net.

@ 1800 IN MX 10 spool.mail.gandi.net.

The mail server fb.mail.gandi.net has a priority of ’50’ and the server spool.mail.gandi.net has a priority of ’10’.

Priority indicates the order in which these mail servers should be tried by a mail server attempting to deliver email. A mail server trying to deliver to Gandi’s email service would try to deliver to spool.mail.gandi.net first, because it’s priority is ’10’. If that doesn’t work, though, it will try fb.mail.gandi.net (because it’s priority is ’50’).

That way, if for some reason, spool.mail.gandi.net isn’t available, is busy, or is offline, the email can be delivered to fb.mail.gandi.net instead.

Why don’t A and NS records also have priority?

Other records like A and NS records accomplish a similar objective. Gandi’s LiveDNS service uses the following NS records:

@ 172800 IN NS ns-89-c.gandi.net.

@ 172800 IN NS ns-32-b.gandi.net.

@ 172800 IN NS ns-202-a.gandi.net.

If ns-89-c.gandi.net isn’t available, a DNS resolver can contact ns-32-b.gandi.net or ns-202-a.gandi.net and get the answer it’s looking for.

Similarly, you could add two A records pointing to different web servers hosting the same content and if the first is down or unavailable, then a web visitor could try the second one, or vice versa.

But A records and NS records don’t have a priority because it’s not necessary for this kind of fallback mechanism to work.

Why does an MX record need a priority?

To be perfectly honest, with modern infrastructure, it probably doesn’t. But having multiple MX records is more complicated than simply providing a fallback.

Generally, the server the MX record points to with the highest priority is the one that handles incoming email. The fallback doesn’t actually deliver the mail, but queues it for when the top priority server is available again. In other words, it’s actually important which mail server gets tried first. It’s not, however, important which web server or name server gets a particular request.

This is a holdover from days gone by on the internet when it could take a few days to deliver an email, and sometimes an email server might go offline for hours at a time without holding up thousands of business-critical emails.

More fun with multiple records of the same type

The A record’s lack of priority actually enables it to be used for something called round robin DNS. This is DNS-based load balancing technique where you use multiple, redundant web servers and add A records pointing to each of them. Theoretically, the list will appear in a random order each time it’s queried, causing a randomized list of web server IP addresses hosting a website to be generated.

Caching does interfere with this, though, since anyone using the same cache will try the same web servers first.

If A records had a priority, though, using DNS like this wouldn’t work at all.

Tagged in DNS