What is MX Record? The DNS record (mx) explained

The Domain Name System (abbreviation: DNS) is primarily known for name resolution. This is because it allows internet users to enter an easy-to-remember URL in the browser – otherwise they would have to surf using unwieldy IP addresses. To perform name resolution, the DNS uses A and AAAA records – and in certain circumstances, CNAME records as well. However, there are even more DNS record types through which the system provides further options.

The MX record is one type that doesn’t exactly refer to the World Wide Web, but instead concerns email communication. But what exactly is it?

DNS records are located in zone files. These are simple text files that bundle all records into a zone for which the relevant server is responsible. Should a client submit a request, the responding server receives the information from precisely this data file. The various file types have different functions. The abbreviation MX stands for mail exchange and thus already gives an indication of the record’s purpose: Through the MX record, a client receives information via DNS regarding the domain under which a mail server can be reached.

Different servers usually form part of a domain. Besides the web server, which supplies the website, there is often also the FTP server, and in fact even one or more mail servers. All of them can be reached via different subdomains. The name of this subdomain can be requested via the MX record. This manages the mail server from which the email is sent, in most cases automatically.

DNS records consist primarily of several units of information placed in different fields. In addition to information such as the name of a specific domain’s mail server, other details can also be transferred in this way:

• <name>: The first field contains the domain name.
• <ttl>: Time to live specifies how long the information is guaranteed to be valid.
• <class>: The class field specifies the type of network.
• <type>: The DNS record type in this case is MX.
• <priority>: The smaller the value, the higher the mail server’s priority.
• <rdata>: Resource data defines the mail server name.

Domain names are always specified in the Fully Qualified Domain Names (FQDNs) format in all record types. This means that the content of each field is ostensibly completed with a full stop. Actually, the FQDN maps the complete path to the root server – from the smallest unit located to the far left, to the largest situated to the far right. The highest level is unnamed however, which is why there is nothing after the preceding periodfull stop.

The time to live specifies how long the requestor can hold and use the information in their cache. This is intended to ensure that no outdated records are used. Should the time lapse, the client must again request the record from the name server. The TTL is specified in seconds. This field frequently does not appear in the actual record. Instead, the time for the complete zone is defined at the beginning of the zone file.

The class field is optional, as nowadays only the internet is possible. When resource records were first introduced however, both the Hesiod (HS) and Chaos (CH) classes were possible. However, both networks are today no longer in operation. For this reason, the field remains either empty or invariably contains the IN abbreviation.

The field relating to priority is a special feature of MX records. Many administrators – in particular those of larger projects – have several mail servers running in parallel. As a result, failures and load peaks can be compensated and email communication doesn’t run the risk of sudden failure. In doing so, however, distribution is not necessarily supposed to occur evenly. For this reason, priorities can be assigned. The server with the lowest value has the highest priority and is selected first. If it isn’t available, then the server with the next-highest value is chosen.

The data field finally contains the mail server name. This is also specified in the FQDN format. In the record, all fields follow one another within a line. The record isn’t ended using a specific symbol; a line break is sufficient.

In practice, both the TTL and class fields rarely appear in records.

As an example, we are using the made-up mail server example.com. A suitable email address for our purposes would be something like user@example.com. The web server’s sender would thus send their DNS request to the example.com domain. The name server’s zone file for the appropriate records would then look like this:

As you can see here, the duration of the information is valid for the entire zone. In the individual records, the field no longer needs to be integrated for this reason. In this example, we initially have an A record that the domain links with an IP address. Then three MX records follow. You may notice that this only differs for the subdomains.

The first two mail servers have the same priority levels in this example. Both tasks are thus distributed accordingly between both. Mail server 3 is then first addressed if the other two can no longer handle the load – for example, due to a failure.

In the example search, you can see the different mail servers under “Answers.” The FQDN, under which these can be reached, can be found under the data item. There the priority is also specified: The records in this section are in the range of 10 to 50. Because the TTL is the same for each record, you can assume that the duration of the information’s validity has been set for the entire zone. The same number is always located under type: 15. This corresponds to an MX record. The Internet Assigned Numbers Authority (IANA) has actually assigned each DNS record type a value and in this way has numbered the entry types consecutively.