Email address

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 5321) 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 (-). 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. 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]. RFC 5233 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.

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.

Comments are allowed in the domain as well as in the local-part; for example, jane.smith@(comment)example.com and [email protected](comment) are equivalent to [email protected].

RFC 2606 specifies that certain domains, for example those intended for documentation and testing, should not be resolvable and that as a result mail addressed to mailboxes in them and their subdomains should be non-deliverable. Of note for email are example, invalid, example.com, example.net, and example.org.

Examples

Valid email addresses

• [email protected]
• [email protected]
• [email protected] (case is always ignored after the @ and usually before)
• [email protected] (one-letter local-part)
• [email protected]
• [email protected] (may be routed to [email protected] inbox depending on mail server)
• name/[email protected] (slashes are a printable character, and allowed)
• admin@example (local domain name with no TLD, although ICANN highly discourages dotless email addresses)
• [email protected] (see the List of Internet top-level domains)
• " "@example.org (space between the quotes)
• "jane..doe"@example.org (quoted double dot)
• [email protected] (bangified host route used for UUCP mailers)
• "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com (include non-letters character AND multiple at sign, the first one being double quoted)
• user%[email protected] (% escaped mail route to [email protected] via example.org)
• [email protected] (local-part ending with non-alphanumeric character from the list of allowed printable characters)
• postmaster@[123.123.123.123] (IP addresses are allowed instead of domains when in square brackets, but strongly discouraged)
• postmaster@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334] (IPv6 uses a different syntax)
• _test@[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334] (begin with underscore different syntax)

Valid email addresses with SMTPUTF8

• I❤️[email protected] (emoji are only allowed with SMTPUTF8)

Invalid email addresses

• abc.example.com (no @ character)
• a@b@[email protected] (only one @ is allowed outside quotation marks)
• a"b(c)d,e:f;g<h>i[j\k][email protected] (none of the special characters in this local-part are allowed outside quotation marks)
• just"not"[email protected] (quoted strings must be dot separated or be the only element making up the local-part)
• this is"not\[email protected] (spaces, quotes, and backslashes may only exist when within quoted strings and preceded by a backslash)
• this\ still\"not\\[email protected] (even if escaped (preceded by a backslash), spaces, quotes, and backslashes must still be contained by quotes)
• 1234567890123456789012345678901234567890123456789012345678901234+x@example.com (local-part is longer than 64 characters)
• i.like.underscores@but_they_are_not_allowed_in_this_part (underscore is not allowed in domain part)

Validation and verification

Email addresses are often requested as input to website as validation of user existence. Other validation methods are available, such as cell phone number validation, postal mail validation, and fax validation.

An email address is generally recognized as having two parts joined with an at-sign (@), although the technical specifications detailed in RFC 822 and subsequent RFCs are more extensive.

Syntactically correct, verified email addresses do not guarantee that an email box exists. Thus many email servers use other techniques and check the mailbox existence against relevant systems such as the Domain Name System for the domain or using callback verification to check if the mailbox exists. Callback verification is an imperfect solution, as it may be disabled to avoid a directory harvest attack, or callbacks may be reported as spam and lead to listing on a DNSBL.

Several validation techniques may be utilized to validate a user email address. For example,

• Verification links: Email address validation is often accomplished for account creation on websites by sending an email to the user-provided email address with a special temporary hyperlink. On receipt, the user opens the link, immediately activating the account. Email addresses are also useful as means of delivering messages from a website, e.g., user messages, user actions, to the email inbox.
• Formal and informal standards: RFC 3696 provides specific advice for validating Internet identifiers, including email addresses. Some websites instead attempt to evaluate the validity of email addresses through arbitrary standards, such as by rejecting addresses containing valid characters, such as + and /, or enforcing arbitrary length limitations. Email address internationalization provides for a much larger range of characters than many current validation algorithms allow, such as all Unicode characters above U+0080, encoded as UTF-8.
• Algorithmic tools: Large websites, bulk mailers and spammers require efficient tools to validate email addresses. Such tools depend upon heuristic algorithms and statistical models.
• Sender reputation: An email sender's reputation may be used to attempt to verify whether the sender is trustworthy or a potential spammer. Factors that may be incorporated into an assessment of sender reputation include the quality of past contact with or content provided by, and engagement levels of, the sender's IP address or email address.
• Browser-based verification: HTML5 forms implemented in many browsers allow email address validation to be handled by the browser.

Some companies offer services to validate an email address, often using an API, but there is no guarantee that it will provide accurate results.

Internationalization

The IETF conducts a technical and standards working group devoted to internationalization issues of email addresses, entitled Email Address Internationalization (EAI, also known as IMA, Internationalized Mail Address). This group produced RFC 6530, 6531, 6532 and 6533, and continues to work on additional EAI-related RFCs.

The IETF's EAI Working group published RFC 6530 "Overview and Framework for Internationalized Email" that enabled non-ASCII characters to be used in both the local-parts and domain of an email address. RFC 6530 provides for email based on the UTF-8 encoding, which permits the full repertoire of Unicode. RFC 6531 provides a mechanism for SMTP servers to negotiate transmission of the SMTPUTF8 content.

The basic EAI concepts involve exchanging mail in UTF-8. Though the original proposal included a downgrading mechanism for legacy systems, this has now been dropped. The local servers are responsible for the local-part of the address, whereas the domain would be restricted by the rules of internationalized domain names, though still transmitted in UTF-8. The mail server is also responsible for any mapping mechanism between the IMA form and any ASCII alias.

EAI enables users to have a localized address in a native language script or character set, as well as an ASCII form for communicating with legacy systems or for script-independent use. Applications that recognize internationalized domain names and mail addresses must have facilities to convert these representations.

Significant demand for such addresses is expected in China, Japan, Russia, and other markets that have large user bases in a non-Latin-based writing system.

For example, in addition to the .in top-level domain, the government of India in 2011 got approval for ".bharat", (from Bhārat Gaṇarājya), written in seven different scripts for use by Gujrati, Marathi, Bangali, Tamil, Telugu, Punjabi and Urdu speakers. Indian company XgenPlus.com claims to be the world's first EAI mailbox provider, and the Government of Rajasthan now supplies a free email account on domain राजस्थान.भारत for every citizen of the state. A leading media house Rajasthan Patrika launched their IDN domain पत्रिका.भारत with contactable email.

The example addresses below would not be handled by RFC 5321-based servers without an extension, but are permitted by the UTF8SMTP extension of RFC 6530 and 6531. Servers compliant with this will be able to handle these:

• Latin alphabet with diacritics: élé[email protected]
• Greek alphabet: δοκιμή@παράδειγμα.δοκιμή
• Traditional Chinese characters: 我買@屋企.香港
• Japanese characters: 二ノ宮@黒川.日本
• Cyrillic characters: медведь@с-балалайкой.рф
• Devanagari characters: संपर्क@डाटामेल.भारत