Email standards and protocols, demystified
The RFCs, SMTP response codes, DNS records, message headers, and Mail Transfer Agents that make email actually work. Reference material for engineers, deliverability practitioners, and anyone who has ever needed to read a bounce log and not panic.
Every email you send is governed by a stack of standards documents written over four decades by the Internet Engineering Task Force. SMTP itself, the way servers talk to each other, the format of the message, the structure of headers, the way authentication is signed, the DNS records that make routing work: each one has an RFC, sometimes several, and the modern email system is the sum of all of them.
Most senders never read those specs. You can run a successful email program for years using your ESP’s dashboard and never touch a HELO command. But the day something breaks, every shortcut you took becomes a debugging session at 2am. A bounce with a code you don’t recognize, a header your filter rejects, an MX record that resolves wrong from one provider but not another. The fastest way out is knowing where to look.
This hub is organized as a reference library, not a tutorial. The six sections below cover RFCs, SMTP response codes, DNS records, Mail Transfer Agents, the email glossary, and message headers and MIME. Each entry is searchable by code, by name, or by the symptom that brought you here.
Browse by topic
RFCs
70 reference guides covering the IETF specs behind SMTP, IMAP, POP3, SPF, DKIM, DMARC, MIME and more.
SMTP codes
121 entries for 2xx, 4xx and 5xx response codes: what each means, why it fires, how to fix it.
DNS records
A, MX, TXT, CNAME, PTR and the lesser-known records: syntax, examples, troubleshooting flow.
Mail Transfer Agents
Postfix, Exim, Sendmail, Microsoft Exchange and the modern cloud MTAs: how they work, when to pick which.
Email glossary
Short, accurate definitions for the terms that appear in every email conversation: ESP, MTA, FBL, HELO, envelope, and more.
Headers and MIME
From, To, Subject, Message-ID, Received chains, Content-Type, multipart bodies: how to read them, what each field means.
Editor’s picks
The 4 reference pages worth bookmarking
Frequently asked questions
What is the difference between SMTP, IMAP, and POP3?
SMTP (RFC 5321) is the protocol mail servers use to send messages to each other and to receive new outgoing mail from clients. IMAP (RFC 9051) is the protocol email clients use to read messages stored on a remote server, keeping the messages on the server and syncing across devices. POP3 (RFC 1939) is the older retrieval protocol that downloads messages to a single client and (by default) deletes them from the server. In a modern setup you almost always use SMTP for sending and IMAP for reading; POP3 survives for legacy reasons and a few specific use cases.
Which RFCs should every email engineer know?
A short core list: RFC 5321 (SMTP), RFC 5322 (Internet Message Format), RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), RFC 8058 (one-click List-Unsubscribe), RFC 9051 (IMAP4rev2), RFC 2045-2049 (MIME). Add RFC 3207 (STARTTLS) and RFC 8314 (mandatory TLS for submission/retrieval) once you start dealing with security. Our RFC directory tiers all 68 by importance.
How are SMTP response codes structured?
SMTP reply codes are three-digit numbers where the first digit indicates the broad category: 2xx is success, 3xx means more input is expected, 4xx is a transient (retryable) failure, and 5xx is a permanent failure. Extended status codes (RFC 3463) add a finer layer with codes like 5.1.1 (bad destination mailbox) or 4.7.0 (security/policy). A bounce like “550 5.1.1 User unknown” combines both: the 5xx category, the 5.1.1 subclass, and a human-readable message.
What is the difference between A, MX, and TXT records?
A records map hostnames to IPv4 addresses; AAAA does the same for IPv6. MX records list the mail servers responsible for receiving mail for a domain, ranked by priority, and they always point to hostnames (which are then resolved via A/AAAA). TXT records are free-form text fields used for things like SPF, DKIM, DMARC, BIMI, and domain verification. They are different layers: A says “this hostname lives at this IP”, MX says “send mail for this domain to these hosts”, TXT says “here are some policies and proofs about this domain”.
What are email headers actually for?
Headers carry every piece of metadata about a message that isn’t the body itself. The visible ones (From, To, Subject, Date) show in your client; the technical ones (Received, Message-ID, DKIM-Signature, Authentication-Results, X-* custom fields) are what your filter, your antispam engine, and any forensic analysis actually read. When debugging a delivery issue, the headers tell you the full route the message took, which servers handled it, and which authentication checks passed or failed.
Are RFCs still relevant in 2026 when most senders use an ESP?
Yes, more than ever. Modern ESPs hide the complexity but they don’t replace it: every interoperability decision, every receiver-side filter, every authentication check, every bounce code traces back to a specific RFC. When your ESP support says “we follow RFC 8058 for List-Unsubscribe”, you need to know what that means to validate they actually do. When Gmail’s February 2024 rules require “compliance with RFC 5321 and RFC 5322”, you need to know what that compliance looks like. The RFCs are the contract; ESPs are implementations of that contract.
Looking for the practical side instead? Our Deliverability hub → covers what to do with these standards in production: authentication, sender reputation, blocklists, bounce handling and inbox placement.
