Guts of a Mail Server: What is it and how does it work?

What’s a Mail Server?

“What exactly is a mail server?” Considering how widely-used email is, and how technical it gets, this is not a question you should be embarrassed to ask. So, what is a mail server, then?

A mail server is a dedicated computer with a static IP address that your mail client (Gmail, Outlook, Apple Mail) talks to via SMTP and either POP3 or IMAP, and which uses a special program to route, receive, and store messages. That’s all simple enough but not exactly what you want to know. To understand what makes a mail server special, let’s break it down:

An Inventory:

• A physical server
  • A good computer on a robust network switch with a high-bandwidth Internet connection and a static IP address.
• An MTA
  • The MTA, or mail transfer agent, is the program that turns your words into something ready to travel the Internet.
  • It accepts messages from your mail client (aka mail user agent or MUA: Gmail, Outlook, Thunderbird, Apple Mail, etc.) and uses SMTP (Simple Mail Transfer Protocol) to push them to their destination MTA, where the MDA (mail delivery agent) uses POP3 (Post Office Protocol version 3) or IMAP (Internet Message Access Protocol) to place the message in the recipient’s MUA. (You might remember POP3 and IMAP from setting up your phone.)

The MTA might sound simple in theory, but there’s a lot going on behind the scenes to make everything happen smoothly across millions upon millions of machines.

To start with, an MTA handles your domain. A domain is a type of address that lives in the DNS.  When you look up an email domain in the DNS, it points to the location of an MTA that is set up to consider what domain is the “local” domain. In other words, if your MTA serves its own domain and if it receives an email addressed to any other domain, it looks up that domain in the DNS and passes the message along. Of course, if it receives an email addressed to its local domain, it keeps the email.

Now, you can have more than one domain on a mail server, but you can’t have the same username twice on the same MTA. This means Zack@inboxpros.com conflicts with Zack@proinbox.com (assuming they are both local to one MTA). Obviously, there’s a way around this or we’d be tripping over separate mail servers for every single domain ever created.  The answer is “virtual domains,” which are domains that the MTA pretends are not local for the purpose of user identification, but are local for the purpose of sending and delivery (no DNS lookup, etc.).

MTA Qualifications

Next, remember how the domain is an address? It doesn’t seem very specific; how does an MTA know how to find my cell phone just by Zack@inboxpros.com? That’s a bit like having a letter addressed to “Zack, Atlanta”. No post office could deliver that! The answer lies in the host. A host, in general terms, is a connection on a network. Essentially, to a mail server, the domain is the external address of the MTA, and the host is the internal address of the user’s mailbox. This means a mailbox’s address is not just Zack@inboxpros.com; it might look more like this: Zack@workstation25.atlantaoffice.subdomain.inboxpros.com. Including the host in the address is called “qualification” and if the receiving MTA is not set up with the correct qualification for the addressee, nothing gets delivered and the email bounces.

This means that the MTA needs to have recorded what host information (internal address) to give to each user at its domain (external address). Now it makes sense that the MTA can’t have two identical users even if they are on different domains. Once the email enters the correct MTA, the external address (domain) no longer matters and doesn’t make the users unique anymore, meaning their hosts (internal addresses) could end up identical and conflict. This is what a virtual domain solves–it makes the host addresses of users in the virtual domain unique from the other local domain, so there is no possible user address conflict and mail goes to the correct mailbox.

When an MTA sends an email to another MTA, it includes a Reply-To and a Return-Path, which are not necessarily the same, however, neither usually contain any host information at all–that info doesn’t leave the mail server. This is because a fully qualified address is often long and complex and is also a useful thing for a bad actor to have. Therefore, an MTA does what’s called “masquerading” and hides all of that detailed address information, by pretending the mailbox lives at the domain, before the message hits the Internet. This is why you only see domain and subdomain in your “To:” and “From:” fields.

Now that the MTA knows the host information, the address is more specific; but how does it become a cheerful “bing” in my pocket? The answer is POP3 and IMAP. These are the same special connections that mail clients use to send mail to your server, and the MDA (mail delivery agent) of the MTA uses them to find logged-in users and drop the messages into their MUAs (mail clients). 

Have additional questions? Contact one of our deliverability strategists.