Email is crazy

Email is crazy<br>25 Apr 2026

11 min read

email security tech

Email infrastructure, accurately depicted

I come across email systems routinely during my day job and often wonder how email works under the hood. This blog post is a result of my foray into that land.

Email is one of the most successful communication technologies ever built and Billions1 of emails are sent each day . Almost half of them are spam, and a quarter of them are marketing emails. Nonetheless a big chunk is transactional emails like password resets, notifications, alerts etc. The beauty of email is that it just works despite the insane complexities that power the email infrastructure.

Email evolved organically over the years, tracing its origins to the academic labs of ARPANET in the ’70s. Its various components were designed by different people, at different times, facing different challenges. The email ecosystem is a very complex beast with more than 100 RFCs mandating its various protocols.

Let us take a deep dive into this 1970s technlogy to see how it works with a classic example of Alice and Bob.

Alice wants to send an email to Bob. She fires up her mail client and types in the message.

The mail client hands it over to the Mail transfer agent over the internet using SMTP.

The security and the spam filters kick in and check the email.

If the email is deemed safe, the email is forwarded to the Mail Access Agent of the recipient.

Bob’s Mailbox stores the email.

Bob’s Mail client polls from this mailbox and displays the email to Bob.

Simple, right? Well, not really. A lot of complexity and security potholes are hidden in plain sight here. Let us go deeper to see what’s actually happening under the hood.

Part 1: Your Mail Client is just a composer

When Alice hits send, the mail client doesn’t send the email, it simply submits it. The Mail Submission Agent, which is on a server listening on port 587 checks the authentication and stamps it with a message-ID. At this point Alice’s client is done and the email is someone else’s problem.

That someone else is the Mail Transfer Agent i.e. the postman. Its job is to find the address of the recipient and deliver the message there. To do this, the MTA uses the address book of the internet, the DNS system. It asks the question to the DNS, “What are the MX records of this domain?”.

MX i.e. Mail Exchanger are a special type of DNS records that are used to route emails. Every domain that wishes to receive email needs to publish them.

They look like this:

example.com. IN MX 10 mail.example.com.<br>example.com. IN MX 20 mail2.example.com.

Note: The numbers 10, 20 denote priority. If mail.example.com is down, the sending server automatically tries mail2.example.com.

Most people think email is real-time, but it is not. It is a queuing system with retry logic. If the destination server is down, the message stays on the queue and is retried with exponential backoff at 5 minutes, 30 minutes, 1 hour and so on up to 4-5 days. If Bob receives Alice’s email instantly, it’s probably because of fast queue drain. Email is an eventually consistent system that doesn’t care about speed, although modern email infrastructure makes it feel blazing fast.

Part 2: The signature is not the address

Once the sending server locates the destination after MX lookup, it opens up an SMTP connection. SMTP is just plain text. In fact anyone can type it in their terminal.

$ telnet smtp.example.com 587<br>220 smtp.example.com ESMTP<br>EHLO localhost<br>250 Hello<br>MAIL FROM:[email protected]><br>250 OK<br>RCPT TO:[email protected]><br>250 OK<br>DATA<br>354 Go ahead<br>From: [email protected]<br>Subject: Urgent: Verify Your Account

Click here immediately.<br>250 Message accepted

Note: How do the servers know when the messages end? By a single period ’.’ on its own line. Email is full of such tiny quirks.

Astute readers might have noticed the discrepancy in the previous email. The MAIL FROM: says [email protected] whereas the FROM: header inside the message says [email protected]. Unfortunately this is not an error and according to SMTP they can be different. The first one (MAIL FROM:) is the envelope, used by servers for routing, and the second one (From:) is the header meant for the human reading the email. The envelope is like an address written on the physical letter, whereas the header is like the sender’s signature on the letter. SMTP doesn’t check if they match.

You might be wondering why is it so. SMTP was designed in the late 70s2 and early 80s3 for the academic cooperative networks4 which were based on trust. I’m sure nobody then had imagined internet banking would exist in the future. This glaring loophole is the reason phishing and spam work.

Part 3: Securing email AKA three kids in a trenchcoat

Good things rarely last and it didn’t take long for spammers to exploit these gaps. With the explosion of phishing and spam, the industry’s answer was not to fix SMTP but to add more duct tape. SMTP was deeply entrenched and...