Every email RFC a developer actually needs to know

Email runs on roughly three dozen active IETF standards, and most guides only cover the three or four that showed up in whatever problem the author happened to be debugging. This page catalogs the standards a developer runs into around email, independent of what any single sending platform implements.

Entries with a dedicated guide link to it. Everything else stays a short, factual definition, naming the concrete header or DNS record the standard produces, so you know what to search for the moment you need it.

Core protocol and message format

The wire format and delivery mechanics every email relies on, independent of any authentication or security layer on top.

• RFC 5321 (SMTP): defines the protocol that carries mail between servers, including the HELO/EHLO, MAIL FROM, RCPT TO, and DATA command sequence. Read the full guide →
• RFC 5322 (Internet Message Format): defines the syntax of the message itself, the From, To, Date, and Subject headers plus the header/body structure every email follows. Read the full guide →
• RFC 6409 (message submission): defines the submission protocol a client uses to hand a message to its outgoing server, typically over port 587, distinct from server-to-server relay on port 25. Read the full guide →
• RFC 2045-2049 (MIME): defines how a message carries more than plain text, the Content-Type header and multipart body structure behind every attachment and HTML email. Read the full guide →
• RFC 2183 (Content-Disposition): defines the header that tells a mail client whether to render a MIME part inline or offer it as an attachment. Covered as part of the MIME guide above.

Authentication

These standards let a receiving server verify who actually sent a message, and what to do when that verification fails.

• RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC): the three standards that let a receiving server verify who sent a message and enforce a policy when verification fails. Read the full guide →
• RFC 8617 (ARC): lets an intermediary, a mailing list or forwarder, record and sign the authentication results it saw, so a message that fails SPF or DKIM after a forward can still be trusted. Read the full guide →
• RFC 8601 (Authentication-Results header): defines the header format receiving servers use to record SPF, DKIM, and DMARC verdicts on an incoming message.
• RFC 8463 (DKIM Ed25519-SHA256): adds a faster elliptic-curve signing algorithm to DKIM, alongside the original RSA-SHA256.

Transport security

This group protects the connection a message travels over, a separate concern from whether the message itself is authentic.

• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE for SMTP, base RFC 6698): the three standards that protect the connection a message travels over, letting a domain require TLS, report on negotiation failures, and anchor certificate trust in DNSSEC. Read the full guide →
• RFC 3207 (STARTTLS): defines the command that upgrades a plaintext SMTP connection to TLS mid-session, opportunistically and without a way to detect a downgrade on its own.
• RFC 8689 (SMTP Require TLS): defines the REQUIRETLS extension, letting a sender demand TLS for one specific message rather than relying on the receiving domain's general policy.

Delivery status and read receipts

These formats report what happened to a message after it left the sending server, whether it bounced, was delayed, or was read.

• RFC 3461-3464 (Delivery Status Notification): defines the bounce message format a receiving server sends back, including the machine-readable Action field (failed, delayed, delivered, and others).
• RFC 8098 (Message Disposition Notification): defines the read-receipt mechanism, triggered by a Disposition-Notification-To header on the original message.

Subscriber and list headers

A mail client reads these headers to surface list membership and unsubscribe options without parsing the message body.

• RFC 2369 (List-Unsubscribe): defines the header a mail client reads to show a one-click unsubscribe option in its own interface.
• RFC 2919 (List-Id): defines the header that identifies which mailing list a message belongs to, independent of its subject line.
• RFC 8058 (One-Click Unsubscribe): defines the List-Unsubscribe-Post header, which tells a mail client to submit the unsubscribe request as a one-click POST instead of opening a webpage.

Retrieval and mail access

These protocols define how a client reads and manages mail that's already been delivered to a mailbox.

• RFC 1939 (POP3): defines the protocol a client uses to download messages from a mailbox and typically remove them from the server.
• RFC 3501 / RFC 9051 (IMAP4rev1 / IMAP4rev2): define the protocol a client uses to manage messages and folders directly on the server, without downloading and deleting them.
• RFC 8620 / RFC 8621 (JMAP): define a JSON-based alternative to IMAP for mail retrieval and management, designed for modern HTTP-based clients.

Internationalization

These standards extend addresses and headers beyond ASCII, for mailboxes and domains that use other scripts.

• RFC 6530-6533 (email address internationalization): define SMTPUTF8, the extension that lets a mailbox or domain name use non-ASCII characters.
• RFC 6531: defines the SMTP extension that negotiates SMTPUTF8 support between servers during a session.
• RFC 6532: extends MIME to allow UTF-8 header values, so a subject line or display name can use non-ASCII characters.
• RFC 5890-5894 (IDNA): define how a non-ASCII domain name gets encoded into the ASCII-compatible xn-- form DNS actually stores.

Content encryption and misc

End-to-end message encryption, plus a handful of adjacent mechanisms that don't fit the categories above.

• RFC 8551 (S/MIME): defines certificate-based end-to-end message encryption and signing, using the application/pkcs7-mime content type.
• RFC 9580 (OpenPGP): defines a certificate-free alternative to S/MIME for end-to-end message encryption and signing.
• RFC 5228 (Sieve): defines a scripting language for server-side mail filtering, the rules behind most "move to folder" and "forward to" mailbox settings.
• RFC 5965 (ARF, Abuse Reporting Format): defines the structured report format a mailbox provider sends back when a recipient marks a message as spam.
• RFC 3834 (Auto-Submitted header): defines the header that marks a message as automatically generated, so receiving systems can suppress automatic replies to it.