Published March 7 2018

Standards from the Internet Engineering Task Force (IETF) define email and related email functionality or data. They can be confusing to navigate, and it is often not clear which standards are widely implemented or not.  This page organizes email-related IETF documents into “families.” 


Before diving into these standards, it is important to keep a few things in mind:

  • IETF working documents are classified as ‘informational,’ ‘draft,’ ‘proposed standard,’ and ‘standard’.  documents pass through the first three stages as a request for comment (RFC) documents, sometimes ending as a formal standard. Since the RFC’s are explicitly defined as technical and organizational notes about how the internet operates. Since the IETF operates as a consensus-based organization, even RFCs that are in informational or draft stage frequently contain information that is a normative description of how the internet operates.  RFCs that are further along in the process have undergone more stringent review and are thus accorded increased authority and normative value. 
  • RFC documents frequently replace earlier RFC’s.  Numbers are not reused, but current RFCs reference those they have replaced or ‘obsoleted’, and vice versa.
  • IETF does not keep statistics or lists of implementation for particular RFC documents.  Some describe a set of technologies that are so common as to have become canonical, such as STMP.  Others describe evolving best practices, such as DMARC and the other authentication technologies.
  • Many standards specify baseline requirements but also allow for  extensions, such as the Message Submissions for mail.  The extensions may be  propreitary or non-proprietary, open or closed.

Simple Mail Transfer Protocol

STD 10 (Alternate, easier-to-use version) defines the Simple Mail Transfer Protocol or SMTP.  SMTP defines the method by which messages are transmitted, sent, and received, and it might be considered the base standard upon which the others depend.

STD 10 combines and obsoletes the following RFC’s:

  • RFC 5321 Simple Mail Transfer Protocol – The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFCs  821, 788, 780, and 772.
  • RFC 974 Mail routing and the domain system – This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing.
  • RFC 1869 SMTP Service Extensions – This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]
  • RFC 1870: SMTP Service Extension for Message Size Declaration – This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client’s estimate of the message size. [STANDARDS-TRACK]

Proposed Standards:

  • RFC 2821 Simple Mail Transfer Protocol – this RFC updates and obsoletes three of the Standard RFCs contained in STD 10: RFC 821, 974 and 1869
  • RFC 7504 SMTP 521 and 556 Reply Codes – This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate that an Internet host does not accept incoming mail at all. This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.
  • RFC 7505 A “Null MX” No Service Resource Record for Domains That Accept No Mail – The No Service MX RR, informally called “null MX”, formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.

Draft Standards:

  • RFC 5321 Simple Mail Transfer Protocol – this RFC obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC 1123 (replacing the mail transport materials of RFC 1123). This RFC updates and clarifies the standards set out in those earlier RFCs but does not add material functionality.
  • RFC 3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) – This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.

Other Core Email Standards:

Security Standards

  • Domain Keys Identified Mail – STD 76 / RFC 6376
  • Sender Policy Framework (SPF) – RFC 7208
  • Domain-based Message Authentication, Reporting and Conformance (DMARC) – RFC 7489

Other Standards

  • SIEVE: An Email Filtering Language (RFCs 5228 and several extension RFCs)