An interactive walkthrough

How email works

Email is the oldest thing most people use every day, and the only major internet service still running on a design set out in 1982. This opens one up: what a message is actually made of, how a photograph gets squeezed through a pipe built for English text, what the servers say to each other on the way, and who vouches that the sender is who the letterhead claims. It ends where the Email Header Forensics Lab begins, so you can take a real message apart yourself.

Module 01

The oldest thing you use every day

Email gets called legacy technology. It is certainly old, which is not the same thing. It is the last widely used internet service that nobody owns, where a message you send can be received by someone using entirely different software on an entirely different network, without either of you asking anyone's permission. That property is the reason it survived, and it is a direct consequence of how carefully it was specified.

1971, two computers in the same room

Ray Tomlinson worked at Bolt Beranek and Newman, the contractor building the ARPANET. There was already a program for leaving a message for someone on the same machine, and a program for copying a file to another machine. He put the two together, and needed a way to write an address that meant this person, on that computer. He picked the @ sign, on the grounds that it was on the keyboard and could not turn up inside anybody's name.

The famous detail is what the first message said. It is usually given as QWERTYUIOP. Tomlinson never confirmed it; asked repeatedly, he said the test messages were "entirely forgettable and I have, therefore, forgotten them". The two machines were sitting next to each other. Internet Hall of Fame official biography; NPR obituary coverage, 6 and 7 March 2016.

Getting everyone to agree, 1973 to 1982

Sep 1973RFC 561, the first headersEvery host was labelling its mail differently, so nothing could process anything. Four authors, one of them Tomlinson, fixed three fields: FROM, DATE and SUBJECT, plus a rule that anyone could add their own as Keyword: value. That shape has never changed.

Nov 1977RFC 733The format expands and tightens. Crocker, Vittal, Pogran and Henderson.

Aug 1982RFC 821 and RFC 822, the same monthJonathan Postel writes the Simple Mail Transfer Protocol: how a message moves. David Crocker writes the message format: what a message is. That split, between the thing and its transport, is the single most useful idea in this whole deck.

Jun 1992MIMEBorenstein and Freed add a way to carry anything that is not plain English text. Every photo, PDF, accented letter and emoji you have ever emailed rides on this.

Oct 2008RFC 5321 and RFC 5322The current standards. They replaced the 1982 pair, and mostly by restating them. A 1982 mail program would still recognise most of what your inbox receives today.

How old is the newest part of your inbox?

Open any message and look at the field that decides where your reply goes. It is the field the forensics lab teaches you to check first, because when it does not match the sender you are usually looking at a scam. When was it specified, and how much has it changed since?

Reply-To: was defined on 13 August 1982, and has not changed since. RFC 822 described it as "a general mechanism for indicating any mailbox to which responses are to be sent". RFC 5322, published in October 2008 and still current, defines the same field, with the same meaning and the same syntax. It turns forty-four this month. The same is true of Subject: and Message-ID:. This is not neglect; it is the reason email still works. A format nobody is allowed to change unilaterally is a format everybody can implement, which is why a message from a mainframe in 1990 still opens on a phone in 2026.

Module 02

Anatomy of a message

The words you typed are the smallest part of an email. Above them sits a block of labelled lines, added partly by your software and partly by every server the message passes through, and almost everything worth knowing about a message is in there.

Click any line

There are two "from" addresses

The envelope · what the servers read

Spoken during the delivery conversation. You never see it.

The letterhead · what you read

Written inside the message. Your mail app shows this.

Why the gap is allowed to exist

Nothing in the protocol requires the two to match, and that is deliberate. A mailing list sends on behalf of its members; a forwarded message keeps the original author on the letterhead; a bounce has to go somewhere other than the person named in the message. Divergence is normal and necessary, which is exactly why it cannot simply be banned. The postie only reads the outside of the envelope. You only read the letter inside. Nobody was checking that the two agreed, and almost every impersonation attack lives in that gap.

The two identities have formal names you will meet in real bounce messages and in Microsoft's error text: 5321.MailFrom for the envelope, 5322.From for the letterhead, named after the two standards. Module 05 is about the machinery built to make them agree.

First, though: how does a photograph fit inside something built for English text?

Module 03

Breaking it up, putting it back

Myth we'll unpick: "email is broken into packets and reassembled in your inbox"

The instinct is right and the mechanism is real; it is filed on the wrong floor. Packets exist, and they matter, but they belong to the network underneath and the message never meets them. There is a genuine break-it-up-and-put-it-back-together inside an email, and it is the more interesting one.

Four floors, each ignorant of the one above

The break-up that does happen inside an email

Type something. Watch it get bigger.

0bytes in

0characters out

0%larger

Base64 takes three bytes at a time and rewrites them as four characters drawn from a safe alphabet of letters, digits, plus and slash. Four out for every three in, so the content grows by a third; email then breaks the result into lines of no more than 76 characters, and each line ending adds a couple more bytes. The working rule is that an attachment travels about 37 per cent larger than the file on your disk, which is why a 20 megabyte limit will not carry a 16 megabyte video.

Two reassemblies, in two different places

The network packets are put back together by the receiving server's network software, before any mail program has looked at a single character. What your mail app reassembles is something else entirely: the message's own internal structure, split on those boundary strings, with the attachment decoded back from letters into a photograph. Both are real. They happen at opposite ends of the process and neither knows about the other.

The standard for TCP is explicit that it "guarantees no correlation between the boundaries of TCP segments sent and received and the boundaries of the read or write buffers", which is a formal way of saying that packet edges cannot possibly be carrying email structure. RFC 9293, 2022.

So the message is packed. Now watch it travel.

Module 04

The journey

Press the button and follow one message from the send button to the inbox. Eight steps, no magic, and a short conversation in plain text that you could type by hand if you wanted to.

Follow one message

step 1Your app

step 2Your server

step 3DNS

step 4Their server

step 5The checks

step 6The mailbox

step 7Their app

Read the trail from the bottom up

Every server that touches a message stamps a Received: line at the top of the headers. So the list grows downwards in age: the last line is the first hop, and the first line was added by the machine that just delivered it to you.

line 1, topYour own providerAdded last, by the server that put the message in your mailbox. This is the line you can actually trust, because your provider added it.

line 2Their outbound gatewayThe sending organisation's mail server handing over. Reasonably trustworthy if the connection was authenticated.

line 3A relay in betweenA forwarding service, a mailing list, a filtering appliance. Each one adds a line and each one is a point where things can change.

line 4, bottomWhere it claims to have startedThe oldest line, and the least reliable one. Anything below the point where your own infrastructure took custody was written by someone else, and an attacker can simply invent it before handing the message over.

Trust decays as you read downwards, and the boundary is wherever a system you control first touched the message. RFC 5321 requires each accepting server to insert its trace record "at the top of the mail data", which is why the order comes out reversed.

What happens in step five, in order

Before your message reaches anyone, the receiving server checks the reputation of the connecting address, evaluates the three authentication mechanisms and writes the verdict into an Authentication-Results: header, scores the content, applies the sending domain's own policy on what to do with failures, and only then decides between inbox, junk and refusal. All of that happens before the recipient's device is involved at all.

For scale: Google says Gmail's filtering stops more than 99.9 per cent of spam, phishing and malware, and blocks close to 15 billion unwanted messages a day. Kaspersky's telemetry put spam at just under 45 per cent of all email sent in 2025. Nearly half of everything sent is junk, and you almost never see it; that invisible sorting is what the next module explains.

Which brings us to the question the whole system now turns on.

Module 05

Who says you are you

For twenty-five years anyone could type anything into the From line, and mostly still can; it is a claim, not a proof. Three mechanisms were bolted on to close that gap. They are the reason your mail gets delivered, the reason it sometimes does not, and the whole substance of reading a message header.

Three questions, asked in order

A message where SPF passes and DMARC still fails

This is the most common real-world result, and it confuses almost everybody the first time. The connecting server was on the approved list. The check came back green. The message was still rejected. Why?

Because SPF was checking a different name from the one you were reading. SPF looks up the envelope sender, the address spoken during the delivery conversation. A sender can set that to a domain they genuinely control, pass SPF cleanly, and still put a bank on the letterhead. DMARC is the rule that says the domain which passed has to be the same domain as the one in the From line. Pass without alignment is not a pass. The same effect breaks legitimate mail. Forwarding changes the connecting server, so SPF fails; a mailing list that adds a footer changes the body, so the DKIM signature fails. This is normal for forwarded mail, and it is why the answer is rarely "just turn on rejection".

The three years authentication stopped being optional

Feb 2024Google and Yahoo set a floorAnyone sending more than 5,000 messages a day must publish SPF and DKIM, have a DMARC record, align the From domain with one of them, offer one-click unsubscribe, and keep complaints under 0.3 per cent. Announced October 2023.

May 2025Microsoft joinsThe same threshold for Outlook, Hotmail and Live addresses, and non-compliant mail is refused outright with 550 5.7.515 rather than quietly junked.

Nov 2025Gmail moves from warning to rejectingGoogle's guidance now states that non-compliant traffic will experience disruptions "including temporary and permanent rejections".

May 2026DMARC becomes an actual standardAfter eleven years as an informational document describing what people happened to be doing, DMARC was published on the standards track as RFC 9989, with its two reporting formats alongside it. Email is still being written.

Having a DMARC record is not the same as being protected. An adoption survey of the top 1.8 million domains in April 2026 found around 52 per cent with a record, but fewer than half of those set to actually act on failures. A policy of p=none is a smoke detector with the battery out; it watches and reports, and does nothing. Figures from EasyDMARC, a vendor in this market, so read them with that in mind.

Why this matters

You now know what is actually in front of you when a message arrives. A block of labelled lines whose format was fixed in 1982; two different sender addresses that the protocol permits to disagree; a body quietly cut into parts and rewritten as plain characters so it can pass through a pipe built for English text; a trail of stamps that reads from the bottom up and gets less trustworthy the further down you go. Every phishing message you will ever receive has to lie in one of those places. Knowing where they are is most of the skill.

Practise itEmail Header Forensics Lab NT World InkSimulation tools catalogue NT World InkBack to presentations

Sources used. History: Internet Hall of Fame official biography of Raymond Tomlinson; NPR obituary coverage, 6 and 7 March 2016, for his own account of the first message. Standards: RFC 561, 5 September 1973; RFC 733, 21 November 1977; RFC 821 (Postel) and RFC 822 (Crocker), both August 1982; RFC 5321 (Klensin) and RFC 5322 (Resnick), both October 2008; RFC 1341 (June 1992) and RFC 2045 to 2049 (November 1996) for MIME; RFC 4648, October 2006, for the Base64 ratio; RFC 1939 for POP3 and RFC 9051 for IMAP; RFC 3207 for STARTTLS; RFC 9293, 2022, for TCP segmentation; RFC 8601 for the Authentication-Results header; RFC 6648, June 2012, which deprecated the X- prefix that vendor headers still use everywhere. Authentication: RFC 7208 (SPF), RFC 6376 (DKIM), and RFC 9989 with RFC 9990 and RFC 9991 (DMARC, 19 May 2026, obsoleting RFC 7489); BIMI remains an Internet-Draft with no RFC. Sender requirements: Google, "Gmail introduces new requirements to fight spam", 3 October 2023, and Google's email sender guidelines and FAQ, accessed 8 August 2026; Yahoo sender best practices, accessed 8 August 2026; Microsoft's Outlook high-volume sender requirements and the 550 5.7.515 error documentation, announced 30 April 2025. Volume and spam: Google's 15 billion figure, 3 October 2023; Kaspersky Securelist spam and phishing report for 2025, published 11 February 2026, which measured 44.99 per cent from its own telemetry rather than a census. Adoption: EasyDMARC 2026 DMARC adoption report, 10 April 2026, a vendor figure. Deliberately not claimed here: that the first email said QWERTYUIOP, which Tomlinson never confirmed, and any global daily email volume, because the widely quoted figures come from a paid market-research estimate and cannot be independently checked.