RFC 5598 — Internet Mail Architecture

The vocabulary of email: MUA/MSA/MTA/MDA, ADMDs, actor roles, mediators vs. relays, and which actor sets which identity field.

Foundational6 min read

Who it is for ESP operators, Senders

Applies to senders on any platform

To diagnose a delivery problem, or to follow a discussion about one, you need exact names for the parts of the mail system. Statements such as "the MSA should add that header" or "forwarding breaks SPF because the mediator is a new originator" only make sense with these terms.

RFC 5598 is the specification that defines them. It names the components, actors and administrative boundaries that the transport specification (RFC 5321) and the format specification (RFC 5322) assume.

Two worlds

MUA world (users): where messages are created and read.
MHS (Message Handling Service): the store-and-forward network that accepts a message from an Author and delivers it to Recipients. The architecture has three store-and-forward layers: User Mediators at the top, MHS Relays in the middle, and packet switches at the bottom.

Actor roles (who is responsible)

Role	Responsibility
Author	Creates the content and the recipient list
Originator	Checks the message against standards and local policy, then submits it, and handles the duties that follow submission. It has "dual allegiance": it works for the Author but enforces the rules of its ADMD
Relay	Routes, stores and forwards within the MHS, and adds trace information. It MUST NOT change envelope addresses or the meaning of the message
Gateway	A hybrid of User and Relay that connects different kinds of mail service. It may translate content but must preserve the dialogue between Author and Recipient
Receiver	Performs final delivery (or redirects the message). It may enforce policy immediately before or after delivery, which is where decisions to deliver to the inbox, file as spam or reject are made
Recipient	Reads the message, and may reply or send message disposition notifications (MDNs)
Return Handler (Bounce Handler)	A special recipient of the notifications the MHS generates (DSNs), reached through the return address the Originator supplied

Functional components

Component	Full name	Function	Key facts
MUA	Message User Agent	The mail client of the Author (aMUA) or of the Recipient (rMUA)	The aMUA creates and submits. The rMUA displays, replies and files
MSA	Message Submission Agent	Accepts submission from the aMUA, and enforces ADMD policy and conformance to standards	Port 587 (SUBMISSION, RFC 4409 and 6409), authenticated, compared with port 25 for relay. Split into the aMSA (acts for the Author, and may add `Date:` and `Message-ID:` or fix headers) and the hMSA (acts for the MHS and takes responsibility)
MTA	Message Transfer Agent	Relays the message one application-level hop over SMTP	Adds `Received:`. Does not change envelope addresses or editorial content (it may re-encode the MIME Content-Transfer-Encoding, CTE). Variants: Boundary (or Border) MTA, which crosses ADMDs, and Outbound, Inbound and Final MTAs
MDA	Message Delivery Agent	Transfers responsibility from the MHS to the Recipient's environment	Split into the hMDA (facing SMTP) and the rMDA (applies actions at delivery time, for example filtering into folders). Writes `Return-Path:`
MS	Message Store	Where messages rest	aMS (drafts, queue and sent mail) and rMS (received mail, accessed over IMAP or POP)

The standard flow runs from the aMUA to the MSA, through one or more MTAs, to the MDA, the rMS and finally the rMUA.

ADMD: Administrative Management Domain

An ADMD is a boundary of independent administrative authority. Inside it, one operator's policies apply for authentication, filtering, accountability and content handling. Everything that matters in deliverability happens at the boundaries between ADMDs, because that is where parties with no shared control must establish trust. This is what SPF, DKIM and DMARC authenticate: the sending ADMD to the receiving ADMD.

There are three types. Edge ADMDs are organizations at the periphery that run their own mail. Consumer ADMDs are mailbox providers that serve end users, typically through web or IMAP access. Transit ADMDs are mail service providers and ESPs that relay mail and add value between Edge ADMDs. Edge ADMDs may exchange mail directly with each other. Transit ADMDs aggregate and filter mail, and take on responsibility for the reputation of their customers' mail.

Mediators vs. relays: why forwarding is special

A Relay moves the same message along. Responsibility and the envelope do not change.

A Mediator receives a delivered message and posts it again. That creates a new transit through the MHS and a new responsibility, and the content may change, while the original Author's From: is preserved. Mediators sit between full relaying and full authorship, and they cause most of the edge cases in authentication. SPF breaks because the mediator's IP address is not in the SPF record of the Author's domain, and DKIM may break if the content changes.

Mediator type	What it does	Identity effects
Alias	Sends the message on to one or more new addresses. The message continues through the transfer service	Keeps the original `MailFrom` (return path), so bounces go to the original Originator. Only `RcptTo` changes. This is classic forwarding in the style of ".forward"
ReSender (ReDirector)	Inserts a new Recipient into the original exchange	Keeps `From:`, adds `Resent-From:` (the mediator as author) and `Resent-Sender:`, and typically uses a new `MailFrom`
Mailing List	Collects postings and redistributes them to members	A new `MailFrom` (the list's bounce address). Adds `List-Id:` (RFC 2919) and other list headers. Often modifies the subject or adds a footer, which breaks DKIM
Gateway	Translates between different kinds of mail service	May rewrite content and addressing as needed, but must keep replies working
Boundary Filter	A filter for abuse or policy at the edge of an ADMD, which may modify or quarantine messages	Acts as both a receiver and a re-injector

What this means for deliverability: a forwarder of the Alias type that preserves MailFrom breaks SPF at the next hop, unless it rewrites the sender (for example with SRS). A Mailing List that takes ownership of MailFrom passes SPF for its own domain, but it must not break alignment for the Author's domain. That need is the practical reason for ARC and for practices that preserve DKIM signatures.

Identity fields: who sets what

Identity	Set by	Meaning
`RFC5321.HELO/EHLO`	SMTP client (MSA or MTA)	The host announcing itself for this hop
`RFC5321.MailFrom`	Originator	The return address for notifications at the transfer level. It need not be the Author
`RFC5321.RcptTo`	Author (or the Final MTA or MDA on redirect)	The envelope recipient, which may never appear in the headers
`RFC5322.From`	Author	Who wrote the message (the DMARC identifier)
`RFC5322.Sender`	Originator	Who submitted it. If it is absent, the `From:` mailbox is treated as the sender
`RFC5322.Reply-To`	Author	Where replies should go
`RFC5322.To/Cc/Bcc`	Author	The displayed recipients (Bcc recipients are not disclosed)
`RFC5321.Received`	Each relay, mediator or receiver	A trace of hosts and IP addresses
`RFC5321.Return-Path`	MDA	Records the `MailFrom` at delivery
`RFC3461.ENVID`	Originator	An opaque tracking ID for one transit from posting to delivery (used to match DSNs)
`RFC5321.ORCPT`	Originator	The original recipient address, which survives remapping. It is the only reliable way to match a DSN to a recipient
`RFC2919.List-Id`	Mediator (list)	A globally unique list name that does not depend on any host

Three separate identities look like "the sender": MailFrom, From: and Sender:. Two different roles set them, and that is exactly why email authentication needed the concept of alignment (DMARC).

Ports and protocols quick reference

Port / protocol	Use
25 / SMTP	Relay from MTA to MTA across ADMDs
587 / SUBMISSION	Submission from the aMUA to the MSA, authenticated (submission over implicit TLS on port 465 was added later, by RFC 8314)
IMAP / POP	Access from the rMUA to the Message Store
LMTP	Delivery from the MHS to the MDA without queuing
ETRN / ODMR	Transfer from the MHS on request ("on-demand"), pulled by the receiving side

RFC 5321: SMTP, the relay protocol these components use
RFC 5322: Message Format, the header fields each actor sets
Foundations of Email Deliverability, on how receiving ADMDs decide placement

Check your own record

The free check reads what your domain publishes in DNS.

In this topic

All 8 in RFCs →