RFC 5322: The Technical Side of Email Marketing

RFC 5322 stands for Request for Comments 5322, an Internet standard that defines the correct format for email messages. It essentially acts as the rulebook for how email messages are structured.

With the new spam updates from Gmail and Yahoo rolling out this year, ensuring correct email syntax and structure becomes critical; this is why email marketers need to be up to date on the role played by RFC number 5322.

Join us as we demystify this term and cover a bit of Internet history before we share how you can be RFC 5322-compliant!

---

---

What are RFC Documents?

RFC documents are a series of publications issued by the Internet Engineering Task Force (IETF) and other related organizations. It is the primary means by which standards and protocols are defined and communicated within the IETF community. 

RFC docs serve as a foundation for the Internet’s architecture and operation, providing a common framework for the development and collaboration of Internet technologies and protocols. 

This table covers a few important characteristics of RFC docs:

Aspect	What it means
Development	RFCs are developed and maintained by various experts who are part of the Internet Engineering Task Force community.
Standardization	RFCs define various standards, protocols, procedures, and concepts related to Internet technologies such as networking, email, and security.
Open for all	Experts worldwide can provide feedback on proposed standards and protocols to ensure their technical soundness and practicality.
Helps track evolution of Internet technologies	RFCs can be updated, revised, or obsoleted as technology evolves and new requirements emerge, reflecting changes in standards, technology, and best practices.
Numbering scheme	Each RFC is assigned a unique number for identification/reference purposes, following a sequential numbering scheme.

It’s interesting to see what a huge impact RFC documents have on such a critical part of our lives — the World Wide Web.

---

RFC Documents: What Makes Them Unique?

RFC documents are truly special — they are the result of a remarkable collaboration between countless individuals pooling their wisdom and expertise toward shared objectives. These documents promote the exchange of information and knowledge, the sharing of research findings, idea proposals, and the implementation of best practices relevant to Internet technologies.

These documents cover a wide scope of topics, from core internet protocols like TCP/IP to application-specific technology such as email formats (this is where RFC 5322 comes in) and security protocols like TLS (or SSL, as it is commonly known).

Now we’re ready to discover what document number 5322 is all about!

---

So, What is RFC 5322?

RFC 5322 stands for Request for Comments 5322 — an Internet standard that states a uniform format for email messages. It lays out rules for how email messages should be structured, including address formats, message headers, message body, and attachments.

In simple words, it is a specification that defines the format of email messages on the Internet.

History and Relevance of RFC 5322

RFC 5322’s history is closely tied to the evolution of email standards and the need for a comprehensive specification to govern email communication.

RFC 5322 represents a significant milestone in the history of email standards, building upon earlier specifications like RFC 822 and RFC 2822.

---

Why Email Marketers Should Care About RFC 5322

While email marketers don’t need to be technical experts on 5322, understanding its basic principles is essential.

That said, most reputable email marketing platforms handle 5322 compliance automatically. While in-depth knowledge may not be necessary for everyday tasks, understanding its role can be valuable for email marketers seeking a deeper understanding of the technology that drives email communications.

For example, 5322 dictates the syntax of email addresses and email structure, as well — let’s see how.

---

RFC 5322 and Email Validation

Email validation is the process of verifying whether the syntax of an email address is correct according to the rules outlined in 5322. These rules include specifications for the format of the email address, such as the characters allowed, the presence of an “@” symbol, and the structure of the domain part.

Note: 5322 only provides guidelines for the structure of email addresses; it doesn’t cover the actual validity of email addresses on your list, so there’s no way of knowing if an email address corresponds to a real user or domain. That level of validation typically involves additional steps such as DNS lookups or sending verification emails.

Here are the rules for different elements in an email address according to 5322:

Element	Description
Local part	Consists of letters, digits, and certain special characters; cannot begin or end with a period.
Domain part	Specifies the domain where the email is hosted; follows domain naming conventions.
Domain structure	The domain part should follow domain naming conventions and have the correct hierarchical structure (e.g., top-level domain or second-level domain).
Quotes	Allows the use of special characters or spaces.
Special characters	Certain characters, such as  “.”, “@”, and special characters within quoted strings have specific roles.

Did you know there is no minimum length requirement for email addresses? There is an upper limit, though; the combination of local and domain parts cannot exceed 320 characters.

Adhering to 5322 guidelines helps ensure that email addresses are at least properly formatted according to established standards.

Benefits of RFC 5322-Based Validation

RFC 5322 provides the blueprint for what a correct email address looks like.

Now that we know the role played by 5322 in email address syntax, the next section explains how it also dictates the structure of email messages.

---

RFC 5322 Rules for Email Structure

5322 provides detailed specifications regarding the structure of email messages.

Header Fields

Email messages consist of header fields and an optional message body. 5322 defines various header fields that can be included in an email message. 

These header fields provide essential information about the message, such as sender, recipient, subject line, date, and additional metadata. 

Commonly used header fields include:

Header Field	Description
From	Specifies the email address of the sender.
To	Specifies the email address of the primary recipient.
Subject	Contains a brief description or summary of the message content.
Date	Indicates the date and time when the message was composed.
CC (Carbon Copy)	Used to send copies of the message to additional recipients.
BCC (Blind Carbon Copy)	Used to send copies of the message to additional recipients without other recipients knowing.

Header Syntax

RFC 5322 defines the syntax rules for constructing header field names and values. Header field names are case-insensitive and must consist of printable ASCII characters. Header field values may contain various types of data, including text, dates, email addresses, and structured data formats such as Multipurpose Internet Mail Extensions (MIME) parameters.

If multiple fields convey the same information, only the most recent one is considered valid.

Email Message Body

The message body contains the actual content of the email message. It follows after the header fields, separated by a single empty line.

5322 does not impose strict guidelines on the structure or content of the message body. It supports the use of MIME to encode and transmit multimedia content, such as images, audio, and video, within email messages. 

Line Length and Wrapping

RFC 5322 specifies that lines in email messages should not exceed 998 characters in length, including the Carriage Return and Line Feed (commonly referred to as CR and LF) sequence used to terminate each line. This limit is due to historical limitations in certain email systems that couldn’t handle longer lines.

Such lines should be folded (wrapped) at the nearest space or tab character preceding the 998th character. This folding process ensures that email messages remain compliant with the maximum line length limit.

Character Encoding

While plain text is the most basic and widely supported format for the body, RFC 5322 allows for various content types through the “Content-Type” header field. It recommends the use of the US-ASCII character encoding for email messages. 

It permits the use of other character encodings, such as UTF-8, to support multilingual content in email messages; this makes it flexible and adaptable to future developments in character representation and internet protocols.

---

Campaign Refinery: A-Grade Compliance

At Campaign Refinery, we’re all about keeping up with technology. This is why we require our clients to have all security protocols implemented on their domains; this includes SPF, DKIM, and DMARC. We’re currently in the process of getting BIMI in place, too!

Why, you may ask? Besides wanting to be an email platform that consistently follows best practices, email security is something we take as seriously as mailbox providers. 

For example, Google and Yahoo are clamping down on spammers in a big way, and this means a lot of rules and regulations for bulk email senders. Besides correct syntax and structure, there is also a strong emphasis on email authentication, involving the above-mentioned protocols.

If you’re concerned about problematic email addresses in your email list, Campaign Refinery offers an amazing solution. Our platform features an automated list-cleaning tool that crawls through your contacts list and weeds out all invalid emails — this includes spam traps, bots, burner IDs, seeder accounts, and role-based emails. And of course, RFC 5322 is our benchmark to filter out invalid or incorrectly formatted addresses.

This does wonders for your sender reputation — we know because our clients see their deliverability rates skyrocket once they switch to Campaign Refinery.