10 Email Protocols You Should Know

The common email protocols: SMTP, POP, IMAP, TLS, MIME, S/MIME, DKIM, SPF, DMARC, and ARC.

Email protocols are a set of standardized rules and procedures used for sending, receiving, and managing email messages. Email protocols allow email clients and servers to communicate with each other in a standardized way, ensuring that email messages are transmitted, stored, and retrieved consistently and reliably across different platforms and networks.

In this article, we list 10 common email protocols that you should know.

SMTP

Simple Mail Transfer Protocol (SMTP) is the primary protocol used for sending email messages between email servers. SMTP defines the format and rules for transferring email messages over the internet.

RFC 772 was published in September 1980 as the first draft of SMTP, which is the mail transfer protocol to replace FTP for email.

The original SMTP protocol supports only unauthenticated unencrypted 7-bit ASCII text communications. It is susceptible to man-in-the-middle attack, spoofing, and spamming. It requiries any binary data to be encoded as readable text before transmission.

SMTP protocol has been updated, modified, and extended multiple times, such as RFC 788. It has the capability to relay mail across transport service environments. The protocol has extensible structure with various extensions for authentication, encryption, binary data transfer, and internationalized email addresses.

SMTP uses port 25 for plain text. SMTP Secure (SMTPS) uses port 587 for encrypted email transmissions. Sometimes, SMTPS also uses port 465.

POP

Post Office Protocol (POP) is an email protocol used for downloading email messages from an email server to an email client. POP allows users to retrieve email messages from a remote server, store them on their local device, and finally delete them from the server.

POP is an application-layer protocol. It has a number of versions:

POP1: POP version 1 is defined in RFC 918, published in October 1984. It suggests a simple method for workstations to dynamically access mail from a mailbox server. This protocol is experimental and depends upon TCP.
POP2: POP version 2 is defined in RFC 937, published in February 1985. This protocol assumes a reliable data stream, provided by TCP or any similar protocol.
POP3: POP version 3 is defined in RFC 1081, published in November 1988. RFC 1939 is an enhancement, published in May 1996. POP3 allows users to retrieve email messages from a remote server, store them on their local device, and finally delete them from the server. It was updated with an extension mechanism (RFC 2449) and an authentication mechanism (RFC 1734).
POP4: It is an informal proposal to add basic folder management, multipart message support, and message flag management. It has not made any progress since 2003.

POP3 is the most commonly used version. Port 110 is the default POP3 port and it is not encrypted. The encrypted port for POP3 is 995 and works over TLS/SSL.

IMAP

Internet Message Access Protocol (IMAP) is an email protocol used for accessing email messages stored on an email server from an email client. IMAP allows users to access their email messages from multiple devices and email clients, while keeping the messages stored on the server. Clients generally leave messages on the server until the user explicitly deletes them.

IMAP is over TCP/IP connection. It has a number of versions:

Original IMAP: It was implemented as a Xerox Lisp Machine client and a TOPS-20 server. The interim protocol does not have command/response tagging, and its syntax is incompatible with all other versions of IMAP.
IMAP2: RFC 1064 was published in July 1988, as the first publicly distributed version of IMAP. RFC 1176 was published in August 1990 as an enhancement. IMAP2 suggests a method for personal computers and workstations to dynamically access mail from a mailbox server.
IMAP3: IMAP version 3 is defined in RFC 1203, published in February 1991. Although it is different from POP2 in many ways, IMAP3 is considered as a functional superset of POP2. However, IMAP3 has never been accepted by the marketplace. The IMAP Working Group has used IMAP2 rather than IMAP3 as its starting point.
IMAP2bis: A draft version of IMAP2bis was published in October 1993 to support MIME body structures, along with adding mailbox management functionality of create, delete, rename, and message upload. It is an experimental draft.
IMAP4: IMAP4 revision 1 is defined in RFC 3501, published in March 2003. It allows a client to access and manipulate electronic mail messages on a server. RFC 9051 was a proposed draft of IMAP4 version 2, published in August 2021. It permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. It provides the capability for an offline client to resynchronize with the server.

An IMAP server typically listens on port 143, and IMAP over SSL/TLS (IMAPS) is assigned port 993.

SMTP is for sending data, and both IMAP and POP are methods to receive emails. IMAP allows users to access their email messages from multiple devices and email clients. All modern e-mail clients and servers support all of them.

TLS

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communication security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

TLS aims to provide security, including privacy (confidentiality), integrity, and authenticity through the use of cryptography. It runs in the presentation layer and is composed of two layers: the TLS record and the TLS handshake protocols.

TLS is a presentation protocol. It has a number of versions:

TLS 1.0: TLS version 1.0 is defined in RFC 2246, published in January 1999. It is an upgrade of Secure Sockets Layer (SSL) version 3.0, which is a standard security technology for establishing an encrypted link between a server and a client. TLS 1.0 provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, and message forgery.
TLS 1.2: TLS version 1.2 is defined in RFC 5246, published in August 2008. The MD5 and SHA-1 combination has been replaced with SHA-256, and it enhances the client’s and server’s ability to specify which hashes and signature algorithms to accept. Later, RFC 6176 was published in March 2011 to remove the backward compatibility with SSL in all TLS versions.
TLS 1.3: TLS version 1.3 is defined in RFC 8446, published in August 2018. TLS 1.3 separates key agreement and authentication algorithms from the cipher suites. It has removed support for MD5 and SHA-224, and it requires digital signatures even when a previous configuration is used. TLS 1.3 is the current version.

Applications can communicate with or without TLS. Therefore, it is necessary for a client to request the server to set up a TLS connection. It can be achieved by using a different port number for TLS connection. For example, unencrypted HTTP uses port 80, but encrypted HTTPS is uses port 443.

MIME

Multipurpose Internet Mail Extensions (MIME) is a protocol used for encoding and decoding email messages with non-textual content, such as audio, video, images, and application programs. MIME enables email clients to send and receive messages with rich content.

The MIME standard is specified in a series of standards: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 and RFC 2049. The integration with SMTP email is specified in RFC 1521 and RFC 1522. Email messages with MIME formatting are typically transmitted with standard protocols, such as SMTP, POP, and IMAP.

Although the MIME formalism was designed mainly for SMTP, its content types are also used in other communication protocols. In the HyperText Transfer Protocol (HTTP) for the World Wide Web, servers insert a MIME header field at the beginning of any Web transmission. Clients use the content type or media type header to select an appropriate application to view the content.

There is a long list of MIME types for application, audio, font, example, image, message, model, multipart, text, and video. Here are some examples:

text/html: HyperText Markup Language (HTML), with extension of .htm or .html.
text/css: Cascading Style Sheets (CSS), with extension of .css.
text/javascript: JavaScript, with extension of .js.
text/plain: Text, with extension of .txt.
text/csv: Comma-Separated Values (CSV), with extension of .csv.
application/json: JavaScript Object Notation (JSON) format, with extension of .json.
application/pdf: Adobe Portable Document Format (PDF), with extension of .pdf.
application/rtf: Rich Text Format (RTF), with extension of .rtf.
image/gif: Graphics Interchange Format (GIF), with extension of .gif.
image/jpeg: Joint Photographic Experts Group (JPEG) image, with extension of .jpeg or .jpg.
image/png: Portable Network Graphics (PNG) image, with extension of .png.
video/mpeg: Moving Picture Experts Group (MPEG) video, with extension of .mpeg.
audio/mpeg: MPEG Layer-3 Audio Encoding (MP3) audio, with extension of .mp3.
audio/wav: Waveform Audio Format, with extension of .wav.
video/mp4: MPEG Layer-4 Video Encoding (MP4) video, with extension of .mp4.
font/woff: Web Open Font Format (WOFF), with extension of .woff.
application/example, audio/example, image/example, message/example, model/example, multipart/example, text/example, video/example: Placeholder for examples.
multipart/encrypted: The encrypted content contains multiple (2) parts: — The control information to decrypt the data in the second part — The encrypted data that is always labeled as application/octet-stream

S/MIME

Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standard for public key encryption and signing of MIME data. S/MIME has been defined in a number of documents, most importantly RFC 3369, RFC 3370, RFC 3850 and RFC 3851.

S/MIME was originally developed by RSA. The original specification uses MIME standard, with the de facto industry standard PKCS#7 secure message format. Change control to S/MIME has since been vested in the IETF and the specification is layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality has been built into the majority of modern email software and interoperation between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

On May 13, 2018, the Electronic Frontier Foundation (EFF) announced critical vulnerabilities in S/MIME, together with an obsolete form of PGP that is still used, in many email clients. The bug, EFAIL, is a security hole in email systems that transmit emails in encrypted form.

DKIM

DomainKeys Identified Mail (DKIM) is an email authentication protocol that adds a digital signature to email messages, which can be verified by the recipient’s email server to confirm that the message was sent by an authorized sender and that the message content has not been tampered with during transmission.

A valid signature also guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed. Usually, DKIM signatures are not visible to end-users. They are affixed or verified by the infrastructure rather than the message’s authors and recipients.

RFC 6376 published DKIM standard in September 2011. It permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author’s organization, an operational relay, or one of their agents. It can detect email spoofing, a technique often used in phishing and email spam.

RFC 8301 was published in January 2018, and it bans SHA-1 and updated key sizes. RFC 8463 was published in September 2018, and it added a new signing algorithm, Ed25519-SHA256, which is adequately strong while featuring short public keys that are more easily publishable in DNS. DKIM verifiers are required to implement this new signing algorithm.

SPF

Sender Policy Framework (SPF) is an email authentication protocol designed to detect forging sender addresses during the delivery of the email.

The existing protocols, such as SMTP, place no restriction on what a sending host can use as the “MAIL FROM” of a message or the domain given on the SMTP HELO/EHLO commands. With SPF, it allows domain owners to specify which IP addresses are authorized to send email on behalf of their domain. SPF enables recipient email servers to verify the sender’s domain name and check whether the message was sent from an authorized IP address, which is published in the DNS records for that domain.

SPF is defined in RFC 7208 , published in April 2014. It helps preventing spammers to use forged email addresses.

Compliance with SPF consists of three loosely related tasks:

Domains and hosts identify the machines authorized to send email on their behalf.
Receivers use ordinary DNS queries to interpret the SPF information as specified and act upon the result.
Plain mail forwarding is not allowed by SPF.

DMARC

Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication protocol. A DMARC policy allows a sender’s domain to indicate whether their email messages are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes — such as to reject the message or quarantine it. The policy can also specify how an email receiver can report back to the sender’s domain about messages that pass and/or fail. These policies are published in the public DNS.

DMARC provides domain owners with visibility into how their domain is being used and provides actionable feedback on how to improve email authentication.

RFC 7489 was published in March 2015 to address DMARC. It empowers email domain owners to protect their domain from email spoofing, phishing email, email scams, and other cyber threat activities.

ARC

Authenticated Received Chain (ARC) is an authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email’s original authentication results.

DMARC allows a sender’s domain to indicate whether their emails are protected by SPF and/or DKIM. When both SPF and DKIM fail, ARC gives intermediate servers a way to sign the original message’s validation results.

ARC is defined in RFC 8617, published in July 2019. The standard is labeled experimental.

Conclusion

We have described 10 most common email protocols. By following email protocols, email communications can be standardized, interoperable, and secure, ensuring that email messages are delivered and managed effectively and efficiently.

Thanks for reading!

Want to Connect?

If you are interested, check out my directory of web development articles.

More content at PlainEnglish.io.

Interested in scaling your software startup? Check out Circuit.