The wording of the first message has been forgotten, while its address symbol is recognized around the world. That unusual combination brings the history of email into focus. What mattered in 1971 was not a grand announcement but the ability to send a message to someone using another computer. Ray Tomlinson connected existing capabilities and gave the @ sign a new job. The experiment provided a foundation for a form of communication that would later reshape research, business operations and relationships with customers.
The familiar statement that Tomlinson “invented email” in 1971 nevertheless needs qualification. Electronic mail within individual computing systems was older. Nor did Internet email, with standardized formats, transfer protocols and convenient applications, arrive fully formed that year. Tomlinson’s particularly important contribution concerned personal messages between networked computers. For marketing history, its significance lies in expanding what communication could do. A research network did not thereby become an advertising channel. Between technical reachability and a useful customer relationship lay further developments and decisions.
Before 1971: Mail within a shared computing system
At the Massachusetts Institute of Technology, Tom Van Vleck and Noel Morris developed a MAIL command for the Compatible Time-Sharing System, or CTSS, in 1965. Users could leave text in another user’s mailbox on the same system for later reading. Van Vleck distinguishes this from a facility for immediate terminal messages. The MAIL command was written that summer and installed in the autumn; later conveniences were not yet included (Van Vleck, 2012).
This changes how the beginnings should be understood. Electronic communication did not require every participant to own a computer. Several people could use terminals to access a shared system. The technical boundary of local mail was therefore not identical to the distance between its users. People in different places could access one system, while two computers in the same room remained separate systems. In this context, “local” describes membership of a computing environment rather than necessarily indicating physical proximity.
An important communication principle was already present: sender and recipient did not need to be active simultaneously. A stored message bridged different working schedules. That was a different capability from immediate conversation and from simply moving a file without identifying its intended recipient. Reducing email history to one first moment obscures these distinctions. The useful historical question is which function existed and which boundary a subsequent development overcame.
It is equally important to avoid reading later conventions into an early command. A familiar name can conceal substantial differences in scope. Calling two systems “mail” does not establish that they provided the same facilities, just as recognizing differences does not make the earlier implementation irrelevant. The relationship has to be reconstructed rather than assumed.
BBN, TENEX and Tomlinson’s working environment
Tomlinson studied electrical engineering at Rensselaer Polytechnic Institute and then MIT. In 1967 he joined Bolt Beranek and Newman, generally known as BBN. His work included the TENEX time-sharing operating system and networking software. The Internet Hall of Fame’s official biography explicitly connects his 1971 contribution with combining SNDMSG and CPYNET (Internet Hall of Fame, n.d.).
That environment offers a better explanation than a retrospective image of an isolated genius. An engineer could draw on operating systems, user accounts, file management, terminals and an existing network connection. His innovation had to make those components work together. In infrastructure, a decisive improvement often emerges when previously separate capabilities are connected effectively. Recognizing that does not diminish the individual contribution. It identifies more precisely what the contribution accomplished.
Elizabeth Feinler and John Vittal’s chronology, published by the Computer History Museum, places the network demonstration in autumn 1971. It describes Tomlinson combining TENEX’s SNDMSG with CPYNET’s transfer capabilities so messages could be appended to a mailbox on another TENEX computer. The destination included a host name following the @ sign (Feinler and Vittal, 2022).
An electronic mailbox was not a miniature version of today’s webmail service. The immediate operation involved adding information to an appropriate stored location under controlled conditions. Modern folder interfaces, mobile notifications and campaign applications should not be projected backwards into that setting. Technical relationships extending across decades do not mean that every familiar feature existed at the beginning.
This also clarifies the nature of a useful technical combination. It was not enough that one program could handle local messages and another could move files. Their interaction had to preserve the intended destination and make the message available in a usable form. The historical importance lies in the working connection, rather than merely in the existence of the separate ingredients.
What the first message does and does not establish
Tomlinson’s own account describes tests between two adjacent machines connected through the ARPANET. He did not remember the exact text. The frequently repeated string “QWERTYUIOP” was a probable example rather than a preserved transcription. He subsequently explained the capability to his group, and network mail was distributed with a TENEX release in early 1972 (Tomlinson, 2016).
A small qualification makes a large historical difference here. Saying that the first message was probably an unremarkable test string does not justify displaying that string as an authenticated original quotation. An approximate date should not become an exact documented day through repetition either. The experiment remains significant even though its first payload is unavailable. Not every innovation leaves a ceremonial founding document.
The machines’ physical proximity does not make the event less of a network experiment. The relevant issue was the transmission path between separate systems. That observation also offers a useful opportunity for a museum display: a visually undramatic arrangement can reveal an important technical boundary. A long geographical distance would have produced a more spectacular story, but it was not required to demonstrate the capability.
Even a preserved first message would not independently explain everything that followed. It could establish a successful test. Evidence about distribution, adoption and business significance would require other sources. Demonstrating that something works and demonstrating that it has become routine within a community are different historical tasks.
This is why the absence of a memorable sentence is not simply a disappointing gap. It redirects attention from the contents of a single message towards the capability that made it possible. The historian can describe the achievement without inventing a dramatic scene to substitute for missing evidence.
Why the @ sign mattered
Tomlinson did not invent the graphic form of @. The Museum of Modern Art describes earlier commercial uses and its appearance on typewriter keyboards. Network addressing gave the existing character a different function. The symbol’s remote origins remain disputed, so an account of its use in email need not depend on selecting one definitive ancient origin story (Museum of Modern Art, n.d.).
The solution separated two questions that needed answers together: which user was intended, and on which computer could that user be found? A name alone was inadequate when similar local identifiers might exist in several places. Linking the user identifier to a host turned a name intelligible within one system into a network destination. That is the functional significance behind the conspicuous symbol.
In his 2009 oral-history interview, Tomlinson recalled that most of the necessary capabilities already existed. He discussed distribution through TENEX and the usefulness of asynchronous communication within an initially small research community. Popularity within that group, he emphasized, did not amount to an immediate worldwide impact (Tomlinson, 2009).
The address can be interpreted as a small interface between people and infrastructure. It provides an intelligible destination without requiring the person composing a message to understand every detail of its route. This helps explain why an inconspicuous character could become more culturally visible than the program in which its new role was implemented. Its familiarity reflects later diffusion rather than measuring the size of the original software change.
The distinction also matters when recognizing authorship. Reusing an existing symbol can constitute a consequential design decision without amounting to creating the symbol itself. A precise account can acknowledge the novelty of the application while retaining the character’s earlier history.
Other mail architectures were being considered in 1971
On 20 July 1971 Richard W. Watson of the Stanford Research Institute issued RFC 196, “A Mail Box Protocol”. It proposed exchanging messages and documents between sites without requiring knowledge of each site’s file conventions. Immediate or deferred printing and numbered mailboxes featured in the design. The document addressed a broader document-handling problem than the personal message alone (Watson, 1971a).
Watson revised the approach in RFC 221 on 25 August 1971. Responding to comments, he sought closer alignment with the File Transfer Protocol. The revision discussed appending to a file and a naming convention intelligible across sites. It provides contemporary evidence of architectural proposals being debated and altered (Watson, 1971b).
These documents make the history more demanding and more interesting. A dated specification is not automatically the earliest working implementation. A working application is not automatically a universally agreed network convention. The source types answer different questions. Watson’s documents reveal an active design process, while Tomlinson’s account concerns a particular implementation. Both contributions can be recognized without forcing them into one supposedly identical event.
The underlying model was not predetermined either. Electronic mail might be understood as a document service, a means of delivering output to remote equipment or a message addressed to a person. The priorities in a specification reveal something about the institutions and users it was intended to serve. The later familiarity of the personal inbox should not conceal that earlier openness.
An invention narrative organized around a single finished object is therefore poorly suited to the subject. Several partially overlapping problems were being addressed. Some proposals supplied useful ideas without becoming the enduring solution. Their historical value does not depend on claiming that every detail survived.
1973: From separate implementations to common rules
Michael D. Kudlick’s RFC 469 summarizes a meeting held at SRI-ARC on 23 February 1973. Discussion included multiple recipients, return addresses, authorship and recording messages. The document explicitly identifies user@host as a common address form. It records coordination among participants rather than simply development within an individual application (Kudlick, 1973).
On 13 June 1973 Jim White presented a more extensive proposal in RFC 524. He described existing delivery through the FTP commands MAIL and MLFL and explicitly invited comments on his richer alternative. A proposal soliciting criticism and acknowledging possible defects does not establish that every suggested facility was subsequently adopted everywhere (White, 1973).
That distinction is central to infrastructure history. A network can contain many useful local implementations and still encounter difficulties at their boundaries. Different recipient rules or responses complicate exchange. Common conventions create a separate benefit by reducing what has to be negotiated afresh in every interaction. Applications can remain different while using agreed interfaces to communicate.
Communication infrastructure can consequently be interpreted as repeatable interoperability. One successful delivery establishes a connection between two places. A dependable system must accommodate many potential connections and respond sensibly when something goes wrong. That expansion is less visually memorable than the first message, but it requires explanation in an account of email’s later importance.
Sender, subject and date: The development of headers
RFC 561, dated 5 September 1973, was written by Abhay Bhushan, Ken Pogran, Ray Tomlinson and Jim White. It identified inconsistent formats for information such as author, title and date as an obstacle to automated processing. The proposal specified a shared structure separating headers from message text, including sender, date and subject fields (Bhushan et al., 1973).
Theodore H. Myer and D. Austin Henderson extended this work in RFC 680 on 30 April 1975. They emphasized the relationship between human readability and machine processing. Shared fields could remain useful even where applications did not yet process them automatically. Their document presented another development step while leaving room for experience and experimentation (Myer and Henderson, 1975).
The importance is understandable without specialist knowledge. A person can often infer who wrote an irregularly formatted letter and what it concerns. Software needs reliably recognizable structures. As messages accumulate and require sorting or other handling, identifying individual fields becomes valuable. Headers are therefore more than a decorative imitation of an office memorandum.
For later organizational communication, this provides an important foundation. A message can function both as something a person reads and as a structured object that software processes. Different workflows become possible from that combination. This does not establish that the early authors intended modern marketing automation. It identifies subsequent possibilities extending beyond the immediate design purpose. Historical explanation should distinguish a later consequence from an original intention.
Nor does the existence of a field establish the quality of its contents. A subject line may be structurally recognizable while remaining unhelpful to its reader. Consistent data structure and effective communication are related requirements that cannot substitute for one another.
From delivery to manageable correspondence
Craig Partridge’s technical history describes Larry Roberts developing a tool for selective message reading in 1972. Subsequently, John Vittal’s MSG combined handling functions, with easier replies particularly important. Development therefore concerned managing growing correspondence as well as transporting it. Partridge treats claims about resulting traffic increases with explicit evidential reservations (Partridge, 2008).
The underlying problem is straightforward. Receiving one message mainly requires reading it. Receiving many creates additional tasks: finding what matters, filing completed correspondence and responding to a particular item. An application may deliver correctly while remaining awkward in everyday work. Usability has its own place in email history rather than being merely an attractive finish applied to a completed invention.
Replying also affects the social form of communication. Sending a single announcement and sustaining an exchange impose different demands. Reducing the effort required to resume an exchange can make a channel more useful for regular collaboration. This analytical inference explains why message-handling features matter without embellishing their effects with an unsupported numerical growth claim.
1977: Standards as collective work
RFC 733 appeared on 21 November 1977 under David H. Crocker, John J. Vittal, Kenneth T. Pogran and D. Austin Henderson’s names. It revised earlier formats and included references to stored address lists. Its preface describes more than twenty participants and a discussion conducted over a year using email itself as the working environment (Crocker et al., 1977).
A significant feedback process becomes visible: the communication medium helped develop its own rules. Such a community consists of more than an inventor followed by users. Participants report problems, defend useful conventions, test alternatives and establish agreements that can be implemented. This work is harder to represent on a timeline than one date, but omitting it distorts the process.
Standardization does not necessarily require every application to look identical. Common exchange rules can coexist with different local interfaces. This matters for broader adoption because cooperation becomes possible without centralizing every organizational or technical choice. Part of the achievement lies in deciding what must be shared and what can remain different.
1982: SMTP and message format address different problems
Jon Postel’s RFC 821 described the Simple Mail Transfer Protocol, SMTP, in August 1982. It specified exchanges between sending and receiving processes, including recipients, responses and forwarding through intermediaries. Its objective concerned reliable mail transfer. The specification belongs to a later development stage and should not be presented as the complete method already used in 1971 (Postel, 1982).
David H. Crocker’s RFC 822, dated 13 August 1982, addressed message format instead. It distinguished the envelope needed for transmission from the contents being delivered. It did not prescribe every participating system’s internal storage or user interface. A transfer protocol and a format specification therefore perform different functions (Crocker, 1982).
For understanding a business message, the distinction is valuable. What appears on a recipient’s screen is not identical to all the information used for transport. Likewise, a successful technical handover is not evidence that a person has read or understood the contents. This is an analytical consequence of the separate layers, rather than a claim about performance measurements used by the early developers.
It also protects marketing history from inflated interpretations. Technical delivery, human attention and business effects should not be collapsed into one event. Infrastructure can establish a route. Whether a message is welcome, understandable and relevant to action remains a further question. Improving a transfer mechanism does not automatically improve an offer or make customer communication successful.
Names and contents continued to evolve
In November 1983 Paul Mockapetris’s RFC 882 explained the domain-name system and its significance for distributed resources and Internet mail. The addressing environment developed beyond early host conventions. The familiar appearance of a present-day address should therefore not be projected unchanged into the initial experiment (Mockapetris, 1983).
Another development is documented in Nathaniel Borenstein and Ned Freed’s RFC 1341 of June 1992. MIME provided standardized facilities for multipart messages, different character sets and non-textual contents. Modern email history consequently involves more than sending simple lines of text between early machines (Borenstein and Freed, 1992).
It is useful to separate the capabilities. Identifying a recipient, locating an appropriate system, transferring a message and interpreting its contents are distinct tasks. They can build on one another without having been solved simultaneously. This makes the history less convenient but more accurate. An apparently seamless contemporary service can contain many layers of decisions whose sequence is no longer visible in everyday use.
The same observation explains why later interfaces are unreliable guides to original capabilities. One screen may combine operations developed at different times. Reading backwards from that screen risks treating a long process as a single invention.
An international perspective: Britain and Karlsruhe
The Royal Family’s digital chronology records Queen Elizabeth II sending an email during a visit to a military base in 1976. This prominent remembered use documents a particular occasion, rather than establishing that the service was generally available to the public (The Royal Family, 2019).
Germany’s Karlsruhe Institute of Technology commemorates a message from Laura Breeden received by Michael Rotert and Werner Zorn on 3 August 1984. KIT explains the CSNET connection and the difference between the sending and receiving dates. The milestone concerns that international network link; it should not imply that no electronic messages of any kind previously existed in Germany (KIT, 2014).
These examples involve different historical measures of achievement. An experimental demonstration, a prominent public use and another institution joining a network are distinct events. None replaces the others. International communication history therefore requires several timescales. A technical possibility may exist well before a particular country, organization or customer group can use it in practice.
Another international precursor lies outside computer engineering. The History of Advertising Trust dates the establishment of the British Direct Mail Advertising Association to 1927. Organized direct advertising was substantially older than network email. Its institutional history and the history of a new transmission route do not follow the same chronology (History of Advertising Trust, n.d.).
Why 1971 is not the beginning of email marketing
Sending a message to another computer did not immediately create a developed marketing practice. Further questions had to be answered: who should receive it, what relationship connected them with the sender, what value the message provided and who would handle a response. These are analytical distinctions, not a documented work programme of the developers in 1971.
A distribution facility is initially a capacity to distribute. Similar technology can support scientific discussion, internal coordination or product information. The sender’s purpose and the recipients’ expectations change the nature of the communication. Marketing history cannot therefore be deduced solely from a catalogue of software functions. It also needs evidence about actual commercial practices and their organizational context.
An invented example makes the distance clear. A manufacturer might send maintenance information to existing business partners or introduce a product to an unfamiliar audience. Both operations could use similar transfer mechanisms, yet involve different objectives, expectations and possible responses. Infrastructure explains how the information reaches a destination system. It does not independently explain why that particular information should matter to a person.
Recognizing this difference gives the technical achievement its proper place. It established an enabling capability without already containing every subsequent business model. Later commercial use should neither be credited wholesale to the initial experiment nor treated as unrelated to the infrastructure on which it depended.
An early warning whose title can mislead
Jon Postel’s November 1975 RFC 706 is titled “On the Junk Mail Problem”. It concerns unwanted messages at the Host/IMP level and the risk of overload from malfunctioning or troublesome hosts. Postel considers refusing particular sources. It is not a report of a commercial advertising email or evidence of contemporary newsletter practice (Postel, 1975).
Familiar terminology can invite anachronistic interpretation. Reading the title alone might encourage someone to project a later conception of spam into the document. Source criticism must establish which system layer and which type of message are actually under discussion. The broader tension between openness and interference can be recognized without equating different historical problems.
For later economic interpretation, the distinction remains useful. A network’s ability to carry messages does not determine whether each transmission is welcome. Another sender can use a shared capability while creating work for others. That tension follows analytically from shared infrastructure. It should not be concealed by technological enthusiasm or illustrated through an invented early advertising incident.
1995: Expectations about behaviour were documented too
Sally Hambridge’s RFC 1855, issued in October 1995 as “Netiquette Guidelines”, documented recommendations for online behaviour. The explicitly informational document distinguished personal and group communication. It also discussed burdens imposed on recipients by unsolicited advertising. This later source separates social expectations surrounding use from the capability to transfer information (Hambridge, 1995).
The historical inference is that a communication medium becomes usable through more than technical operation. Participants also need expectations about when a message is appropriate and what recipients are meant to do with it. Such expectations can vary by community and purpose. Moving technology into another setting consequently involves more than copying software; people need to understand the relationship in which communication occurs.
Consider a supplier sending information specifically requested by a long-standing customer. The same information could be distributed to numerous strangers with little alteration to the message file. The relationship would nevertheless differ. Technical similarity establishes neither equal value nor an identical response. This is an analytical example, not a business transaction documented in the source. The historical guidelines are also being examined as evidence of their period, rather than presented as current legal or implementation advice.
Email predates the World Wide Web
Email and the Web are easily combined into one everyday idea of online communication. CERN dates Tim Berners-Lee’s invention of the World Wide Web to 1989. Network email belongs to a substantially earlier layer. A browser was not a prerequisite for Tomlinson’s 1971 experiment (CERN, n.d.).
This chronological distinction changes the account of digital marketing too. Not every digital contact channel originated with websites. Services could later be connected without sharing an origin. An email referring its reader to a website combines different developments. Their later integration should not erase their different beginnings.
What the surviving evidence can establish
MIT’s CTSS documentation explains how dispersed paper materials were digitized and source listings recovered from backup tapes. It also acknowledges gaps. Reconstructing early software history therefore depends on surviving manuals, notes and program versions as well as familiar names (MIT CSAIL, n.d.).
Distinguishing the history of practice from the history of ideas also features in Jones and Tadajewski’s preface to The Routledge Companion to Marketing History. Applied here, that perspective helps separate implementation, standardization and commercial use. One important publication or celebrated person does not automatically account for every activity subsequently associated with a concept (Jones and Tadajewski, 2016).
Recollections, contemporary specifications and retrospective timelines should consequently be read together but with different expectations. A memory can illuminate a working environment while remaining uncertain about an exact date. A specification can establish that a feature was proposed without demonstrating widespread adoption. A museum can connect the evidence while retaining those distinctions instead of hiding them behind an apparently seamless invention story.
The historical significance of Tomlinson’s contribution
The year 1971 marks an important transition: personal computer mail could cross a system boundary. The @ sign made the additional destination visible in the address. That solution, together with many other contributions, developed into infrastructure whose subsequent effects far exceeded the first experiment. Recognition becomes more precise when Tomlinson’s achievement is identified without absorbing everyone else’s work into it.
For marketing.museum, the longer development is particularly revealing. Digital market communication requires routes, intelligible destinations, common formats and workable procedures. None replaces the need to build a relevant relationship with an audience. The first network email therefore offers more than the origin of a famous symbol. It shows how a specific technical connection could become part of a generally usable communication capability, without every later commercial form already being present in the initial test.
References
Bhushan, A., Pogran, K., Tomlinson, R. and White, J. (1973) Standardizing Network Mail Headers. RFC 561, 5 September. Original.
Borenstein, N. and Freed, N. (1992) MIME: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. RFC 1341, June. Original.
CERN (n.d.) The birth of the Web. Institutional history.
Crocker, D. H. (1982) Standard for the Format of ARPA Internet Text Messages. RFC 822, 13 August. Original.
Crocker, D. H., Vittal, J. J., Pogran, K. T. and Henderson, D. A. (1977) Standard for the Format of ARPA Network Text Messages. RFC 733, 21 November. Original.
Feinler, E. and Vittal, J. (2022) Email Innovation Timeline. Computer History Museum, 1 July, especially pp. 22–23. Timeline.
Hambridge, S. (1995) Netiquette Guidelines. RFC 1855, October. Original.
History of Advertising Trust (n.d.) Data & Marketing Association; DMA. Collection record.
Internet Hall of Fame (n.d.) Official Biography: Raymond Tomlinson. Internet Society. Biography.
Jones, D. G. B. and Tadajewski, M. (2016) ‘Preface’, in Jones, D. G. B. and Tadajewski, M. (eds), The Routledge Companion to Marketing History. Abingdon: Routledge, pp. xvii–xviii. Publisher preview.
Karlsruhe Institute of Technology / KIT (2014) First E-mail Received in Germany 30 Years Ago. Press release.
Kudlick, M. D. (1973) Network Mail Meeting Summary. RFC 469, 8 March. Original.
MIT CSAIL (n.d.) CTSS Documents. Documentation catalogue.
Mockapetris, P. (1983) Domain Names – Concepts and Facilities. RFC 882, November. Original.
Museum of Modern Art (n.d.) Ray Tomlinson. @. 1971. MoMA Learning. Museum account.
Myer, T. H. and Henderson, D. A. (1975) Message Transmission Protocol. RFC 680, 30 April. Original.
Partridge, C. (2008) ‘The Technical Development of Internet Email’, IEEE Annals of the History of Computing, 30(2), pp. 3–29. DOI: 10.1109/MAHC.2008.32. Full text.
Postel, J. (1975) On the Junk Mail Problem. RFC 706, November. Original.
Postel, J. B. (1982) Simple Mail Transfer Protocol. RFC 821, August. Original.
The Royal Family (2019) Her Majesty The Queen shares Instagram post, 7 March. Institutional timeline.
Tomlinson, R. (2009) Oral History of Raymond (Ray) Tomlinson. Interview with Marc Weber and Gardner Hendrie, 5 June, Cambridge, Massachusetts. Computer History Museum, X5409.2009, especially pp. 9–14. Transcript.
Tomlinson, R. (2016) The First Network Email. Undated autobiographical account, reprinted by David Luckham on 9 March 2016. Reprint.
Van Vleck, T. (2012) ‘Electronic Mail and Text Messaging in CTSS, 1965–1973’, IEEE Annals of the History of Computing, 34(1), pp. 4–6. DOI: 10.1109/MAHC.2012.6. Author version.
Watson, R. W. (1971a) A Mail Box Protocol. RFC 196, 20 July. Original.
Watson, R. W. (1971b) A Mail Box Protocol, Version-2. RFC 221, 25 August. Original.
White, J. E. (1973) A Proposed Mail Protocol. RFC 524, 13 June. Original.
