Email

Email, short for electronic mail, is a method of exchanging digital messages between people and organizations over computer networks. A message is composed in a client program, handed to a mail server, passed from server to server across the internet, and stored in the recipient's mailbox until it is read. It is one of the oldest network applications still in everyday use, and it remains a core tool for personal communication, business correspondence, account registration, and official notices. It is also a common channel for security attacks and a major source of unsolicited commercial messages.

Email has been shaped by open technical standards more than by any single company. Its basic architecture, from the internet delivery protocol to the message format, was set out in a series of documents from the 1970s and 1980s and then revised over decades. Later additions such as encryption, sender authentication, and anti-spam filtering were layered onto this original design, which assumed a small, trusting network. Understanding email therefore means looking at both its historical design choices and the continuing work to make it secure and reliable.

This entry first covers what an email message consists of and how its addresses are structured, then traces its origins in early ARPANET experiments and the standardization of the core protocols. It describes how messages move between servers, how users retrieve them, and how message formats handle attachments and international text. It then examines security measures, spam and phishing, the social and workplace uses of email, the legal rules that apply to it, and how it relates to newer communication tools.

Message Structure and Addressing

An email is best understood as two layers that travel together but are not always identical. The first is the envelope, a set of parameters that mail servers use for routing and error reporting. In SMTP, the envelope consists of the reverse-path given by the MAIL FROM command and the forward-paths given by one or more RCPT TO commands. The second layer is the message itself: a block of header fields, a blank line, and a body, defined in RFC 5322. The two layers can diverge in ways that matter. A message sent to five people has one envelope with five forward-paths, but its To and Cc headers may list only some of them. A Bcc recipient normally appears in the envelope and not in the headers that other recipients see. The envelope sender, which receives bounce notifications, is often a technical return address that differs from the From address the user sees.

An address takes the form local-part@domain. The local part identifies a mailbox within the domain and is interpreted by the receiving system, not by the sender. RFC 5321 allows up to 64 octets for the local part and 255 for the domain. Because RFC 5322 permits quoted strings in the local part, an "@" can appear inside quotes, so the separator is conventionally taken to be the last "@" in the address. The domain is a DNS name. To deliver mail, the sending server queries the domain's MX (mail exchanger) records, which list the hosts that accept mail for that domain, each with a preference value; lower values are tried first. If no MX record exists, RFC 5321 falls back to the domain's address record. The sending server then opens an TCP/IP connection to the chosen host, normally on port 25, and transfers the message over the Internet. Because routing depends on this lookup, a misconfigured DNS zone can stop mail from reaching an entire domain even when its mailboxes are healthy.

Header fields are lines of the form name: value, and RFC 5322 defines their syntax and meaning. Only two are mandatory, From and Date, although nearly every message also carries To, Subject, and Message-ID. Cc and Reply-To are common, and Sender records the actual submitter when a message is sent on behalf of someone else, such as an assistant writing for an executive. Mail clients usually display the From value as the sender, but the transport does not verify it: the envelope sender can be different, and a mailing list may rewrite From or Reply-To on the way through. This gap between the visible sender and the envelope sender is why receiving systems need separate authentication checks, which are covered in the security section.

Replying, forwarding, and grouping messages into conversations depend on identifiers rather than on the visible text. Each message should carry a Message-ID header, a globally unique string enclosed in angle brackets and generated by the originating system. When a user replies, the client places the parent's Message-ID in the In-Reply-To header and appends the chain of earlier identifiers to the References header. Clients use these fields to thread messages into conversations. When they are missing or stripped, for example by some gateways or automated tools, clients fall back to comparing normalized subject lines, which is less reliable: unrelated messages may be merged and genuine replies split apart. A forward normally creates a new message with its own Message-ID, so it does not join the original thread in the same way a reply does, and the link to the original usually exists only in the quoted text or an attachment.

Origins in Early Networked Messaging

People left messages for one another on computers well before email crossed a network. Computer-based messaging between users of the same system became possible following the advent of time-sharing in the early 1960s, and an influential case was MIT's time-sharing system CTSS. In 1965, Noel Morris and Tom Van Vleck implemented both an electronic mail command and a text messaging facility for CTSS. The MAIL command was installed in the fall of 1965, and each user's messages would be appended to a per-user file called MAIL BOX. The design had obvious limits. Because neither version did anything about privacy, authentication, or security, and any user could write or view any other user's mailbox. The idea was useful, but it could only work inside one machine.

The step to network email came at Bolt Beranek and Newman (BBN), where Ray Tomlinson worked on the ARPANET, the research network that was a precursor of the internet. In 1971, he developed ARPANET's first application for network email by combining the SNDMSG and CPYNET programs, allowing messages to be sent to users on other computers. SNDMSG handled local messages, and CPYNET handled file transfer between machines. Tomlinson's test was modest: he sent a message from one DEC PDP-10 computer to another over ARPANET. Tomlinson later said he could not recall the text of that message, and the content was never the point. Commentators usually credit this as the first network email, but the qualification matters, since it was not the first electronic message ever created. Its novelty lay in addressing a user on a different host.

The addressing scheme came from a practical need. Once messages could reach other machines, the system had to separate the user's name from the name of the computer. Tomlinson chose the @ sign to separate local from global emails in the mailing address. His choice of symbol was deliberate, since the symbol was chosen because it was rarely used in names and conveyed the meaning "at". The resulting pattern of a local part, an @ sign, and a host name is still the basic structure of addresses today.

The move from single systems to a network of many hosts also exposed a compatibility problem. Most developers of early mainframes and minicomputers developed similar, but generally incompatible, mail applications. Over time, a complex web of gateways and routing systems linked many of them. That experience helped create the later demand for shared standards, which the IETF and its predecessors would address in the following decade.

Networked mail also brought unsolicited commercial messages. On May 3, 1978, Gary Thuerk, a marketing representative for Digital Equipment Corporation (DEC), sent an advertisement for an open house about DEC's new computers. He sent it to 393 recipients, addressed to every user with an ARPANET account on the West Coast of the United States. Counts differ between sources: one account puts the number at roughly 400 accounts, depending on the count used by each historical source. The reaction was hostile. The ARPANET administrators reprimanded Thuerk and made it clear that mass emailings were not an acceptable use of the network. The incident is widely cited as the first case of what later became known as spam, and it showed that a shared network with informal norms could be exploited once the cost of sending to many recipients fell.

Standardization and the Role of the IETF

The first formal specification for moving mail between hosts was the Mail Transfer Protocol, documented in RFC 772 in September 1980 by S. Sluizer and Jon Postel. It was framed as a first draft that invited comment, and it described how a sending process opened a control connection to a receiving process and exchanged coded replies. It was short-lived. In August 1982, Postel's Simple Mail Transfer Protocol (RFC 821) replaced it, along with the earlier 1981 specification RFC 788. RFC 821 introduced the command vocabulary still used today, including MAIL, RCPT, and DATA, and a three-digit reply code system. It assumed only a reliable, ordered data stream, so it did not depend on any particular network technology.

The message format was standardized separately. RFC 822, "Standard for the Format of ARPA Internet Text Messages," was dated 13 August 1982 and was revised by David H. Crocker. It replaced RFC 733 of 1977, which had codified informal conventions already in use on the ARPANET. RFC 822 divided a message into an envelope, holding the information needed for transmission and delivery, and contents, meaning the material handed to the recipient. Contents consisted of a block of header fields followed by a body whose structure was left unspecified. The document deliberately tolerated redundancy, using free-text field names rather than compact codes, and it said little about encoding anything other than lines of text. Its header syntax became the template for later internet mail, and it was superseded in 2001 by RFC 2822, itself later succeeded by the 2008 RFC 5322.

Later changes extended SMTP without breaking existing software. Extended SMTP, defined in RFC 1869 in 1995, allows a server to list the extensions it supports in its response to the client's greeting. Extensions added over time include STARTTLS for encryption, SMTP AUTH for authentication, a message-size declaration, 8-bit body transport, and support for internationalized addresses. RFC 2821 (2001) clarified the 1982 specification, and RFC 5321, written by John Klensin and published in October 2008, consolidated the earlier documents. RFC 5321 obsoleted RFC 821, RFC 974, RFC 1869, and RFC 2821, and updated RFC 1123 by replacing its mail-transport material. Its core command set and reply structure were kept, which is why software written against the 1982 protocol continues to interoperate with current servers.

The Internet Engineering Task Force (IETF) develops these standards through open working groups, and much of the drafting happens through public mailing-list discussion. The RFC 822 preface notes that its predecessor was refined over a year on the ARPANET mail system itself. Results are published as numbered Request for Comments documents. An RFC is not normally edited once issued; instead, a new document obsoletes it, which leaves a visible chain of revisions. The chain for SMTP runs from RFC 772 to RFC 821, then RFC 2821, and finally RFC 5321. Documents that reach full standard status receive a STD number, as RFC 821 (STD 10) and RFC 822 (STD 11) did. This practice let independent implementers across many networks agree on a common, versioned reference.

Delivery Architecture and Message Routing

Sending an email involves several cooperating programs. A user agent, such as a desktop client, a mobile app or a webmail page, hands the composed message to a submission server, which accepts it only from authenticated users and then passes it into the wider transfer network. Inside that network, mail transfer agents (MTAs) relay the message from server to server using the Simple Mail Transfer Protocol (SMTP). Each relay works in a store-and-forward fashion: it accepts the complete message, writes it to local storage, and only then attempts the next hop. A server can therefore accept a message long before the message reaches its final destination, and the sender's client usually receives no delivery confirmation at that point.

Routing to the destination depends on the Domain Name System (DNS). The sending server takes the domain part of the recipient address and queries its mail exchanger (MX) records, which list one or more hosts responsible for receiving mail for that domain, each with a preference value. The server tries the lowest-preference host first and falls back to the others if it cannot connect, which gives domains built-in redundancy. It then opens a TCP connection to the chosen host on port 25 and conducts an SMTP dialogue: it identifies itself, names the envelope sender and each recipient, and transfers the content. The MX mechanism replaced earlier explicit source routing, which the IETF deprecated in 1989 because it was cumbersome, so the path to a destination is now determined by ordinary DNS data rather than by the sender's instructions.

When a message reaches the receiving domain's server, the final MTA hands it to a mail delivery agent (MDA). The MDA writes the message into the recipient's mailbox store, which the recipient's client later retrieves through a separate access protocol. Delivery failures are handled through the SMTP reply codes. A reply in the 4xx range signals a temporary problem, so the sending server defers the message and tries again later. A 5xx reply signals a permanent refusal, such as an unknown recipient, and causes the sending server to return a bounce message, also called a non-delivery report, to the return address on the envelope. Because bounces are themselves email, poorly configured systems can create loops, and many servers send bounces with an empty sender address to prevent this.

Queuing and retries are what allow mail to survive outages. If a destination server is down or overloaded, the sending MTA keeps the message in its queue and retries at increasing intervals. Most implementations give up only after a fixed period, often measured in days, and then generate a bounce. Relaying through several intermediate servers adds further resilience and is also how mailing lists, forwarding services and gateways between networks operate. Each server that handles a message typically prepends a Received header field recording the hop, which forms a trace of the route.

These same properties make the path hard to verify. Intermediate servers may be operated by different parties, Received headers can be forged or omitted, and a message may be re-queued, rewritten or forwarded in ways that obscure its origin. Transport encryption between hops is frequently opportunistic, so the protection of each leg depends on what the two servers negotiate. Consequently, receiving systems generally cannot know with certainty which route a message took, and they rely on the authentication and filtering mechanisms described elsewhere in this article to judge a message's trustworthiness.

Retrieval Protocols and Access Methods

SMTP is designed to move messages, not to hold them for the user. It carries mail from a client to its submission server and then between servers, but the recipient reads the mailbox through separate protocols. The two long-established retrieval protocols are POP3 and IMAP. Both are defined by the Internet Engineering Task Force, both run over TCP, and both are normally wrapped in TLS on dedicated ports. Each requires the client to authenticate before it can open the mailbox.

POP3 (Post Office Protocol, version 3) follows a simple model. The client connects, downloads the waiting messages, and in its common configuration deletes them from the server. The mailbox is therefore a drop point that the device empties. This suits a single computer used as the main archive, but messages read on one device do not appear as read on another, and a message removed from the server exists only on the device that downloaded it. Some clients can leave copies on the server, but that is a client setting rather than part of the protocol's model, and POP3 has no native concept of server-side folders.

IMAP (Internet Message Access Protocol) treats the server copy as authoritative. Clients can list, create, and rename folders, and they can set flags such as read, answered, flagged, or deleted. A change made on one device propagates to the others at the next synchronization. IMAP can also fetch only message headers or a particular MIME part, which allows a phone to show a preview and download a large attachment later, and it allows searches to run on the server. The trade-off is that the server must hold the full mailbox, so provider storage quotas and retention rules directly determine how much a user can keep.

Not every user runs a dedicated program. Webmail runs in a web browser and talks to the provider over HTTPS, and mobile apps on a smartphone or tablet provide the same function. Many such apps use IMAP or POP3 internally, but large providers and enterprises often rely on proprietary interfaces. Microsoft's Exchange ActiveSync, for example, synchronizes mail, calendars, and contacts between Exchange servers and devices over HTTP, and it supports push delivery so that new messages arrive without the device polling the server. These approaches make the mailbox reachable without any installed client, but they bind the user more closely to one provider's services. Third-party clients can work only with the access the provider chooses to expose.

The choice between local and server-side storage is the central practical trade-off. Local storage, typical of POP3 setups, gives offline access and full control over stored files, and it is not limited by a provider's quota. However, it makes multi-device use awkward, and the device becomes a single point of failure unless it is backed up. Server-side storage, typical of IMAP and webmail, makes multi-device use seamless and moves backup responsibility to the provider or an administrator. Its costs are a dependence on connectivity for many operations and the concentration of a user's correspondence in one place, which raises security and data-governance questions. Many modern clients combine the two approaches by caching messages locally while keeping the authoritative copy on the server. Organizations often add separate archiving systems so that retention obligations are met regardless of which client a user chose.

Message Format, MIME, and Internationalization

The original Internet mail format was built for a narrow character set. The 1982 standards (RFC 821 for transport and RFC 822 for messages) allowed only 7-bit US-ASCII text in lines of at most 1000 characters, so a message could not carry binary files, images, or most non-English text. Early users worked around this by converting attachments into printable characters by hand, and the Internet's growth made the problem more pressing. Text files were usually pasted into the message body.

The Multipurpose Internet Mail Extensions (MIME) solved most of these problems without replacing SMTP. The first MIME specification was published as RFC 1341 in 1992, and its successor, RFC 2045, appeared in 1996. MIME defines a set of headers, most importantly Content-Type, which names the media type of a body part, and Content-Transfer-Encoding, which states how that part has been converted for transport. A message can be a multipart structure in which each part has its own type and encoding, so a plain-text body, an HTML version, and an attached file can share one message separated by boundary strings. RFC 2045 defines the transfer values 7bit, 8bit, binary, quoted-printable, and base64, but only the last two actually transform data. The identity values merely describe what the data already is and whether the transport can carry it.

The two transforming encodings serve different purposes. Quoted-printable keeps mostly ASCII text readable and represents each non-ASCII byte as an equals sign followed by two hexadecimal digits, which suits European-language prose with occasional accented letters. Base64 maps every three bytes of input onto four printable characters, so it can carry any binary content, but the output is about a third larger and is unreadable without decoding. Mail clients often choose base64 for attachments and quoted-printable for text. Non-ASCII words in headers, such as a Japanese subject line or a name with diacritics, are handled by separate "encoded-word" syntax defined in RFC 2047, which wraps the text in a charset label and an encoded payload.

Internationalized email, the work of the IETF in the 2000s and 2010s, goes further by allowing non-ASCII characters in addresses and headers themselves. RFC 6531, published in February 2012, defines the SMTPUTF8 extension, which a server advertises in its EHLO response and which lets the envelope addresses contain UTF-8. RFC 6532 permits raw UTF-8 in most header fields, so that display names, subjects, and the local part of an address can be written in many scripts. Until these extensions are widely deployed, a sender may need to convert an international domain name to its ASCII form using Punycode, while local parts with non-ASCII characters are only usable when both ends support SMTPUTF8. Some servers also require the 8BITMIME extension before they will accept 8-bit content, and sending services may rewrite messages in ways that corrupt 8-bit bodies.

Compatibility problems persist in practice. Although the standards do not set a fixed maximum message size, providers impose their own limits on total size, attachment count, and permitted file types, and these limits differ from one service to another. A message that is acceptable to one provider may be rejected, truncated, or converted by another, and character sets that a sender assumes are not always declared or interpreted correctly. For these reasons, many developers and organisations treat MIME-compliant, ASCII-safe encoding as the default choice even when the recipient is known to support Unicode.

Security and Sender Authentication

Encryption between mail servers is usually negotiated with STARTTLS, an SMTP extension that RFC 3207 published in 2002 to upgrade a plaintext session to TLS. The upgrade is opportunistic. The server advertises the option in its capability list, and that list travels before any encryption exists, so an attacker on the path can remove the offer and force plaintext delivery. A sending server that sees no offer usually delivers the message unencrypted rather than refusing it, because delivery is prioritized over security. Protocols such as MTA-STS and DANE were developed to let domains require TLS and to report failures, but their adoption is uneven, and many messages still cross some hops without enforced encryption.

Sender Authentication

SMTP originally let any host claim any address in the sender field, so authentication was added as a layer on top. SPF (RFC 7208) lets a domain publish a DNS TXT record that lists the servers permitted to send for it. The receiving server compares the connecting address with that list, using the envelope sender domain. SPF has practical limits: a single evaluation may trigger at most ten DNS lookups, and forwarding often breaks it, because the forwarding server is not in the original domain's list. DKIM (RFC 6376) takes a different approach. The sending system signs selected headers and the body with a private key, and the matching public key is published in DNS under a selector. A valid signature shows that the signing domain vouched for the content and that it was not altered in transit, but it says nothing about whether the signer is trustworthy.

DMARC Alignment and Policy

SPF and DKIM check identities that users rarely see. SPF checks the envelope return path, and DKIM checks the domain named in its signature. DMARC (RFC 7489, published in 2015 as an informational document) connects these results to the From address that the recipient reads. Its central requirement is identifier alignment: a message passes only if SPF or DKIM passes and the authenticated domain matches the From domain. In relaxed mode the two must share an organizational domain, while strict mode requires an exact match. Without alignment, a spoofer could pass SPF with a domain of their own while displaying someone else's name. A domain owner publishes its DMARC policy in a DNS record, choosing among none, quarantine, and reject, and can request aggregate reports. The optional percentage tag limits the policy to a share of failing mail. A successor draft tightens guidance for domains that use reject, advising them not to depend on SPF alone because forwarding weakens it.

Content Encryption and Its Limits

PGP and S/MIME provide end-to-end protection of message content, including confidentiality through encryption and integrity through digital signatures that recipients can verify. Their use remains narrow. Users must manage keys and certificates, many webmail services offer weak or no native support, and encrypted content cannot be indexed by the provider's search or recovered by an administrator unless keys are escrowed. Even when the body is protected, metadata is still exposed. Every relay must read the envelope addresses to route the message, and providers can observe who wrote to whom and when. In common setups, outer headers such as the subject line are also left readable. As a result, authentication and encryption protect the content and the claimed identity of the sender, but they do not hide the communication pattern from the infrastructure that carries it.

Spam, Phishing, and Filtering

Unsolicited bulk email has been a persistent problem since the late 1970s. On 3 May 1978, a marketer at Digital Equipment Corporation sent a promotion for an open house on DECSYSTEM-20 computers to several hundred users of the ARPANET, and spam is generally traced to that message. Its reported sales figure, often cited as about $13 million, is hard to verify, but recipients reacted with anger and network administrators warned the sender against mass mailings. Estimates of spam's share of total traffic vary widely, from about 60 percent in 2017 to roughly 90 percent in other estimates, because the figures depend on how messages are counted. The core economic problem has stayed the same: sending one more message costs the sender almost nothing, while the time and attention needed to deal with it fall on the recipient.

Filtering Techniques

Mail providers and administrators combine several defences. Blocklists list IP addresses or domains known to send unwanted mail, and the receiving server consults them through DNS before accepting a message. Early public lists such as the MAPS blackhole lists appeared in 1996. Reputation scoring weighs a sender's history, sending volume, complaint rates and authentication results rather than the content of one message. Content analysis looks at headers, links, attachments, images and suspicious wording.

Statistical classifiers are now central. The naive Bayes classifier applies Bayes' theorem to individual words or tokens, estimating how likely each token is to appear in spam and in legitimate mail, then combining those estimates into an overall probability. The method is "naive" because it treats the tokens as independent of one another. In his 2002 essay "A Plan for Spam", Paul Graham popularized a variant that uses only the handful of tokens whose probabilities are farthest from neutral, so that padding a message with ordinary text has limited effect. Such filters learn from user corrections, which makes them adaptive but also means their accuracy depends on the quality of feedback they receive.

Senders adapt in turn. Research presented in 2005 showed that adding words that are more typical of legitimate mail could let spam pass a naive Bayes filter, a tactic often called Bayesian poisoning. Attacks that depend on feedback from the recipient's server, such as bounce messages, are more effective, which is one reason mail systems try to avoid revealing delivery outcomes to senders. Filtering therefore becomes an ongoing contest rather than a solved problem, and classifiers are increasingly combined with other machine learning models and cybersecurity tools.

Phishing and Business Email Compromise

Phishing uses messages that imitate a trusted organisation, often with a forged display name, a look-alike domain or a link to a counterfeit login page, in order to collect passwords or other credentials. Because the aim is to obtain access to accounts rather than sell a product, phishing messages are usually sent in small numbers and aimed at specific people.

Business email compromise (BEC) is a more targeted form of fraud. Attackers pose as an executive, supplier or known contact and ask an employee to wire funds, change bank details or send payroll data. Such schemes rely on social engineering rather than malware, which is why they can bypass technical controls that screen for malicious attachments. The FBI's Internet Crime Complaint Center has reported BEC losses of nearly $3 billion for 2023 and more than $3 billion for 2025. Its 2025 report also described AI-enabled cases, in which generated text, voice cloning and fabricated messages make impersonation more convincing.

Trade-offs of Filtering

Every filter makes errors. A false positive sends a legitimate message to the spam folder or rejects it outright, and the consequences can be serious when the lost message is a password reset, a contract or an invoice. A false negative lets fraudulent or harmful mail reach the inbox. Administrators tune these thresholds according to their risk tolerance, which means the same message may be delivered at one provider and blocked at another.

Aggressive policies also shape who can reach whom. Small or new senders, organisations with poor reputations and users of shared hosting can be blocked for reasons that lie outside their own conduct, while large providers gain influence over which messages are seen. Blocklist criteria are often opaque, and disputes over delisting can be difficult to resolve. Spam control is therefore not only a technical question but also a matter of competition and access to communication.

Social, Workplace, and Commercial Uses

Office correspondence and record-keeping

Email spread through offices in the 1980s and early 1990s, mainly inside large organisations, universities, and government bodies. Early corporate systems were often proprietary and could not reach outside networks, so their value depended on how many colleagues were on the same platform. The Smithsonian's experience shows the transition: its internal systems were joined to the Internet in July 1992 and adopted SMTP, and a 1994 directory listed about 4,800 addresses across ten different systems. Staff were still spread across incompatible platforms, and the institution's own estimate was that only about half to three-fifths of its staff had email at that time. Once interoperability arrived, email began to replace the memo, the fax, and much postal correspondence in business. Its records also changed status: messages that people had first treated as informal began to be kept as evidence of decisions and agreements.

The 1990s also saw the emergence of commercial services and tools for handling volume. Web-based services such as Hotmail (1996) and Yahoo Mail (1997) let people reach email without a workplace account, and Microsoft Outlook became a common desktop client in business settings. Companies that received large numbers of customer messages began to need specialised software and trained staff. One example is the EchoMail platform, introduced in 1994 to analyse and categorise incoming messages, which was adopted by large retailers and telecommunications firms in the following years.

Etiquette and workplace norms

Expectations about how email should be written and used developed alongside its adoption, and these conventions are usually grouped under the term email etiquette. They cover matters such as the tone of a message, the length and clarity of a subject line, how quickly a reply is expected, and when a message should be copied to additional recipients, a practice that can spread responsibility or make a message more public. Norms also vary by organisation and culture, and disputes over unnecessary copying, late-night messages, or "reply all" chains have been a recurring source of friction in workplaces. Because email is asynchronous, its etiquette often centres on balancing responsiveness against the interruptions that constant messaging creates, a tension that later drove parts of the shift toward other tools discussed in the alternatives section.

Mailing lists, newsletters, and transactional messages

Email is central to online commerce because it carries two very different kinds of message. Mailing lists and newsletters are sent to groups who have subscribed, and they are used for marketing, community discussion, and information distribution. Transactional messages are different: they are triggered by a specific action, such as a purchase, a sign-up, or a request to reset a password, and their main purpose is to confirm or convey information about that action. Typical examples include order confirmations, purchase receipts, shipping notifications, two-factor verification codes, and account alerts. Many online retailers and service providers depend on these messages to operate, which is why email delivery problems can directly disrupt a business. Because such messages are time-sensitive, senders typically separate them from marketing traffic, often by using distinct sending domains, so that a complaint about a promotional campaign does not affect the delivery of password resets.

Email as an account identifier

Email addresses have become the usual identifiers for online accounts, and they are also the usual route for recovering them. A password reset normally sends a time-limited link to the registered address, and services use the address to confirm identity, deliver security notices, and verify new devices. As a result, control of an address can act as a key to many other services. If a person loses access to an address, through a forgotten password, an expired subscription, or a compromised account, they may be unable to recover linked accounts for shopping, banking, or social networks. The same dependency makes an email account an attractive target for cybersecurity attacks, since taking over the inbox can allow an attacker to reset passwords across other services. For this reason, the reliability and security of an address often matter more to users than its original purpose as a message channel, and the role of email in e-commerce and digital identity has increased the consequences of such failures.

Legal, Regulatory, and Privacy Dimensions

Anti-spam law is the most direct form of email regulation. In the United States, the CAN-SPAM Act of 2003 is the main federal statute for commercial email, and the Federal Trade Commission enforces it. Unlike privacy regulations in Europe and Canada, CAN-SPAM operates on an opt-out framework: prior consent is not required to send commercial email, but recipients must be given a clear, functional way to stop receiving it. In practice, a sender may keep mailing a recipient until that person objects. The Act also imposes content rules. Commercial messages must not carry false or misleading header information, the message must be identified as an advertisement, and it must include a valid physical postal address. Opt-out requests must be honored within 10 business days, and that window includes weekends and holidays. Transactional messages such as receipts and account notices are largely exempt from CAN-SPAM's requirements, though they must still contain truthful information. The Act also applies to business-to-business mail, since it has no exemption for business-to-business messages.

Data protection law takes a different approach, treating the email address itself as information about a person. Under the EU's General Data Protection Regulation, personal data covers information about a living individual who can be identified directly or indirectly. An email address is personal data under the GDPR whenever it identifies a natural person, for example firstname.lastname@company.com. A generic address such as info@company.com usually is not, because it points to an organisation rather than one individual. The protection extends to content and metadata as well. The content of email messages, file attachments, subject lines and even metadata (e.g. timestamps, IP addresses) may also contain sensitive information. Organisations that handle such data must establish a lawful basis for processing, set retention and deletion rules, and handle requests from individuals who exercise their rights. That means email systems often need controls for lawful basis, transparency, security, retention and deletion, and user rights handling. Article 32 of the GDPR requires appropriate technical and organisational measures to protect personal data, which in email contexts commonly means encryption and access restrictions. Other regimes take a similar view. According to the GDPR and CCPA, email addresses are personally identifiable information (PII).

Because email records who communicated, what they knew and when they acted, it is routinely treated as evidence. As the primary medium for business communication, email can be used to document an individual's knowledge and motivation as well as the timing and intent of actions and business transactions. In litigation, the parties must identify and preserve relevant electronically stored information through e-discovery. The duty to preserve is typically triggered as soon as litigation is reasonably foreseeable, and the most common preservation tool is a legal hold. Destroying evidence after that point is known as spoliation and can lead to sanctions. In one 2020 case, the Southern District of New York found that defendants had a duty to preserve relevant ESI at the time of their deletion, which occurred a year into the litigation. The court also noted that the defendants had failed to suspend their routine document retention/destruction policy. Routine deletion is not unlawful in itself. Under a documented policy, an organisation may destroy email, but the destruction stops immediately if an incident occurs which could give rise to a lawsuit. A retention policy can also affect admissibility. It may help show that a message was generated and retained in the ordinary course of business, which bears on the business records exception to the hearsay rule. Regulated sectors face additional demands, since financial services, healthcare, public sector, and other regulated industries often impose additional demands on email preservation and access. These can include specific audit logging, retention periods, encryption expectations, and breach notification timelines.

Employers and governments can also monitor or archive email, and this raises questions about privacy and the limits of surveillance. Organisations usually own the systems and accounts that staff use, and many archive mail for compliance, security, and investigation. The rules on reading or retaining employees' messages, including notice requirements and the permitted scope of review, differ considerably between jurisdictions. Public authorities may obtain email from providers through legal process, and both the content and the metadata can be sought. Debates continue over how far such access should extend, particularly regarding bulk collection and the use of encryption that limits what providers can read. These questions connect email to wider concerns about human rights and data privacy.

Alternatives, Competition, and Future Development

Competing forms of communication

Email has lost ground in many informal and real-time settings, but it has not been replaced. Instant messaging and team collaboration platforms now carry much of the quick exchange that once went by email. One comparison guide describes email as the default for formal online business messages, while also noting that Slack keeps growing as a team communication platform (Email is the global standard for online messages (particularly in business) and of the many email management systems, Gmail is probably the most widely used. Even so, Slack continues to grow as a popular platform for communication among teams.). Critics argue that the shift has not been an unqualified gain. A 2025 commentary contends that chat tools, which were expected to replace email, produced a new overload linked to continuous communication.

Email's remaining strengths are largely structural. Threads can be searched and reviewed later, and messages can carry a formal record, which is why many organizations still reserve email for decisions, contracts, and external correspondence. Estimates of total daily volume vary widely between sources. One vendor puts it at over 376 billion emails are sent every day, while another reports more than 347 billion emails sent daily. The discrepancy reflects differing methods rather than a real shift in scale, and neither figure is independently verified.

Why email endures

Email has persisted because it is open, decentralized, and interoperable. Any organization can run a mail server and exchange messages with any other, so no single vendor controls the network. Its role as a universal account identifier reinforces this. Because addresses are used for sign-in, password recovery, and receipts across many services, switching away from email is costly for individuals and businesses, even when a newer tool would be more convenient for a particular task.

Provider competition and interoperability

Providers now compete on storage capacity, search quality, spam filtering, and integration with calendars and office software. These features can make a service more useful, but they often depend on proprietary extensions or closed ecosystems. When a feature works well only inside one suite, users and administrators may find that it does not carry over cleanly to other clients or domains, which weakens the interoperability that gave email its durability.

Authentication and encryption

The most concrete recent change has been the tightening of sender requirements. In February 2024, Gmail and Yahoo began enforcing rules for high-volume senders. Google defines a bulk sender as anyone sending around 5,000 messages per day to personal Gmail accounts. Those senders must use SPF, DKIM, and DMARC, keep spam complaints below 0.3%, and offer a one-click unsubscribe option. Details of these mechanisms are covered in email authentication. Enforcement has gone beyond warnings: one vendor reports that Google's rules were enforced as of November 2025 and that non-compliant emails will face temporary and permanent rejections. Earlier, according to Mailgun, Gmail's 2022 authentication requirement was followed by a 75% drop in unauthenticated messages received by Gmail users. Transport encryption has also been tightened in practice; Google's stated requirements include email delivery to Google should happen over an encrypted TLS connection. End-to-end encryption, however, remains far less common than transport encryption.

Generative AI and automated messages

Generative AI has changed the economics of spam and phishing, and the available statistics are contested. A security-industry source estimates that over 51% of spam emails are now AI-generated, while another researcher estimate holds that by early 2026, roughly 82.6% of phishing messages were generated or assisted by AI. These figures come from vendors and secondary research, and their definitions differ, so they should be read as indicative rather than precise. The practical concern is that AI makes fraudulent messages more fluent and personalized, which weakens the older advice to look for poor grammar.

Automated senders are also creating new problems. In September 2026, reporting described an AI-agent platform whose service has been flooding inboxes with emails offering services no one asked for. Filters are responding by moving away from content keywords. They analyze sender behavior, engagement signals, and content context. Open questions remain about how to label mail sent by software on a person's behalf, how recipients should verify its origin, and whether existing authentication standards are sufficient. The answers will likely shape the next revisions of the standards that have held email together since the 1980s.

References

1. History of emailen.wikipedia.org
2. (PDF) Electronic Mail and Text Messaging in CTSS, 1965-1973researchgate.net
3. Electronic Mail and Text Messaging in CTSS, 1965 - 1973multicians.org
4. Timeline of Early Email - Matt Rickardblog.matt-rickard.com
5. Official Biography: Raymond Tomlinson - Internet Hall of Fameinternethalloffame.org
6. The First Email Was Sent in 1971missedhistory.com
7. Ray Tomlinson and the Invention of Networked Email (1971)ineedthatbadge.com
8. On This Day: Birth of Email Spamyourstory.com
9. Gary Thuerk’s 1978 ARPANET email still explains the spam problemwebiano.digital
10. Ray Tomlinsonen.wikipedia.org
11. The First Mass Unsolicited Commercial E-mail, i.e. Spam - This Day in Tech Historythisdayintechhistory.com
12. Email spamen.wikipedia.org
13. RFC 772: Mail Transfer Protocolrfc-editor.org
14. datatracker.ietf.orgdatatracker.ietf.org
15. RFC 821 - Simple Mail Transfer Protocoltools.ietf.org
16. Standard for the Format of ARPA Internet Text Messagesietf.org
17. RFC 822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGESrfc-editor.org
18. RFC 5321: Simple Mail Transfer Protocolrfc-editor.org
19. RFC 5321 SMTP Standard: Developer's Complete Referenceresources.mailertogo.com
20. RFC 821: Simple Mail Transfer Protocol (obsoleted by ...smtpedia.com
21. RFC 5321 SMTP Protocol: Commands, Reply Codes, ESMTP Extensionssmtpedia.com
22. Emailen.wikipedia.org
23. Sender Rewriting Schemeen.wikipedia.org
24. Mail Transfer Agent - an overviewsciencedirect.com
25. What Is an Email MTA? A Guide to Mail Transfer Agents - Transactional Email API Service For Developersmailgun.com
26. Mail Transfer Agent: What Is an MTA And How Does It Workboostinbox.com
27. What is an MX record? - Zoho Mail Glossaryzoho.com
28. Mail transfer agent guide: MTA mail server and testingmailslurp.com
29. RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodiestools.ietf.org
30. RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodiesrfc-editor.org
31. Quoted-printableen.wikipedia.org
32. MIMEen.wikipedia.org
33. Email attachmenten.wikipedia.org
34. RFC 1341 - MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodiesdatatracker.ietf.org
35. Really simple mail transport protocolimage-ppubs.uspto.gov
36. Sending raw email using the Amazon SES API v2 - Amazon Simple Email Servicedocs.aws.amazon.com
37. Enhanced electronic mail system including methods and apparatus for identifying mime types and for displaying different iconsimage-ppubs.uspto.gov
38. RFC 6531: SMTP Extension for Internationalized Emailrfc-editor.org
39. RFC 6532mailertogo.com
40. RFC 6531 SMTPUTF8: Internationalized Email Address Extensionsmtpedia.com
41. Email Address Internationalization - ICANNWikiicannwiki.org
42. RFC 3207mailertogo.com
43. RFC 3207: STARTTLS — DMARC Analyzerdmarc-analyzer.net
44. (PDF) SMTP Require TLS Optionresearchgate.net
45. Opportunistic TLSen.wikipedia.org
46. RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)datatracker.ietf.org
47. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)rfc-editor.org
48. What Is DMARC Alignment, And How Does It Workdmarcreport.com
49. DMARC RFC Explained: The Foundation Of Email Authenticationpowerdmarc.com
50. DMARC Policy Guide: SPF, DKIM & Rollout - DKs Enterprisesdkent.net
51. Email Authentication Mechanisms: DMARC, SPF and DKIMnist.gov
52. SPF vs DKIM vs DMARC: Email Authentication Explainedadaptivesecurity.com
53. DMARC, SPF and DKIM Setup Guide: Get to p=reject Safelyconsilien.com
54. SPF, DKIM, and DMARC Explainedcli.nylas.com
55. History of email spamen.wikipedia.org
56. May 3: Earliest Known Case of Spamcomputerhistory.org
57. 40 years on from the first spam email, what have we learned? Here are 5 things you should know about junk mailweforum.org
58. The History of Spam Email: Origins, Evolution, and Impactspaceship.com
59. Naive Bayes classifieren.wikipedia.org
60. 23. Practical: A Spam Filtergigamonkeys.com
61. Paul Graham on Fighting Spam - Slashdotdevelopers.slashdot.org
62. Bayesian poisoningen.wikipedia.org
63. Key Takeaways from the 2023 FBI IC3 Report: Business Email Compromise Losses Jump to Nearly $3 Billionabnormal.ai
64. Cybersecurity is everyone's job: the human layer your fund can't automateecsoffice.com
65. Bank of America cites $20.8 billion in FBI-reported 2025 internet crime losses - The Money Overviewthemoneyoverview.com
66. FBI's 2025 Annual Cybercrime Report Shows U.S. Losses Reach Nearly $21 Billion; BlackCloak Addresses Top Two Issues of Investment Fraud and Business Email Compromiseprweb.com
67. FBI Issues Warning About The Business Email Compromiseforbes.com
68. When Did Email Become Popular? A Brief History of Email's Rise to Dominancemailfloss.com
69. The History of Email at the Smithsoniansiarchives.si.edu
70. Email @ 50 Series: A Brief Historyvia.studio
71. The History of Email Marketing: 1971 to the AI Inboxknak.com
72. Email managementen.wikipedia.org
73. What is a Transactional Email?mailchimp.com
74. Everything You Need to Know About Transactional Emailsbenchmarkemail.com
75. Transactional Email Guide: Best Practices & Setupbrevo.com
76. Top Transactional Email Examples to Boost Your Businesstruelist.io
77. Email marketingen.wikipedia.org
78. CAN-SPAM Act Requirements: 7 FTC Rules Every Email Marketer Must Follow to Avoid $53,088 Finesadaptivesecurity.com
79. The CAN-SPAM Act: A complete 2026 compliance guidetranscend.io
80. Is an Email Address Personal Data Under the GDPR?lawandmore.eu
81. Data protection and email: 7 steps to ensure GDPR complianceftapi.com
82. GDPR email compliance requirements for product teamsmailslurp.com
83. Are Email Addresses Personal Data?termly.io
84. What is eDiscovery in Microsoft Office 365?mimecast.com
85. System and method to optimally apply local retention in a remote repositoryimage-ppubs.uspto.gov
86. Tag:Email - Electronic Discovery Lawediscoverylaw.com
87. Email archivingen.wikipedia.org
88. BY ADAM I. COHEN DAVID J. LENDER ELECTRONIC DISCOVERY PRACTICE GUIDELINESweil.com
89. E-Discovery Email Security: How to Protect Sensitive Case Emails in Litigationtrustifi.com
90. Email Anti Spam Lawsfoundersworkbench.com
91. Anti-Spam Guidancefairfield.edu
92. The CAN-SPAM Act: Compliance Guide with Best Practicesusercentrics.com
93. When to Use Email vs. Slack? 7 Team Communication Tipsgmelius.com
94. Chat has replaced email, and it's even worseduperrin.com
95. 2026 Guide: Avoid AI Spam Filters with Smart Email Sequencesreply.io
96. Yahoogle: New Bulk Sender Requirements in 2024 - Transactional Email API Service For Developersmailgun.com
97. New Google and Yahoo Email Requirements for 2024: Explained - BuzzStreambuzzstream.com
98. Google And Yahoo Email Authentication Requirements 2026powerdmarc.com
99. Gmail And Yahoo Inbox Requirements & What They Mean For Senders - Transactional Email API Service For Developersmailgun.com
100. The new Gmail and Yahoo requirements for email delivery (2024)dmarcwise.io
101. AI-Generated Email Detection: The New Spam Filter Front Line and What It Means for Your Inbox Securitygetmailbird.com
102. AI Now Writes 82% of Phishing Emails Hitting Inboxesgblock.app
103. AI Agent Platform Reinvents Spam, Floods Inboxes Worldwide404media.co
104. New Bulk Sender Requirements from Gmail and Yahooemailonacid.com
105. Slack vs Email - Talking To Your Customersm.io