RFC 5598 – Internet Mail Architecture

Informational Core SMTP & Message Format Published July 2009

ELI5: Think of email like a package delivery system. There’s the person who writes the letter (author), the local post office that accepts it (submission), the sorting facilities that route it across the country (relay), and the local post office at the destination that puts it in your mailbox (delivery). RFC 5598 names every player and process in this system so that when other RFCs talk about “the MTA” or “the MSA,” everyone means the same thing.

Why This RFC Exists

Before RFC 5598, the email community used terms like "MTA," "relay," and "gateway" loosely and inconsistently. Different RFCs used different terminology for the same concepts. This created real confusion, especially as authentication mechanisms like SPF, DKIM, and DMARC needed precise definitions of who was doing what in the message path.

Published in 2009 by Dave Crocker, RFC 5598 provides a comprehensive architectural model for internet email. It's not a protocol specification — it doesn't define any new wire formats or commands. Instead, it's a reference framework that names and defines every actor, role, and function in the email ecosystem. Nearly every modern email RFC references 5598's terminology.

How It Works

RFC 5598 breaks the email system into distinct functional components organized around the message's journey from author to recipient.

The Four Main Environments

The architecture defines four operational environments through which a message passes:

Mail User Agent (MUA) environment: Where the user composes and reads messages. Your email client — Gmail, Outlook, Thunderbird, or your app calling an API.
Mail Submission Agent (MSA) environment: The service that accepts messages from an MUA for delivery into the mail system. Operates on port 587 per RFC 6409, requires authentication.
Mail Transfer Agent (MTA) environment: The core routing infrastructure. MTAs relay messages across the internet using SMTP (RFC 5321) on port 25.
Mail Delivery Agent (MDA) environment: The final system that places the message into the recipient's mailbox, making it available via IMAP, POP3, or webmail.

The Message Flow

# The lifecycle of an email message Author (MUA) --compose--> MSA --submit--> MTA --relay--> MTA --deliver--> MDA --store--> Recipient (MUA) # | | | | | # Composes msg Authenticates, Routes via Routes via Stores in # with headers validates, DNS MX DNS MX mailbox # applies policy lookup lookup

Key Actors and Roles

Actor	Abbreviation	Role
Mail User Agent	MUA	Composes and displays messages for the user. The email client.
Mail Submission Agent	MSA	Accepts messages from authenticated MUAs, enforces policy, and injects them into the MTA infrastructure.
Mail Transfer Agent	MTA	Routes and relays messages between domains using SMTP. The "backbone" of email.
Mail Delivery Agent	MDA	Final delivery into the recipient's mailbox. May apply filtering rules.
Mail Store	MS	Stores messages and provides access via IMAP/POP3/JMAP.

Identity Types

RFC 5598 carefully distinguishes the different identities associated with a message:

Identity	Where It Appears	What It Means
Author	`From:` header	The person or entity who wrote the message
Sender	`Sender:` header	The agent that actually transmitted the message (when different from author)
Return-Path	`MAIL FROM` envelope / `Return-Path:` header	Where bounces should be sent; the responsible party for the transport
Recipient	`RCPT TO` envelope / `To:`/`Cc:` headers	The intended recipients

This distinction matters enormously for authentication. SPF validates the Return-Path identity. DKIM can sign on behalf of the Author or an intermediary. DMARC aligns the Author identity with SPF and DKIM results.

Key Technical Details

Mediators

RFC 5598 identifies a crucial category of actors called mediators — entities that receive a message and then re-post it, potentially modifying it along the way:

Mailing List: Receives a message, adds list headers, possibly modifies the subject or body, and redistributes to subscribers. The list becomes the new MAIL FROM sender.
Gateway: Converts between email and another messaging system (e.g., email-to-SMS, email-to-fax).
Resender/Redistributor: Forwards or redistributes mail, such as alumni forwarding addresses.

Mediators are the primary reason email authentication is complex. When a mailing list changes the envelope sender and modifies the message, SPF breaks (new sender IP isn't authorized for the original domain) and DKIM may break (body was modified). This is exactly the problem ARC (RFC 8617) was designed to solve.

ADMD: Administrative Management Domain

RFC 5598 introduces the concept of an ADMD — the administrative boundary of a mail operation. An ADMD is an organization that operates one or more mail services under a single administrative authority. Examples:

A company running its own Exchange server is one ADMD.
Gmail/Google Workspace is one ADMD.
A transactional email service like MailerToGo is one ADMD.

Messages cross ADMD boundaries when they leave one organization's mail infrastructure and enter another's. Authentication and trust decisions happen at these boundaries.

Envelope vs. Content

The architecture formalizes the two layers of every email message:

Envelope: The SMTP-level information (MAIL FROM, RCPT TO) used for routing. Created during submission and modified at each hop.
Content: The message headers and body as defined by RFC 5322. Intended to be immutable after composition, though mediators may modify it.

Common Mistakes

Conflating MTA and MSA. The MSA (port 587, authenticated) and the MTA (port 25, server-to-server) serve different purposes. Sending application email directly to a remote MTA on port 25 — bypassing an MSA — skips authentication and policy enforcement. Most cloud providers block outbound port 25 for this reason.
Ignoring the mediator problem. If you enforce strict DMARC (p=reject) without considering that your messages may pass through mailing lists, those forwarded messages will be rejected at the destination. Understanding the mediator concept helps you plan for this.
Treating From: as the sender. The From: header identifies the author, not the transport sender. SPF checks the envelope sender, not the From header. This distinction is the entire basis for DMARC alignment.
Assuming a flat topology. Messages don't always go directly from sender to receiver. They may pass through multiple MTAs, mailing lists, forwarding services, and gateways. Each hop can modify the envelope and potentially the content.
Not understanding ADMD boundaries. When you delegate sending to an email service, the message crosses an ADMD boundary. SPF, DKIM, and DMARC must be configured to account for this delegation.

Deliverability Impact

Proper submission architecture. Using an MSA (port 587 with authentication) rather than injecting directly into an MTA ensures your messages are properly authenticated and policy-compliant from the start. Services like MailerToGo act as your MSA.
Authentication alignment. Understanding which identity each authentication mechanism checks — SPF checks Return-Path, DKIM signs on behalf of a domain, DMARC aligns these with the From header — requires understanding RFC 5598's identity model.
Forwarding and list handling. If your recipients use forwarding services or mailing lists (mediators), your messages may fail authentication at the final destination. Understanding the mediator role helps you diagnose "why did my DMARC-passing message get rejected?"
Bounce processing. The architecture distinguishes between the author (From header) and the return-path (MAIL FROM). Bounces go to the return-path. If you set up your return-path correctly, you can process bounces automatically without confusing them with replies to the author.