An email address identifies a mailbox to which email messages are delivered. While early messaging systems used a variety of address formats, email addresses today follow a specific set of rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by . The term "email address" in this article refers to just the addr-spec in Section 3.4 of . The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.
An email address, such as [email protected], is made up of a local-part, the symbol @, and a domain, which may be either a domain name or an IP address enclosed in brackets. Although the standard stipulates that the local-part is case-sensitive, it also urges that receiving hosts deliver messages in a case-independent manner, e.g., that the mail system in the domain example.com treat Jane.Smith as equivalent to jane.smith. (Some mail systems even treat both as equivalent to jane smith."...you can add or remove the dots from a mail address without changing the actual destination address; and they'll all go to your inbox ...", Google.com) Email systems often limit the user's choice of name to a subset of the characters permitted by the RFCs. With the introduction of internationalized domain names, efforts are progressing to permit non-ASCII characters in email addresses.
Due to the ubiquity of email today, email addresses are used as regular usernames by many websites and services that provide a user profile or account. For example, if a user wants to log in to their Xbox Live video gaming profile, they would use their email address as the username ID of their Microsoft account, even though the service in this case is not email.
Message transport
An email address consists of two parts, a local-part (sometimes a user name, but not always) and a domain. If the domain is a domain name rather than an IP address, then the SMTP client looks up the mail-exchange (MX) IP address of that domain name. The general format of an email address is local-part@domain, e.g. jsmith@[192.168.1.2], [email protected]. The SMTP client transmits the message to the mail exchange, which may forward it to another mail exchange, until it ultimately arrives at the host of the recipient's mail system.
The transmission of electronic mail from the sender's computer and between mail hosts in the Internet uses the Simple Mail Transfer Protocol (SMTP), defined in , and extensions such as . The mailboxes may be accessed and managed by applications on personal computers, mobile devices or webmail sites using the SMTP protocol and either the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP).
When transmitting email messages, mail user agents (MUAs) and mail transfer agents (MTAs) use the domain name system (DNS) to look up a resource record (RR) for the recipient's domain. A mail exchange resource record (MX record) contains the name of the recipient's mail server. In the absence of an MX record, an address record (whether A or AAAA) directly specifies the mail host.
The local-part of an email address has no significance for intermediate mail relay systems other than the final mailbox host. Email senders and intermediate relay systems must not assume it to be case-insensitive, since the final mailbox host may or may not treat it as such. A single mailbox may receive mail for multiple email addresses, if configured by the administrator. Conversely, a single email address may be the alias to a distribution list to many mailboxes. Email aliases, electronic mailing lists, sub-addressing, and catch-all addresses (mailboxes that receive messages regardless of the local-part) are common patterns for achieving a variety of delivery goals.
The addresses contained in the header fields of an email message are not directly used by mail exchanges to deliver the message. In SMTP mail transfer, the sending system communicates the source and destination addresses; this information is sometimes called the "message envelope". While the envelope and header addresses may be the same, this is not strictly required, and forged or "spoofed" email addresses are often seen in spam, phishing, and many other Internet-based scams. This has led to several initiatives aimed at making such forgeries of fraudulent emails easier to spot.
Syntax
The format of an email address is local-part@domain, where the local-part may be up to 64 octets long and the domain may have a maximum of 255 octets. The formal definitions are in RFC 5322 (sections 3.2.3 and 3.4.1) and RFC 5321—with a more readable form given in the informational RFC 3696 (written by J. Klensin, the author of RFC 5321J. Klensin, RFC 5321, IETF, October 2008) and the associated errata.
An email address also may have an associated "display-name" (Display Name) for the recipient, which precedes the address specification, surrounded by angled brackets in that case, for example: Jane Smith <[email protected]>. Email spammers and phishers will often use "Display Name spoofing" to trick their victims, by using a false Display Name, or by using a different email address as the Display Name.
Earlier forms of email addresses for other networks than the Internet included other notations, such as that required by X.400, and the UUCP bang path notation, in which the address was given in the form of a sequence of computers through which the message should be relayed. This was widely used for several years, but was superseded by the Internet standards promulgated by the Internet Engineering Task Force (IETF).
Local-part
The local-part of the email address may be unquoted or may be enclosed in quotation marks.
If unquoted, it may use any of these ASCII characters: uppercase and lowercase Latin letters A to Z and a to z digits 0 to 9 printable characters !#$%&'*+-/=?^_`{|}~ dot ., provided that it is not the first or last character and provided also that it does not appear consecutively (e.g., [email protected] is not allowed).
If quoted, it may contain Space, Horizontal Tab (HT), any ASCII graphic except Backslash and Quote and a quoted-pair consisting of a Backslash followed by HT, Space or any ASCII graphic; it may also be split between lines anywhere that HT or Space appears. In contrast to unquoted local-parts, the addresses ".Jane.Doe"@example.com, "Jane.Doe."@example.com and "Jane..Doe"@example.com are allowed.
The maximum total length of the local-part of an email address is 64 octets.
Space and special characters "(),:;<>@[\] are allowed with restrictions (they are only allowed inside a quoted string, as described in the paragraph below, and in that quoted string, any backslash or double-quote must be preceded once by a backslash); Comments are allowed with parentheses, either at the start or end of the local-part; e.g., jane.smith(comment)@example.com and (comment)[email protected] are both equivalent to [email protected].
In addition to the above ASCII characters, international characters above U+007F, encoded as UTF-8, are permitted by RFC 6531 when the EHLO specifies SMTPUTF8, though even mail systems that support SMTPUTF8 and 8BITMIME may restrict what characters to use when assigning local-parts.
A local-part is either a Dot-string or a Quoted-string; it cannot be a combination. Quoted strings and characters, however, are not commonly used. RFC 5321 also warns that "a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form".
The local-part postmaster is treated specially—it is case-insensitive, and should be forwarded to the domain email administrator. Technically all other local-parts are case-sensitive, therefore [email protected] and [email protected] specify different mailboxes; however, many organizations treat uppercase and lowercase letters as equivalent. Indeed, RFC 5321 warns that "a host that expects to receive mail SHOULD avoid defining mailboxes where ... the Local-part is case-sensitive".
Despite the wide range of special characters that are technically valid, organisations, mail services, mail servers, and mail clients in practice often do not accept all of them. For example, Windows Live Hotmail only allows creation of email addresses using alphanumerics, dot (.), underscore (_) and hyphen (-).. However, the phrase is hidden, thus one has to either check the availability of an invalid ID, e.g., me#1, or resort to alternative displaying, e.g., no-style or source view, in order to read it. Common advice is to avoid using some special characters to avoid the risk of rejected emails.
According to RFC 5321 2.3.11 Mailbox and Address, "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain of the address". This means that no assumptions can be made about the meaning of the local-part of another mail server. It is entirely up to the configuration of the mail server.
Interpretation of the local-part is dependent on the conventions and policies implemented in the mail server. For example, case sensitivity may distinguish mailboxes differing only in capitalization of characters of the local-part, although this is not very common.Are Email Addresses Case Sensitive? by Heinz Tschabitscher For example, Gmail ignores all dots in the local-part of user email address for the purposes of determining account identity.
Sub-addressing
Some mail services support a tag included in the local-part, such that the address is an alias to a prefix of the local-part. Typically the characters following a plus and less often the characters following a minus, so fred+bar@domain and fred+foo@domain might end up in the same inbox as fred+@domain or even as fred@domain. For example, the address [email protected] denotes the same delivery address as [email protected]. refers to this convention as subaddressing, but it is also known as plus addressing, tagged addressing or mail extensions. This can be useful for tagging emails for sorting, and for spam control.
Addresses of this form, using various separators between the base name and the tag, are supported by several email services, including Andrew Project (plus), Runbox (plus), Gmail (plus), Rackspace (plus), Yahoo! Mail Plus (hyphen), Apple's iCloud (plus), Outlook.com (plus), Mailfence (plus), Proton Mail (plus), Fastmail (plus and Subdomain Addressing), postale.io (plus), Pobox (plus), MeMail (plus), and MTAs like MMDF (equals), Qmail and Courier Mail Server (hyphen). Postfix and Exim allow configuring an arbitrary separator from the legal character set.
The text of the tag may be used to apply filtering, or to create single-use, or disposable email addresses.Gina Trapani (2005) "Instant disposable Gmail addresses"
Domain
The domain name part of an email address has to conform to strict guidelines: it must match the requirements for a hostname, a list of dot-separated DNS labels, each label being limited to a length of 63 characters and consisting of:
Uppercase and lowercase Latin letters A to Z and a to z; Digits 0 to 9, provided that top-level domain names are not all-numeric; Hyphen -, provided that it is not the first or last character. This rule is known as the LDH rule (letters, digits, hyphen). In addition, the domain may be an IP address literal, surrounded by square brackets [], such as jsmith@[192.168.2.1] or jsmith@[IPv6:2001:db8::1], although this is rarely seen except in email spam. Internationalized domain names (which are encoded to comply with the requirements for a hostname) allow for presentation of non-ASCII domains. In mail systems compliant with RFC 6531 and RFC 6532, an email address may be encoded as UTF-8, both a local-part as well as a domain name.