What this RFC defines
RFC 5598 is a conceptual overview of the entire internet mail system. It defines and names the functional roles: the MUA (Mail User Agent, your email client), the MSA (Mail Submission Agent, port 587), the MTA (Mail Transfer Agent, the relay servers), and the MDA (Mail Delivery Agent, which places mail into mailboxes). It is a map, not a protocol specification.
Where you see it in practice
When an email deliverability consultant talks about the MUA-MSA-MTA-MDA chain, they are using the terminology from RFC 5598. When your ESP’s documentation distinguishes between submission (port 587) and relay (port 25), the conceptual separation comes from this RFC. It is the document that gives email infrastructure its shared vocabulary.
How it connects to other RFCs
RFC 5598 is an architectural overview that sits above all the protocol RFCs. It references RFC 5321 (SMTP), RFC 5322 (message format), and the MIME suite as the protocols that implement the architecture it describes. It is informational rather than standards-track, meaning it documents existing practice rather than defining new requirements.
Current status
RFC 5598 is a current informational RFC, published July 2009. It has not been superseded and remains the standard reference for email architecture terminology. Anyone designing or describing an email system should read it to use consistent vocabulary.
The Internet Mail Architecture
RFC 5598 published Dave Crocker Internet Mail Architecture document in July 2009. It is not a protocol standard; it is a taxonomy of the entities that participate in email delivery: MUA (Mail User Agent, the client), MSA (Mail Submission Agent, port 587), MTA (Mail Transfer Agent, relays), MDA (Mail Delivery Agent, final delivery), and MS (Message Store). It also introduces the concepts of author, sender, receiver, and various trust boundaries that shape how policies apply.
Why the vocabulary matters
Reading RFC 5598 clarifies why certain policies apply in certain places. SPF and DKIM are MTA-level authentication checks; DMARC alignment operates on the RFC 5322 From header that the MUA generates; DSN reports go to the return path that the MSA rewrote. Each protocol operates at a specific point in the delivery chain, and confusion about which agent handles which task is a common source of misconfiguration. When troubleshooting, mapping the actual mail flow onto the RFC 5598 vocabulary usually clarifies the problem.
Reading as prerequisite
Many later RFCs implicitly assume familiarity with RFC 5598 vocabulary. When RFC 7489 (DMARC) talks about “receiver” behavior, it means the receiving MTA specifically, not the ultimate MUA. When RFC 6376 (DKIM) talks about “author signing”, it means the domain of the RFC 5322 From header, not the envelope MAIL FROM. If you are diving into modern mail RFCs and finding the terminology dense, RFC 5598 is a short (roughly 60 pages) prerequisite read.
RFC 5598 (July 2009), authored by Dave Crocker, defines the Internet Mail Architecture: the vocabulary and role definitions used across every subsequent email RFC. Introduces terms like MUA (Mail User Agent), MSA (Mail Submission Agent), MTA (Mail Transfer Agent), MDA (Mail Delivery Agent), MRA (Mail Retrieval Agent), and their handoffs. Not a wire protocol; a conceptual map. Essential prerequisite for reading modern authentication, deliverability, and routing RFCs which use this vocabulary throughout.
RFC 5598 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Establish common vocabulary and role definitions for Internet mail |
| Author | Dave Crocker |
| Type | Informational (conceptual framework, not wire protocol) |
| Length | Approximately 60 pages |
| Key concept | Actor and role separation (Author, MUA, MSA, MTA, MDA, MRA, Recipient) |
| Referenced by | Every modern email RFC that discusses paths or actors |
| Published | July 2009 |
The core actors and roles
| Actor | Full name | Role |
|---|---|---|
Author | Author | The person or process that creates a message |
MUA | Mail User Agent | Client software the Author uses (Outlook, Apple Mail, Thunderbird, webmail) |
MSA | Mail Submission Agent | Server that accepts newly authored mail from MUAs (typically port 587) |
MTA | Mail Transfer Agent | Server that relays mail between systems (typically port 25) |
MDA | Mail Delivery Agent | Component that places mail into the recipient’s mailbox (Postfix local, Cyrus deliver, Dovecot deliver) |
MRA | Mail Retrieval Agent | Server that provides access to stored mail (IMAP, POP3) |
Recipient | Recipient | The person or process for whom the message is intended |
Mediator | Mediator | Actor that re-injects mail (mailing list, forwarder, alias expander) |
Standard mail flow through the actors
Mediators: mailing lists, forwarders, aliases
Common confusions around actor vocabulary
Related standards and further reading
- Email Protocols and Ports Guide: submission vs relay ports
- RFC 4409 Submission Guide: MSA in practice
Frequently asked questions
Should I read RFC 5598 before other email RFCs?
If you are diving into modern mail RFCs (authentication, deliverability, ARC), yes. RFC 5598 is a short (60 pages) informational document that establishes vocabulary used throughout. Reading it once means every subsequent RFC references to MSA, MTA, MDA, MRA, Mediator make immediate sense instead of requiring inference from context.
What is the difference between MSA and MTA?
MSA (Mail Submission Agent) is the endpoint MUAs submit new messages to; typically port 587 with SMTP AUTH required. MTA (Mail Transfer Agent) is the relay endpoint that receives from other MTAs; typically port 25. Historically one server handled both; modern operations separate them. Separating provides security (submission requires AUTH; relay applies anti-spam), scaling (different load profiles), and monitoring (different failure modes).
Are Mediators the same as MTAs?
No. An MTA relays a message unchanged (only adding trace headers). A Mediator re-injects the message with modifications: added Subject prefixes, rewritten From, added footers, new List-* headers. Mailing list managers (Mailman, Sympa) are Mediators; simple forwarding aliases can be either MTA or Mediator depending on implementation. The distinction matters because Mediators break DKIM signatures while pure MTAs preserve them.
Where does a webmail interface fit in this architecture?
A webmail interface is a browser-based MUA that also incorporates MRA functionality via the server backend. When you compose in Gmail’s web interface, the interface is the MUA. When it displays your inbox, the backend fulfills the MRA role. The mail-server-side of Gmail combines MSA, MTA, MDA, and MRA into a single platform; the web interface is what you see.
Is RFC 5598 still current?
Yes. RFC 5598 is informational and its terminology has not been superseded. It has been referenced by every subsequent mail architecture and authentication RFC. The vocabulary continues in use unchanged. For deployment specifics of individual roles, consult protocol-specific RFCs (RFC 5321 for MTA, RFC 4409 for MSA, etc.); RFC 5598 remains the architectural map.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
