MUA vs MTA vs MDA vs MSA: Email's Four Server Roles

The MUA vs MTA vs MDA difference comes down to one thing: these are not rival products you pick between. They are four jobs in the relay that carries a single email from your keyboard to someone else's inbox, plus a fourth actor — the MSA — that most short explanations leave out. Each is named and defined in RFC 5598, the IETF document that describes how internet mail is actually built.

This post maps each role to the software that plays it in real life — the mail client you read in, the submission service that accepts what you send, the transfer agents that relay it, and the delivery agent that writes it into a mailbox. Get this mental model right once and every other email-plumbing term, from MX records to SMTP ports, stops being a jumble of acronyms.

The four roles, in one line each#

These four actors are a relay team, not a contest. A message is handed from one to the next, and each takes responsibility for its own leg of the trip. RFC 5598, titled 'Internet Mail Architecture', is where the names and boundaries come from.

• MUA (Message User Agent) — the program you read and write mail in. It composes your message and hands it off, and it displays mail that arrives for you.
• MSA (Mail Submission Agent) — the first server that accepts your outbound message, checks who you are, and enforces your provider's rules before the message enters the transfer network.
• MTA (Message Transfer Agent) — a relay that moves the message server to server, one 'hop' at a time, toward the recipient's domain.
• MDA (Mail Delivery Agent) — the final hand-off that files the message into the recipient's mailbox, where their own MUA can fetch it.

MUA vs MTA vs MDA vs MSA at a glance#

The table below pairs each role with the exact name and section RFC 5598 gives it, and with software you may already recognise. One quirk worth flagging up front: the RFC itself writes 'Message' for the MUA and MTA but 'Mail' for the MSA and MDA. Both wordings circulate in the wild, and the acronyms are what people actually use.

How an email moves from your client to a mailbox#

Here is the same journey as a sequence. Each step is one hand-off, and the message is never in two places at once — this is the 'store and forward' model email has used since the start.

1. 1

   You hit Send in your MUA

   Your mail client — the Message User Agent — finishes the message and opens a connection to your provider's submission service. In RFC 5598 terms this is the author MUA, or aMUA.

2. 2

   The MSA accepts and checks it

   The Mail Submission Agent authenticates you, may add or repair headers, and enforces your provider's policy. Only after it accepts responsibility does the message enter the transfer network.

3. 3

   MTAs relay it hop by hop

   One or more Message Transfer Agents look up the recipient domain's MX record in DNS, open an SMTP connection to the next server, and pass the message along until it reaches the receiving side.

4. 4

   The MDA files it into the mailbox

   The final MTA hands off to the Mail Delivery Agent, which writes the message into the recipient's mailbox — the Message Store, RFC 5598 section 4.2.2 — applying any delivery-time filtering along the way.

5. 5

   The recipient's MUA fetches it

   The recipient opens their own client, the recipient MUA (rMUA). It retrieves the message from the store over IMAP or POP and displays it. The relay is done.

The MUA: the program you actually read mail in#

The Message User Agent is the only one of the four you normally see. It is your email app — Apple Mail, Outlook, Thunderbird, Gmail's web interface, a phone mail app, or an AI-native client. RFC 5598 section 4.2.1 says the MUA 'works on behalf of User Actors and User applications'. In plain terms, it acts for you.

The standard splits the role in two by direction. The author MUA (aMUA) is the sending side: it composes your message and submits it. The recipient MUA (rMUA) is the reading side: it pulls delivered mail from the store and shows it to you, and it is where you write replies. The same app usually plays both parts.

A key boundary: the MUA does not relay mail across the internet. It hands outbound messages to a submission server and reads incoming ones from a mailbox store. Everything between those two points is the job of the agents below — which is exactly why a client can look broken when the real fault is a server you never see.

The MSA: what accepts your outbound message#

MSA stands for Mail Submission Agent. RFC 5598 section 4.3.1 says it 'accepts the message submitted by the aMUA and enforces the policies of the hosting' provider. It is the doorway between your client and the wider transfer network, and it is the piece most four-letter summaries drop.

Submission is deliberately kept separate from relay. Your client authenticates to the MSA — a login, not an anonymous connection — so the provider knows the message is really yours before it accepts responsibility for it. The MSA can also tidy the message: filling in a missing Date header, rewriting a From address to an approved one, or rejecting mail that breaks policy.

The MTA: the relay between mail servers#

The Message Transfer Agent does the long-haul work. RFC 5598 section 4.3.2 says an MTA 'relays mail for one application-level hop' — it accepts a message, works out where the next server is, and passes it on. A message often crosses several MTAs before it arrives.

MTAs speak SMTP, the Simple Mail Transfer Protocol defined in RFC 5321. That standard describes relay systems as ones that 'receive and transmit mail to other servers without modifying message data except for adding trace information' — which is why each hop stamps a Received header but leaves your words alone.

Is Postfix an MTA or an MDA? Postfix is an MTA — so are Exim, Sendmail, and Microsoft Exchange's transport service. On a small server a single package can wear more than one hat: Postfix can also listen as an MSA for submission and ship a local delivery component. But its core job is transfer, and busy setups usually hand final delivery to a dedicated MDA.

The MDA: what files it into the mailbox#

The Mail Delivery Agent handles the last step. RFC 5598 section 4.3.3 frames it as a change of custody: 'a transfer of responsibility from the' transfer network 'to a Recipient's environment (mailbox) is called delivery'. The MDA is the software that performs that write.

Delivery is where per-recipient rules run. The MDA can sort into folders, apply Sieve filters, forward, or reject before the message ever lands. Common delivery agents include Dovecot's LMTP and LDA, procmail, and maildrop; on some servers the MTA's own local transport does the job.

After delivery the message sits in the Message Store — RFC 5598 section 4.2.2 — the mailbox the recipient's MUA reads from over IMAP or POP. The MDA writes; the recipient's client reads. That clean split is why one server can relay mail (MTA) while a different one holds and serves the mailboxes (store), even inside the same provider.

Which of these do you actually choose?#

For almost everyone, the answer is short: only the MUA. Sign up with Gmail, Microsoft 365, Fastmail, or a hosting provider, and that provider runs the MSA, the MTAs, the MDA, and the Message Store for you. You never configure them by name, and you rarely pay for them as separate items.

If you self-host, you assemble the roles yourself, and the software is typically open-source — Postfix or Exim for transfer, Dovecot for delivery and the store. Either way, the one piece you pick, switch, and sometimes pay for is the client. That is the part of the stack where products genuinely compete, so it is worth choosing on purpose.

If you are weighing a paid mail client, check the vendor's own pricing page at the time you buy — this category reprices often, and any figure printed in an article ages within weeks.

Where AI Emaily fits in this picture#

We build AI Emaily, so this is the disclosure and the placement in one place. In RFC 5598 terms, AI Emaily is an MUA — a Message User Agent. It is the app you read and write mail in, not a mail server.

That boundary matters. When you connect a Gmail, Outlook, or IMAP account, those providers keep running the submission, transfer, and delivery. AI Emaily talks to them the way any client does: it fetches from the Message Store over your provider's connection and hands outbound mail to your provider's MSA. It does not replace the MSA, the MTAs, or the MDA, and it does not touch your MX records.

What it adds on top of the plain MUA role is where the product lives: it unifies Gmail, Outlook, and standard IMAP in one inbox, and layers an AI agent that triages and drafts. The agent runs in modes — Copilot requires your approval before anything sends; Autopilot acts within gates, with undo and a readable audit log. Its writing voice comes from a Personal Context brain and per-client profiles you set, not from scanning your archive, and your mail is not used to train models.

Where it is the wrong tool: if your problem is a mail server — self-hosting an MTA, debugging delivery at the MDA, or tuning deliverability — that is infrastructure work AI Emaily does not do, and there is no Linux desktop build. Packaging is a 7-day free trial on the Pro and Autopilot plans, card required and $0 if you cancel before day 7, not a permanent free tier. See the current tiers at aiemaily.com/pricing, start from the homepage at aiemaily.com, and the connect-mailbox guide covers linking an account.

Which role failed when mail breaks#

The four-role model earns its keep at the worst moment: when something does not arrive. The symptom usually points at one agent, which tells you where to look instead of blaming the whole system.