Email infrastructure and how email sending works

Mail user agent (MUA)

An email client or webmail is also known as a mail user agent. It’s a web-based or computer application that can be used to send and view emails. An MUA will download emails from a user's remote storage mailbox to display them to the user. It’s the component that users generally interact with. Some examples of MUAs are Outlook, Apple Mail, Zoho Mail, and Gmail.

Mail submission agent (MSA)

An MSA acts as an intermediary between the MUA that initiates the email and the mail transfer agent (MTA) that delivers the email. An MSA receives the outgoing email from the email client (MUA) and performs various checks to authenticate the email and eliminate spam. It checks for sender credentials, formatting mistakes, spam content, and compliance with email protocols, among other things. If the email checks out, it hands the email over to the MTA to be delivered.

While an MTA can perform the action of an MSA, having a separate MSA can be beneficial in many ways. Having an MSA will notify the sender of potential mistakes before delivery attempt, whereas in the case of an MTA, the sender is notified of mistakes only after delivery is attempted. It prevents spam, phishing, and malicious content to a certain extent. This, in turn, decreases the chance of delivery issues or rejections.

Mail transfer agent (MTA)

The mail transfer agent is responsible for the actual relaying of the email. It receives the email from the MSA and transmits it to the destination. The MTA first accepts the email from the MSA. Then the MTA looks up the destination of the domain where the email has to be delivered, often using mail exchange (MX) records. The MTA uses SMTP relay to deliver the email to the next step.

Message delivery agent (MDA)

The message delivery agent receives the email from the MTA and stores it to deliver it to the MUA (email client) of the recipient. The MDA is the component of the email infrastructure that’s also referred to as the recipient email server.

Email protocols

Email protocols play an important role in the email infrastructure. They’re the components that enable the transport of email across these different agents. There are three prominent protocols:

• Simple Mail Transfer Protocol (SMTP): SMTP is responsible for the email sending part of the operations. It’s the outgoing email protocol. It performs authentication checks and hands the email over to the next steps.
• Post Office Protocol (POP): POP is the protocol responsible for the accessibility of the delivered email. Once the email is delivered to the recipient server, POP will retrieve the email to be viewed. After downloading the email from the server, it deletes the message from the server.
• Internet Message Access Protocol (IMAP): IMAP is similar to the POP protocol in theory. It’s also used to retrieve emails from the server and display them, but it’s a more complex protocol and different from POP in some ways. For example, unlike POP, IMAP leaves a copy of the downloaded email on the server, and it also has the ability to maintain folder structures.

Email domains

Even the most infrequent email user would have come across email domains. If your email address is rachel@zylker.com, zylker.com is the email domain. It’s equivalent to the address we write down when addressing a physical mail. It denotes where the email needs to be delivered.

Email domains can be broadly classified into two groups: shared domains and custom domains.

• Shared domain: These are often owned by major ESPs. They will allow users to sign up for a mailbox, and the domain will be their common domain. For example, gmail.com, outlook.com, or zohomail.com.
• Custom domain: Custom domains are often owned by the sender alone. For example, if you own a business called Zylker Mobiles, your custom domain will be zylkermob.com.

Whichever email sending domain you should opt for completely depends on your purpose. If you’re looking for an email address for personal purposes like writing to your friends and family, then a shared domain provided by an ESP is sufficient. But if you're a business owner or using the email address for some professional use, it’s best to have your own custom domain.

IP address

An Internet Protocol (IP) is your address on the internet. It contains a string of multiple numbers separated by periods, like 112.3.43.235, 222.22.4.54, or 54.2.34.023. In the context of sending email, a unique IP address is given to your domain by your Domain Name Server (DNS), which will be used to locate where your email needs to be delivered. IPs are important for data to be shared or communicated over the internet.

Much like IP addresses, there are two types of IP addresses—shared and dedicated IPs.

• Shared IP: ESPs generally maintain IP addresses that are shared by a pool of users for email sending. Users with similar sending patterns are often assigned to the same pool. The email activities of each user in the shared IP will affect the other users, good or bad.
• Dedicated IP: These are IP addresses that aren’t shared. If you’re assigned a dedicated IP, only you will be sending emails from the IP. While you have complete control over your sender reputation with a dedicated IP, if you're not a high-volume sender with a well-established reputation, dedicated IPs might be detrimental.

Take a look at our article on IP addresses to see which one is a good fit for your email sending.

Domain Name Servers (DNS)

Name servers are the basic unit of a DNS system. They hold information about all of the domains they host. DNS is responsible for assigning IP addresses to domains, authentication records, and much more. During the process of email sending, DNS is constantly referred to. First, it’s to navigate the email to the right recipient using the information hosted in the DNS, like MX records. Second, DNS contains all of the authentication records like SPF and DKIM that are used to check the authenticity of the email sender while the email is being delivered.

Feedback loop

A feedback loop (FBL) is an important component of email infrastructure that comes into play after the email has been delivered. FBL will notify email senders if their emails have been marked as spam. This gives the senders an opportunity to fix issues in their emails or, sometimes, even remove the recipients from their recipient list. While FBL is an important component, not every sender uses this. While a registration process is involved, it’s crucial to stay informed of your email's performance so you can improve your email sending practices.

Hit “send” on the MUA

This step is the one that everyone is familiar with. MUAs, like email clients or webmail interfaces, are where the email sending process begins. You log into your inbox, open the mail composer, and draft your email. Once the email is ready, you hit the send button. This initiates the email delivery process.

Checks by the MSA

Once the send button is triggered, the email is transferred to the MSA. The MSA is a middleman between the MUA and MTA/SMTP server. It receives the email from the MUA and performs certain checks to see if the email is in the right format, has minor errors, and more.

Transfer to an MTA

Once the check is done by MSA and the email is found to be compliant, the MSA hands over the email to the MTA on the outgoing SMTP server. This email is in the MIME format (Multipurpose Internet Mail Extension) that accommodates the transfer of media files like audio, video, images, and more. After the email is received by the outgoing server, it again performs certain checks to validate the email’s authenticity. The sender details, associated data, and compliance with existing rules of the email account are verified. This transfer of email from the client to the server and additional transfers are performed using SMTP, which is a set of rules for email transfer between email clients and servers.

Pinpoint recipient location

This step can vary depending on where the recipient is located. The SMTP server checks to see if the recipient is also part of the same location as the sender; that is, the recipient address and the sender address belongs to the same domain. If this is the case, the email is kept on the same server to be accessed by the recipient's client later.

The more likely scenario is that the recipient address isn’t part of the same domain. In this case, once the SMTP server is done running validating the email, it contacts the DNS to retrieve the location of the recipient in a format that’s understandable by the server. To do this, the MX lookup is employed. Every email address hosted in a domain will have a MX record added to the associated DNS. This MX record contains information about the host and IP address of the email address server. Using MX lookup, the outgoing SMTP server will fetch the details and use it to route the email in the right direction.

Server-to-server connection

Once the server identifies the location of the recipient, the sender server attempts to establish an SMTP connection with the recipient server. This is referred to as the “SMTP handshake.” During this connection, the sender and recipient information is exchanged to verify authentication.

In cases where the recipient server isn't available to establish the connection directly, the email message is routed through multiple servers to facilitate the email’s delivery to its final destination. This is called “SMTP relay.”

Spam checks by the recipient server

Once the email reaches the recipient server or message delivery agent (MDA), it runs a series of checks to authenticate the email. MDA checks for spam, phishing, malicious content, and other security breaches using email protocols like SPF, DKIM, and DMARC.

• Sender Policy Framework (SPF): This determines whether the sending server has permission to send the email.
• DomainKeys Identified Mail (DKIM): This email protocol uses a digital signing process to ensure that the email hasn’t been tampered with after being sent.
• Domain-based Message Authentication Reporting and Conformance (DMARC): This email protocol informs the recipient server of the SPF and DKIM status that can be expected and what to do when the expected standard isn't met by an email.

Delivery to the recipient client

Once all of the checks have been performed on the email and the email has passed the verification, the email is finally accepted by the recipient server. The recipient MUA then uses the IMAP or POP protocols to download the email to the email client where it can be displayed to the recipient.

Permanent reasons

If the email cannot be delivered due to permanent reasons, it’s considered a hard bounce. The email is bounced back to the sending server with a notification of the bounce reason. Hard bounces are often characterized by 5xx series error codes. Some possible reasons for hard bounces are:

• Invalid email address: When the email has been sent to an email address that doesn't exist either due to an error in the email address or because the address was deleted.
• Invalid domain: When the email is sent to an email address whose domain doesn’t exist.
• Missing MX records: MX records are used to identify the location of the recipient and route the email. If the MX record is missing, there’s no way the sending server can deliver the email.

Temporary reasons

If the email can’t be delivered because of temporary reasons, it’s called a soft bounce. This email is added to the retry queue, and delivery is periodically tried in the hopes that the bounce reason has been resolved. If the delivery attempt fails after a certain number of times, the email will then be returned to the sending server. Soft bounces are often characterized by 4xx series error codes. Some possible reasons for soft bounce are:

• Mailbox full: The recipient’s mailbox storage is full, so the email cannot be delivered at that instant. If the mailbox has storage left during any of the subsequent attempts, the email will be delivered.
• Server occupied: If the recipient server is too busy to receive the email, the email will be set aside to retry delivery.
• Greylisted: Sometimes the recipient server will greylist senders for temporary reasons on suspicion. This often resolves itself, and the email will be delivered in later attempts.

Some of these reasons can be placed in one category by certain email providers and another category by other providers. While in most cases these reasons fall under the categories mentioned here, it’s best to check the standard set by the recipient’s email provider in case of bounces.