What this RFC defined
RFC 772 defined the Mail Transfer Protocol in 1980, two years before RFC 821 replaced it with SMTP. It was one of the earliest specifications for transferring electronic mail over ARPANET. RFC 772 established several concepts that influenced SMTP, including the notion of mail relaying and the use of a command-response model for mail transfer between hosts.
Where you would have seen it in practice
RFC 772 is a purely historical document with no practical implementation relevance today. It predates the internet as we know it and was designed for the ARPANET research network. It is included here for completeness and historical context, showing the full evolution of email transfer protocols from 1980 to the present.
How it connects to other RFCs
RFC 772 was obsoleted by RFC 821 (SMTP) in 1982. The lineage is RFC 772 to RFC 821 to RFC 2821 to RFC 5321 (current). RFC 772 influenced the design of RFC 821 but the two protocols are not interoperable. No modern system implements RFC 772.
Current status
RFC 772 was obsoleted by RFC 821 in August 1982. It has no practical relevance to modern email systems and is preserved purely as a historical artifact. It represents the earliest standardised email transfer protocol on the ARPANET predecessor to the modern internet.
Historical significance
RFC 772 was authored by Suzanne Sluizer and Jon Postel in September 1980 and represents the first formal specification of a mail transfer protocol running over TCP/IP. Before RFC 772, ARPANET mail traveled through the NCP-based FTP mail extension. The proposal introduced the store-and-forward transfer model, the concept of a mail relay separate from the sender and receiver, and the notion that mail delivery is best-effort but the transfer itself must be reliable. Every command in modern SMTP (MAIL, RCPT, DATA, QUIT) descends from decisions made in this brief document.
What survived and what changed
The transactional model survived unchanged: connect, negotiate, transfer envelope, transfer data, quit. What changed was almost everything else. RFC 772 assumed a single recipient per session, used verbose command names, and had no notion of extensions. Within a year, RFC 780 refined the ideas, and RFC 788 introduced the term SMTP. By August 1982 RFC 821 had condensed and stabilized the design into what would run production email for almost two decades. Reading RFC 772 today is largely a historical exercise, but it is useful for understanding why RFC 5321 retains certain structural quirks that make no sense in isolation.
When you would reference it
You do not implement anything from RFC 772 in a production system in 2026; RFC 5321 has been the reference for eighteen years. RFC 772 is cited in academic papers on the history of internet mail, in Postel biographies, and occasionally in IETF preambles that trace the lineage of a proposed extension. If you find RFC 772 in a modern requirements document or vendor claim of conformance, that is a red flag: it means whoever wrote the document copied a reference from a very old source without checking.
RFC 772 (September 1980), authored by Suzanne Sluizer and Jonathan Postel, defined the Mail Transfer Protocol (MTP): an early experimental predecessor to SMTP. Introduced key ideas (envelope-vs-content separation, command-response dialogue) that carried into RFC 821 SMTP two years later. Fully obsolete since 1982 and never widely deployed. Historical curiosity only; any modern reference to RFC 772 is a red flag indicating stale documentation. Current SMTP reference is RFC 5321.
RFC 772 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Early experimental mail transfer protocol |
| Authors | Suzanne Sluizer, Jonathan Postel |
| Status | Obsolete (never widely deployed) |
| Introduced | Envelope-vs-content separation, command-response dialogue, forward path concept |
| Direct successor | RFC 780 (also 1981, MTP revision), then RFC 788 (SMTP proposal), then RFC 821 (SMTP, 1982) |
| Modern reference | RFC 5321 |
| Published | September 1980 |
Mail transfer protocol lineage
| RFC | Year | Status |
|---|---|---|
| RFC 772 (MTP) | 1980 | Experimental; obsolete |
| RFC 780 (MTP) | 1981 | Revision; obsolete |
| RFC 788 (SMTP proposal) | 1981 | Draft; obsolete |
| RFC 821 (SMTP) | 1982 | Deployed for 19 years; obsoleted by RFC 2821 |
| RFC 2821 (SMTP) | 2001 | Obsoleted by RFC 5321 |
| RFC 5321 (SMTP) | 2008 | Current |
What survived from RFC 772 to modern SMTP
Common confusions around RFC 772
Related standards and further reading
- RFC 822: Message Format (also 1982)
- RFC 733: Earlier message format (obsoleted by RFC 822)
- RFC 5321 SMTP Guide: current transfer protocol
Frequently asked questions
Is RFC 772 still used anywhere?
No. RFC 772 defined the Mail Transfer Protocol (MTP), an experimental predecessor to SMTP that was superseded by RFC 821 within two years. No production system implements RFC 772 in 2026; any reference to it in current documentation is stale or historical context only.
What is the relationship between RFC 772 and SMTP?
Direct ancestry. RFC 772 introduced concepts (envelope separation, command-response dialogue, forward path routing) that SMTP inherited and refined. RFC 821 SMTP was designed with RFC 772 experience in mind. The current SMTP RFC 5321 is separated from RFC 772 by four decades of refinement, but the core conceptual model traces to that early document.
Why does RFC 772 come up in some old documentation?
Pre-1985 mail infrastructure occasionally cited it as the transfer protocol. Any documentation from that era referring to MTP or RFC 772 predates SMTP’s dominance. Modern documentation should not cite RFC 772; if it does, that document has not been maintained since the early 1980s and its guidance is likely out of date across many other topics.
What are the differences between RFC 772 MTP and RFC 821 SMTP?
Substantial. RFC 821 tightened command semantics, refined the reply code structure, added the DATA end-of-message convention (the single “.” on a line), and generally cleaned up MTP’s rough edges. The high-level model is similar; the details are much more precise in RFC 821. Modern SMTP (RFC 5321) has evolved further with ESMTP extensions, STARTTLS, and authentication, all layered on the RFC 821 foundation.
Should I know RFC 772 to work with modern email?
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.
