| Invention | Email (electronic mail) as networked digital messages |
| Primary Credit | Ray Tomlinson at BBN (Bolt, Beranek and Newman), Cambridge, Massachusetts |
| First Network Email | Late 1971 on ARPANET, between two TENEX machines placed side by side |
| Core Breakthrough | Mail that can move between different hosts, not only users on the same computer |
| Address Pattern | user@host using the @ symbol to separate person and machine |
| Early Building Blocks | SNDMSG (local messaging) combined with CPYNET (network file transfer ideas) to send messages over ARPANET |
| Transport Standard | SMTP defined in RFC 821 (Aug 1982), modernized in RFC 5321 (Oct 2008) |
| Message Format Standard | Internet Message Format in RFC 5322 (Oct 2008): headers like From, To, Subject |
| Attachments and Rich Content | MIME in RFC 2045 (Nov 1996): attachments, multipart, media types |
| Mailbox Access | POP3 (RFC 1939, May 1996) and IMAP4rev1 (RFC 3501, Mar 2003) |
| Modern Trust Signals | DKIM (RFC 6376, Sep 2011), SPF (RFC 7208, Apr 2014), DMARC (RFC 7489, Mar 2015) |
| Secure Transport Layer | STARTTLS for SMTP (RFC 3207, Feb 2002) enabling TLS encryption in transit |
Email is digital mail built for the Internet era: a system that lets you send a message to a mailbox anywhere, then read it whenever you choose. It feels simple, yet under the hood it is a careful mix of standards, servers, and routing that keeps communication reliable at global scale.
- What Email Is
- Two Layers People Often Mix Up
- How Email Was Created
- How an Email Message Is Built
- Header Fields You See
- Header Fields That Matter Quietly
- A Small Header Sample
- How Email Moves across the Internet
- A Clear Delivery Flow
- SMTP, IMAP, and POP3 Compared
- Attachments, HTML, and MIME
- Email Service Types
- Personal Mail
- Work Mail
- Automated Mail
- Delivery, Bounces, and Reliability
- Trust and Privacy Layers
- Three Widely Used Domain Signals
- Key Milestones in Email
- Email Variants and Use Cases
- Why Email Still Fits the Internet Era
- Email Terms You Will See
- References Used for This Article
What Email Is
Email is a store-and-forward messaging system. Your message is accepted by a mail server, then passed along—server to server—until it reaches the recipient’s mailbox. The key idea is separation: writing and delivery happen now, while reading can happen later.
Two Layers People Often Mix Up
- Transport: how servers move mail using SMTP.
- Format: how a message is written, with headers and a body, defined by RFC 5322.
How Email Was Created
Before modern email, many computers already supported local messaging—leaving notes for other users on the same machine. The leap came in 1971, when Ray Tomlinson at BBN made messages travel over ARPANET. He adapted an existing tool (SNDMSG) and blended in network transfer ideas from CPYNET, turning local notes into network mail.
The famous @ sign was a practical decision, not branding. Email needed a clean way to separate the user from the destination host. The result—user@host—became a durable address format that still fits modern systems, from webmail to large enterprise platforms.
Email did not start as a “product.” It started as a small, working improvement: send a message to someone on another machine using a single symbol as the separator.
How an Email Message Is Built
A typical email message has two visible parts: headers and the body. Headers are structured lines that help software route, label, and display the message. The body is the human content—plain text, HTML, or MIME multipart content for attachments.
Header Fields You See
- From: who the message claims to be from.
- To: primary recipients.
- Subject: a short label.
- Date: when it was composed.
Header Fields That Matter Quietly
- Message-ID: unique identifier used for threading and tracking.
- Received: a hop-by-hop trail added by servers.
- MIME-Version: signals modern body structure.
- Content-Type: describes text, HTML, or multipart data.
A Small Header Sample
From: Alex Example <alex@example.com>
To: Sam Reader <sam@example.net>
Subject: A Simple Email Message
Date: Tue, 12 Mar 2024 10:15:00 +0000
Message-ID: <unique-string@example.com>These lines look plain, yet they carry a lot of meaning. A well-formed Message-ID supports threading, while Content-Type controls whether your client shows text, HTML, or multiple parts.
How Email Moves across the Internet
When you click Send, your device typically connects to a mail submission service, which then uses SMTP to hand the message to other servers. Those servers may relay the message through several hops. This design keeps email resilient, because each server can queue mail if the next hop is temporarily unavailable.
A Clear Delivery Flow
- Compose in a client (MUA) and submit to a server.
- Server looks up the recipient domain’s MX record in DNS.
- Servers exchange the message using SMTP and may add Received lines.
- Message is stored in the recipient mailbox until read via IMAP or POP3.
SMTP, IMAP, and POP3 Compared
| Protocol | Primary Job | Where It Runs | What Users Notice |
|---|---|---|---|
| SMTP | Moves mail between servers and accepts outgoing mail submissions | Mail servers and submission gateways | Send works even if the other person is offline |
| IMAP | Synchronizes mailboxes and folders on the server | Mail server + client | Same inbox across phone and computer |
| POP3 | Downloads messages from a mailbox (often to local storage) | Mail server + client | Simple access with fewer mailbox features |
Attachments, HTML, and MIME
Early email was mostly plain text. The Internet grew, and people needed files, images, and structured content. That is why MIME matters: it defines how a single email can carry multiple parts with clear labels like Content-Type and Content-Transfer-Encoding.
Common MIME Patterns People See
- multipart/alternative: plain text + HTML versions of the same message.
- multipart/mixed: message plus one or more attachments.
- application/pdf, image/png, text/calendar: the “media types” that help software handle files correctly.
HTML email makes newsletters and receipts easy to read, yet plain text stays valuable for clarity and compatibility. Many systems send both, letting the receiver choose. That dual approach is a calm balance between design and reliability.
Email Service Types
The invention of email created an ecosystem: different tools for writing, delivering, storing, and searching messages. Modern services often hide complexity, yet the pieces are still there—just packaged behind accounts, apps, and webmail.
Personal Mail
- Webmail for quick access in a browser
- Mobile clients with push notifications
- Search and labels to organize fast
Work Mail
- Shared mailboxes for teams
- Calendars and contacts tied to the same identity
- Retention and archiving for long-term records
Automated Mail
- Receipts, alerts, confirmations
- System notifications from apps and services
- Bounces and delivery reports for failed mail
Delivery, Bounces, and Reliability
Email is famous for being forgiving. If a destination server is busy, sending systems can retry later. If an address is wrong, a server can return a bounce. This is not glamorous, but it is the reason email can keep going through ordinary internet hiccups and still deliver what people expect to recieve.
| Signal | Meaning | Why It Matters |
|---|---|---|
| Queue | Mail is stored temporarily for retry | Supports resilience and smoother delivery |
| Bounce | Delivery failed and a notice is returned | Keeps sender informed without silent loss |
| Retry Window | Servers attempt delivery for a period before giving up | Handles short outages without user action |
Trust and Privacy Layers
Modern email uses several layers that make messages safer and more trustworthy. For transport privacy, many servers use TLS via STARTTLS so mail moves in an encrypted channel between servers. For identity signals, domains can publish policies and signatures so receivers can validate that a message aligns with the domain’s sending rules.
Three Widely Used Domain Signals
- SPF: lets a domain state which servers are allowed to send on its behalf.
- DKIM: adds a cryptographic signature so receivers can verify message integrity.
- DMARC: ties policies to visible From identity and enables reporting.
These tools don’t change what you write. They influence how receiving systems judge authenticity, how they handle suspicious mail, and how they support a cleaner inbox experience.
Key Milestones in Email
Email evolved through a series of standards and service shifts. A few dates stand out because they shaped what users now take for granted: universal delivery, attachments, and consistent behavior across products. Each milestone below connects to a capability you likely use daily, even if you never see the machinery.
| Year | Milestone | Why It Still Matters |
|---|---|---|
| 1971 | First network email on ARPANET; user@host addressing | Created the durable identity pattern of an email address |
| 1982 | SMTP standardized (RFC 821) | Established the core delivery protocol for Internet mail |
| 1996 | MIME (RFC 2045) and POP3 (RFC 1939) | Attachments and simpler client retrieval became mainstream |
| 2003 | IMAP4rev1 (RFC 3501) | Enabled modern multi-device mailbox syncing and folders |
| 2008 | Modern specs: RFC 5321 and RFC 5322 | Clarified today’s expected behaviors for transport and format |
| 2011–2015 | DKIM, SPF, DMARC widely adopted | Improved sender identity checks and helped reduce inbox confusion |
Email Variants and Use Cases
Even though we call it email, the “same” invention appears in several variants. The differences are not cosmetic; they shape how messages are stored, searched, and shared. Understanding these variants makes modern email feel less mysterious and more like a set of clear choices.
- Webmail runs in a browser and relies on server-side storage and search.
- Client-Based Mail uses apps that connect over IMAP or POP3 and usually send via SMTP submission.
- Mailing Lists redistribute a single message to many recipients and depend heavily on consistent headers and clear list metadata.
- Transactional Messages are system-generated notices like sign-in links, invoices, or confirmations.
Why Email Still Fits the Internet Era
- Open standards let different providers communicate without special deals.
- Asynchronous delivery works across time zones and busy schedules.
- Address-based identity ties messaging to accounts, services, and long-term records.
- Extensibility (MIME + SMTP extensions) allows growth without breaking basics.
Email Terms You Will See
Glossary of Common Email Words
| MUA | Mail User Agent: the app you use to read and write email. |
| MTA | Mail Transfer Agent: the server software that moves mail via SMTP. |
| MX | DNS record that tells the Internet where a domain receives email. |
| Header | Structured lines like From and Subject that describe a message. |
| MIME | Rules that allow attachments and multipart message bodies. |
| TLS | Encryption used to protect mail connections in transit, often via STARTTLS. |
| SPF / DKIM / DMARC | Domain signals that improve identity checks and message handling. |
References Used for This Article
- NIST Computer Security Resource Center — SP 800-177 Rev. 1, Trustworthy Email: Practical guidance on modern email trust controls like authentication and policy enforcement.
- RFC Editor — RFC 5321: Simple Mail Transfer Protocol (SMTP): Defines how email is transported between mail servers on the Internet.
- RFC Editor — RFC 5322: Internet Message Format: Specifies the structure of email headers and the overall message format.
- RFC Editor — RFC 2045: MIME Part One: Format of Internet Message Bodies: Explains how email carries attachments and multiple content types via MIME.
- RFC Editor — RFC 1939: Post Office Protocol – Version 3 (POP3): Documents the standard protocol for downloading messages from a mailbox.
- RFC Editor — RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL (IMAP4rev1): Defines server-based mailbox access and synchronization used by many clients.
- RFC Editor — RFC 6376: DomainKeys Identified Mail (DKIM) Signatures: Describes cryptographic signing to help receivers verify message integrity and responsibility.
- RFC Editor — RFC 7208: Sender Policy Framework (SPF): Specifies how domains publish authorized sending hosts to reduce spoofing.
- RFC Editor — RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC): Defines domain-level policy and reporting that builds on SPF and DKIM checks.
- RFC Editor — RFC 3207: SMTP Service Extension for Secure SMTP over TLS: Standardizes STARTTLS to enable encrypted SMTP connections in transit.