The parts of an email system

Email is not one protocol connecting two inboxes. It is a chain of specialized programs.

A mail user agent (MUA) is the app where you write and read mail. A mail submission agent (MSA) accepts outgoing mail from that app. Mail transfer agents (MTAs) relay it between domains. A mail delivery agent (MDA) places it in the recipient’s mailbox.

The recipient then uses an access protocol such as IMAP or POP3, or a web application, to read the stored message. Learning the roles first prevents a common mistake: expecting one protocol to do every job.

Follow the ownership of one message:

flowchart LR
  accTitle: The parts of an email system
  accDescr: A mail user agent submits a message to an MSA, two MTAs relay it, an MDA delivers it to the message store, and the recipient reads it with another MUA.
  Sender["Sender MUA"] --> MSA
  MSA --> Sending["Sending MTA"]
  Sending --> Receiving["Receiving MTA"]
  Receiving --> MDA
  MDA --> Store["Message store"]
  Store --> Recipient["Recipient MUA"]

Each arrow is a boundary where the message can be accepted, rejected, queued, or changed. A 250 from the MSA means the submission system accepted responsibility. It does not prove the receiving mailbox has the message.

The same product can implement several roles. A provider may run submission, relay, filtering, delivery, and storage behind one hostname. Keep the roles separate in your mental model even when the deployment combines them.

Draw the path for one message you send. Mark who owns the message after every successful handoff and where you would look for evidence if delivery stops.