|Previous Top Next|
An e-mail address provides a server with all the necessary information on the recipient and how the message should be delivered. For instance, a server needs to deliver a message to the following e-mail address: email@example.com. In this case "example.com" is the mail domain and "user" is a username within that domain. First of all, it is necessary to define which server(s) are responsible for mail directed to the "example.com" domain and then initialize a connection to it via the SMTP protocol, after that it's up to the respective server to deliver the message to the user. In order to find the responsible server the DNS (Domain Name System) is used. The DNS-server keeps different sets of records for domain names and returns the respective records for certain domains upon request. In our case (in terms of e-mail) we are interested in records of the MX and A types.
The MX record contains number which determine the priority of a record followed by host name responsible for the certain domain's mail. Host with lower priority value should be used prior to the others. Hosts with equal priority can be used randomly.
If the server encounters it's own name in the list of the hosts responsible for that domain's mail, it has to establish connections only with hosts possessing lower priority than it's own. This is done on purpose to avoid situations in which an e-mail might stuck within a circle of servers forever.
In our case, for example, the following MX records might be received:
example.com MX 10 mx1.example.com
example.com MX 20 mx2.example.com
example.com MX 20 mx3.example.com
In this case the server has to try to pass over the message to "mx1.example.com" host first, and in case of a failure randomly to the "mx2.example.com" and "mx3.example.com" hosts.
The MX records provide us with host names only, whereas the A records are used to determine its IP-address. The A record contains the IP-address for a given domain. A single domain can possess several A records, in other words a domain can have several IP-addresses. While sending out mail we have to try to connect to each IP-address (in any order)
In our case we might receive the following A records for the "mx1.example.com" host:
mx1.example.com A 188.8.131.52
mx1.example.com A 184.108.40.206
What we should do next is try to connect to the 220.127.116.11 and 18.104.22.168 IP-addresses in any order and in case it fails move to the next MX record.
Such record structure allows implementing the following:
|·||Server cluster. Large-scale mail portals might use several
servers simultaneously in order to improve its performance and
stability, in case a particular server goes down the rest continue
to function properly. This procedure also allocates workload
between them thus improving the overall server performance.
Such structure can be realized either with the help of several MX (with equal priorities) or A records. Since the mail servers process records in the order they had been received from the DNS-server it is highly important they be returned in a random order, thus the load will be divided evenly.
|·||Reserving servers. In such structures there is a main server
and backup servers which can receive mail if the main server is not
responding. In order to implement that several MX records with
different priorities are created. The main server possess the
lowest priority value (it will the first one to be connected to)
while the backup servers have a higher priority value (they will be
connected to if the main server is not responding).
In our example "mx1.example.com" represents the main server while "mx2.example.com" and "mx3.example.com" are backup servers.
Important. The latter scheme can also be used in case the company decides to maintain the mail domain (formerly maintained by the ISP server) by itself. It is necessary to add the MX record referring to a server within the company. Note that its priority value has to be lower (main server) than the one of the ISP server (backup server).
This will allow setting up the server within a company much easier, as a last resort the mail will still be received by the ISP's server. When the internal server is finally up and running, you can remove the MX record from the ISP's server (or leave it as it is just to be on the safe side).