Email is the dinosaur that keeps surviving asteroids. It weathered the transition from ARPANET, BITNET, and FidoNet over to the one and only Internet. It remained relevant as computers moved from universities to offices to homes, and from dial-up to broadband to cellular. When legacy software and protocols fell behind the move to smartphones, web-based apps, and social media, email plodded on, a resilient relic.

Forty-five years of consensus-driven iteration means that sending emails today bears little resemblance to how it worked at first. Messages have always had a To: field, filled with some variation of user@host above the email's content. But attachments, formatted text, message routing and forwarding, mailing lists, and even subject lines had to be proposed and debated over months and years. Now, when you send an email, the app you compose it in is several steps removed from your recipient's inbox.

The companies that send our emails, forcing AI into the mix, might look like another asteroid in the sky for our archaic addresses. Take a look at how sending and receiving works, though, with email agents scurrying behind the scenes for 20+ years now, and you’ll see that this too will miss our unassuming dinosaur.

Your email app is not the only email app

The client you use to write your emails is responsible for assembling all of the bits that make sure your recipients actually see your message. It adds headers like From:, To:, and Message-ID, all of which have been in use since 1977. Your email app also encodes attachments, formatted text, and non-English characters into 7-bit ASCII, an upgrade that dates back to 1992. When all is said and done, what leaves your inbox is plain text, ferried along by an email-specific language that every email program shares.

If you have a Gmail address, for example, your emails will travel from your on-device outbox to one of Google's mail servers. Your phone or laptop will initiate that connection using the Simple Mail Transfer Protocol, a standard that hails from the year of our Lord 1982. Back then, email servers relied on the HELO command, while today most have upgraded to EHLO, an "extended hello" documented in the 1993 revision of SMTP as:

Client: EHLO ymir.claremont.edu  
Server: 250-dbc.mtview.ca.us says hello  
Client: [the usual HELO chit-chat]

The client and server tell each other which authentication methods they support and agree to use the best one that both share. And from there on out, it's difficult to pin down precisely what happens to your email. When two distinct and unrelated mail servers talk to each other, they have to stick with SMTP conventions to understand each other. But there are a ton of checkpoints and deliverability decisions that happen outside of server-to-server interactions. Gmail's servers may perform tests and checks on your email that are different from the ones Outlook conducts before sending your message.

Those that work in email had to come up with a shared vocabulary for these internal and proprietary programs, all handling the same generalized email tasks in slightly different ways. They decided to call them agents.

Agents all the way down

Much like today’s AI agents, the authors of SMTP's 2001 revision complained that "these terms are used with at least the appearance of great precision in other environments, the implied boundaries between [agents] often do not accurately match common, and conforming, practices with Internet mail." And so, depending on who you ask, the first of these agents may or may not be called a Message Submission Agent.

Whether it's Gmail's version of an MSA or AOL's, the MSA's job is to make sure your email has all the required headers, your From: address matches the account credentials your inbox provider has in its database, and there's no obviously bad-faith content in the message. There's no point in placing an email in the sending queue if it can be rejected with a quick glance.

If everything looks on the up and up, the Message Submission Agent hands your email over to a Message Transfer Agent. SMTP doesn't care what you call it as long as there's a timestamped Received header tacked on before the transfer itself is initiated. In fact, Gmail even adds a Received breadcrumb when two Gmail users email each other, despite the fact that the message never leaves Google's infrastructure.

When a transfer agent does need to figure out where your email goes next, it looks for something called an MX record. You can see what one looks like, including the IP addresses the record resolves to, with a site like mxtoolbox.com. Next, MTAs will add a DKIM-Signature header as a way to verify that the message hasn't been altered since it left the sending domain, and off it goes.

Sometimes, there are intermediary transfer agents. Buttondown, for instance, lets you draft an email in your own client and send it to a relay address that converts your message into a beautified newsletter before sending it to your list. That entails:

1. Your inbox provider's MTA adding Received and DKIM-Signature headers before looking up and sending to Buttondown’s IP address;
2. Buttondown's MTA adding its own Received and DKIM-Signature headers, looking up each of your subscribers' mail servers, and sending to each of them;
3. MTAs from each of your subscribers' inbox providers adding yet another Received header, this time without adding DKIM because the email is almost (but not quite!) ready for the recipient's inbox.

Somewhere amidst the litany of SMTP updates, those working on the protocol realized that an email client could assemble an email that checks all of the required boxes, the associated domain and its mail server could add a DKIM signature promising everything looks good, and the message could still be entirely untrustworthy. And so a slew of anti-spam measures were added to the mix.

Unsolicited and unwanted email

When transfer agents receive emails from third-party domains, they almost always check them against public blocklists, rejecting anything that's been flagged by groups like Spamhaus. Then, MTAs look at the sending domain's SPF and DMARC records, both of which broke the mold by originating outside of the typical RFC process. The Sender Policy Framework idea first popped up in a Usenet conversation in 2000 and Domain-based Message Authentication, Reporting and Conformance, as the name suggests, was published in 2012 by a handful of enterprise senders.

DKIM, SPF, and DMARC still aren't enough, though! MTAs pass email content through a spam filter, check it for malware, and look for untrustworthy URLs before…drumroll…rejecting it. This "graylisting" is the frequent practice of temporarily blocking an email simply because legitimate MTAs always try again while spam MTAs typically give up after one try.

At this stage, many inbox providers have their MTAs hand off approved emails to a Message Delivery Agent for the last digital mile. MDAs put the journey-weary message in the recipient's cloud-based inbox, where it can be downloaded to their device from their email client of choice.

The user opens their email client—or, as I neglected to mention, what SMTP documentation sometimes calls the Message User Agent (that’s four agents, for anyone who’s counting)—and checks with their inbox provider's mail server for any new mail.

The email client downloads messages using either POP3, IMAP, or the nascent JMAP. Plain text is converted back into HTML (including tracking pixels) and attachments before everything is passed through the on-device spam filter (that's three spam checks since the email hit the first server, for anyone who’s counting). Finally, the email can rest its weary headers, its journey complete. Unless the recipient forwards it, which is anything but straightforward.

Lots of agents and zero AI

This account of every email’s journey isn’t even the whole story. It’s an oversimplified and dumbed down version of what happens several hundred billion times per day. And it works just fine without large language models and machine learning bots. Even better, email will be fine if inbox providers try to force AI agents that delete messages without permission. Because despite all of the mail servers and message agents, email is really just a shared language. Don’t like the dialect your inbox provider has adopted? There are countless other options.

Spinning up your own email server is unrealistic even for those with technical backgrounds—the gatekeepers effectively unavoidable. But at least you get to choose who handles your email. You get to send newsletters from your own domain, building a deliverability reputation all your own. And when you want to move to another platform, no one can stop you.