What are the most important RFCs for email (5321, 5322, 7208, etc.)?

If you only learn a handful of RFC numbers in your email career, learn these. They are the rulebook every mailbox provider, ISP, and authentication tool quietly checks your mail against. Break them and your delivery problems usually trace back to one of these documents.

The two that define email itself

RFC 5321 defines SMTP, the protocol mail servers use to talk to each other. It covers the EHLO/HELO greeting, MAIL FROM (the envelope sender, also called the Return-Path), RCPT TO, DATA, and the response codes you see in bounces. When you read a bounce that says "550 5.1.1 user unknown" or "421 4.7.0 try again later," those codes come from 5321. The Return-Path it defines is also what SPF checks against, which trips up a lot of senders who confuse it with the From header. See what RFC 5321 defines for the full breakdown.

RFC 5322 defines the message itself: headers like From, To, Subject, Date, Message-ID, and the body. This is the "From" your recipient actually sees in their inbox, which is different from the SMTP MAIL FROM. DMARC alignment is the rule that ties these two Froms together. Get the difference wrong and your authentication can pass but DMARC still fails. We have a longer note on that at what RFC 5322 defines.

The three authentication RFCs you cannot skip

RFC 7208 (SPF) says which IPs are allowed to send mail using your domain in the Return-Path. It lives as a TXT record on your domain. The big trap is the 10 DNS lookup limit. Once you exceed it your SPF returns PermError and authentication fails silently. We see this constantly with senders who chain include: statements for every vendor (HubSpot, Mailchimp, Salesforce, Google Workspace) and never flatten the record.

RFC 6376 (DKIM) signs the message with a private key. The receiver fetches the public key from DNS and verifies the signature. Use 2048-bit keys, not 1024. Rotate them. If you change ESPs and forget to remove the old selector, you have a stranded private key floating around that someone could abuse.

RFC 7489 (DMARC) ties SPF and DKIM together by requiring one of them to pass AND align with the visible From domain. Without DMARC, SPF and DKIM are almost decorative. Since February 2024, Google and Yahoo require DMARC for bulk senders (Google's announcement). Start at p=none, read the aggregate reports, then move to p=quarantine and p=reject.

The supporting cast

• RFC 8058 defines one-click List-Unsubscribe. Gmail and Yahoo now require it for bulk senders. It is not optional anymore.
• RFC 8617 (ARC) preserves authentication results through forwarders and mailing lists, which would otherwise break DKIM signatures.
• RFC 8461 (MTA-STS) forces TLS between mail servers so attackers cannot downgrade your connection to plaintext.
• RFC 8460 (TLS Reporting) gives you reports when TLS delivery fails. Pair it with MTA-STS.
• RFCs 2045 through 2049 (MIME) define how you attach files, encode HTML, and handle non-ASCII characters. You rarely touch these directly, but every multipart email depends on them.

How we use these in practice

When a client comes to us with a deliverability problem, the diagnostic walk is almost always: check 5321 (is the Return-Path domain you expect), check 5322 (does the visible From match the sending domain), check 7208 (does SPF resolve under 10 lookups), check 6376 (is DKIM signing with a current selector), then check 7489 (does DMARC align and what does the policy say). Nine out of ten problems land in one of those five RFCs.

If you want the bigger picture on why these documents matter at all, read what is an RFC and common RFC compliance issues that break deliverability.