E-mail Infrastructure Components and Authentication Protocols

5 minute read


Hello, 🌎! Hundreds of billions of e-mails are sent and received every day. But out of the 4+ billion e-mail users, I’m pretty confident that 95%, possibly even more, do not know the underlying components that facilitate the transfer and reception of e-mails. Well in this blog, I am going to describe the components that make up an Internet e-mail system and the most important authentication protocols that help protect against common email-based attacks.

Mail Infrastructure Components

There are four main components that handle all the sending, forwarding, and receiving of e-mails:

Mail User Agents (MUA)

Mail Submission Agents (MSA)

Mail Transfer Agents (MTA)

Mail Delivery Agents (MDA)

NOTE: one thing to note here is that the MSA and MTA are usually the same application running on a server. However, there are setups that do seperate these functions.

Now let’s break down what each of these components are responsible for.

Mail User Agents (MUA)

The MUA is the application to send and receive emails, to and from, a mail server. This is the application you interact with when you are writing an email. MUAs are also known as an email client which you might know as Microsoft Outlook, Yahoo!, Gmail, ProtonMail, etc. These applications help abstract away the creation of an email so that we don’t have to write raw email headers, which would writing emails quite tedious.

Mail Submission Agents (MSA)

An MSA is an application that runs on the mail server that receives the e-mail sent by the MUA and performs error handling, addresses formatting issues, and also adds any additional mail headers to the e-mail. The MSA is also responsible for forwarding emails to the MTA, if it has been configured as an individual component. Otherwise, the functions of the MSA are included in the MTA.

Mail Transfer Agents (MTA)

The MTA is responsible for transfering mail between servers via the Simple Mail Transfer Protocol (SMTP). If the recipients mail server is not local then an email will need to be relayed across a chain of MTAs, until delivery to the recipients MDA is possible.

Every domain that accepts e-mail must define an DNS MX record which MUAs can use to determine what mail servers are responsible for receiving mail for a given domain.

For example, here are Gmail’s mail servers:

dig mx +noall +answer gmail.com

Google’s MX Records

Mail Delivery Agents (MDA)

The MDA is an application that runs on the recipients mail server that receives e-mails from an MTA. Examples of MDA services and apps include Maildrop, Dovecot, procmail, fdm, postdrop, etc.

Mail Authentication Protocols

Sender Policy Framework (SPF)

SPF is an extremely helpful authentication protocol that helps prevent spoofing and phishing. SPF allows the owner of a domain name to define specific entities that should be able to send e-mails on its behalf. This can be an IP V4/6 address or a domain from which you’d like your e-mails to originate from. Receiving MUAs can use the origins specified in the SPF to cross-check that an email has been sent from a trusted mail server.

Here is Google’s SPF record:

dig txt +noall +answer _spf.google.com

Google SPF Lookup

This SPF record says that emails sent on behalf of google.com should be originating from _netblocks.google.com, _netblocks2.google.com, or _netblocks3.google.com.

Domain Keys Identified Mail (DKIM)

DKIM is used by MUAs to generate and verify signatures that can be used to verify the identity of the sender. DKIM uses asymmetric cryptography which means two keys are used - one to encrypt and the other to decrypt. Here is how the DKIM process works:

  1. The senders MUA hashes the body of the e-mail
  2. The senders MUA encrypts the hash generated in the previous step and sends it along with the original email as a signature
  3. The recipients MUA receives the e-mail containing the signature.
  4. The recipients MUA makes a DNS TXT query to obtain the sendering domains public key
  5. The recipients MUA decrypts the signature, which provides the hash generated by the sender in step 1
  6. The recipients MUA hashes the body of the e-mail and verifies that the hash matches the received by the sender

To perform a DKIM lookup, its a little bit trickier because you need something called a “selector” in order to perfom the lookup. This can be done by opening an e-mail up from the domain you’d like the DKIM public key for and then finding the “DKIM-Signature” header. Within this header, the selector will defined by the “s=[selector]” key like this:

DKIM Signature Header

Using the example, the selector for the powerdmarc.com domain would be s1.

Using the steps above, I was able to find that Cloudflare has a selector called “google” and perform a DKIM lookup:

dig txt +noall +answer google._domainkey.cloudflare.com

Google DKIM Lookup

Domain-based Message Authentication, Reporting, and Comformance (DMARC)

DMARC builds on top of DKIM and SPF but adds additional control by allowing the owner of a domain to specify how’d they like to respond to unauthenticated emails claiming to originate from their domain. They can do this by defining a subdomain called _dmarc and specifying a TXT record that defines the action they like to take when an e-mail fails DKIM and SPF. These are the 3 actions supported by DMARC:

  1. none: the recipients MUA allows the e-mail to go through even if the e-mail fails authentication
  2. quarantine: the recipients MUA sends the e-mail to a specific folder, i.e. spam folder, if the DMARC check fails
  3. reject: the recipients MUA denies the e-mail completely if the check DMARC fails

Here is Google’s DMARC policy:

dig txt +noall +answer _dmarc.google.com

Google DMARC Lookup

As we can see, Google’s DMARC policy tells e-mail recipients to reject all e-mail that fail their DMARC checks.


Hopefully, you’ve learned something from this and now know more about the underlying components and processes that help you deliver those extremely important e-mails to your colleagues and friends in a secure manner.

If you enjoyed reading this blog and learned something, keep an eye out for more of my posts and maybe consider following me on GitHub, where I work on cybersecurity projects. And if you are feeling really generous, consider buying me a coffee!


comments powered by Disqus