How a mail server works

I had originally written this tutorial for xmodulo.com

Email service is one of the most often used services globally. Today almost everyone has at least one email account. Although clicking on the email send button and delivery of an email message appear seamless, a lot of events take place behind the scenes to make sure that the email reaches its final destination.

The functionality of a mail server can be divided broadly into two processes: sending and receiving emails. The following two protocols oversee these processes.

• Sending email: Simple Mail Transfer Protocol (SMTP)
• Receiving email: Post Office Protocol (POP) / Internet Message Access Protocol (IMAP)

Terminology

The following terminology is important in understanding the operation of a mail server.

• Mail User Agent (MUA): The MUA is a component which interacts with end users directly. Examples of MUA are Thunderbird, MS Outlook, Zimbra Desktop. Web mail interfaces like Gmail and Yahoo! are also MUA.
• Mail Transfer Agent (MTA): The MTA is responsible for transferring an email from a sending mail server all the way to a recipient mail server. Examples of MTA are sendmail and postfix.
• Mail Delivery Agent (MDA): Within a destination mail server, local MTA accepts an incoming email from remote MTA. The email is then delivered to user's mailbox by MDA.
• POP/IMAP: POP and IMAP protocols are used to fetch emails from a recipient server's mailbox to recipient MUA.
• Mail Exchanger Record (MX): The MX record is the DNS entry for mail servers. This record points to the IP address towards which emails should be shot. The lowest MX record always wins, i.e., gets the highest priority. For example, MX 10 is better than MX 20. The IP address of the MX record may vary based on the design and configuration requirements, as will be discussed later in the article.

When a sender clicks on the send button, SMTP (MTA) ensures end to end delivery of an email from a sender-side server to a destination server. Upon reaching the destination server, the MTA local to the destination server accepts the email, and hands it over to the local MDA. The MDA then writes the email to a receiver's mailbox. When the recipient checks for emails, they are fetched by MUA by using protocols like POP or IMAP.

Mail Service Without Use of Service Provider MX

To keep things simple, the first example will exclude the use of any service provider MX. Let us assume thatuserA@exampleA.tst is trying to send an email to userB@exampleB.tst.

The following parameters are configured.

• Both exampleA.tst and exampleB.tst domains have proper DNS registrations.
• DNS servers have valid MX records for both domains (the records are shown in the figure).

A series of the following events take place as soon as a user initiates sending an email.

1. The MUA of a sender initiates a connection to exampleA.tst mail server using SMTP (typically TCP Port 25).
2. The server mail.exampleA.tst receives an email, and learns that a destination domain is exampleB.tst. The mail server generates a query to a local DNS server asking about the MX record for exampleB.tst. Let us assume that there is no information about the destination domain in the local DNS cache yet.
3. The local DNS server in turn generates a recursive query towards the authoritative DNS server, and learns about the MX record details of exampleB.tst. This information is shared with the mail server mail.exampleA.tstas an answer.
4. Now that the mail server has the IP address of the destination mail server, it sends the email directly towards the server mail.exampleB.tst over the Internet. SMTP is used for communication between the source and destination mail servers.
5. The incoming email is received by the SMTP (MTA) local to mail.exampleB.tst. After the email is received, it is handed over to MDA, which then writes the mail to a recipient's mailbox stored in the server. The server has separate mailboxes for each user.
6. When the recipient checks the email via POP or IMAP, the email is fetched by MUA from the server. Depending on MUA configuration, emails can be downloaded in the workstation, copies can be kept in both server and workstation, or emails between server and MUA are synced.

Mail Service with Use of Service Provider MX

Most ISPs maintain their own Mail Exchangers (MX) for their customers. These MX servers are also known as Smarthosts or Relay Servers. Smarthosts are usually equipped with advanced virus scanners, powerful spam mail detection and blocking systems. These servers are also built to ensure maximum up-time and best performance for email delivery service.

Using the service provider MX is optional, but it can provide some additional benefits, such as:

• Mail scanners provide security against both incoming and outgoing malicious mails and mail attachments.
• ISP MX is the last hop before a customer's end mail server. Even if a customer's mail server goes down, incoming mails will stay in the SMTP queue of ISP MX until queue timer expires. The MX server will keep trying to send emails periodically to the customer. Emails can be delivered whenever the customer' mail server comes back online. This feature can significantly reduce the rate of undelivered emails, i.e. bounces.

Let us assume that exampleA.tst is a customer of ISP A, and exampleB.tst a customer of ISP B. Also assume thatexampleA.tst mail server is configured to send all outgoing mails via mx.ispA.com, while exampleB.tst wants to use the MX server of the ISP B, i.e., mx.ispB.com. As mentioned earlier, the lowest MX record gets the highest priority. Keeping this in mind. The (hypothetical) MX record for exampleB.tst can be defined as below.

 
   IN MX 10 mx.ispB.com
   IN MX 20 mail.exampleB.tst
mx.ispB.com  IN A  Y.Y.Y.Y
mail.exampleB.tst IN A  B.B.B.B

With proper configuration, the following events take place while an email is sent from userA@exampleA.tst touserB@exampleB.tst.

1. An email is sent from userA@exampleA.tst MUA to mail server mail.exampleA.tst using SMTP. The mail server mail.exampleA.tst is configured to send all outbound mails to mx.ispA.com, instead of sending emails directly towards a destination over the Internet. Virus/spam check is done as soon as ISP A relay host i.e., MX receives the email.
2. Assuming that the server mx.ispA.com does not have any DNS information about exampleB.tst, a query is sent to a local DNS server asking about the MX record.
3. The local DNS server gathers required information, and learns both MX 10 and MX 20 records. Since MX 10 is the lowest MX record, it will be used as a primary mail server. MX 20 will be used only when MX 10 goes down i.e., ISP B Smarthost is unreachable for some reason. The DNS server answers the query of the MX server with necessary information.
4. As the server mx.ispA.tst has all necessary information, it sends the email directly towards mx.ispB.comover the Internet. The email is scanned upon arrival. When the ISP B Smarthost recognizes that the server itself is not the final destination, it forwards the email to the customer's mail server, based on the forwarding decision configured by the server's administrator.
5. The local SMTP in mail.exampleB.tst receives the incoming mail, and hands it over to local MDA. The MDA in turn delivers the email to a recipient's mailbox.
6. Finally, the recipient can check the email using POP or IMAP.

To sum up, the entire process of email communication needs many steps performed in the background. Based on the configuration, emails can be sent directly over the Internet from one server to another. Service provider MX can also be used depending on the requirements, and of course, SLAs (Service Level Agreements).

Hope this helps.