Email address

An email address identifies an email box to which email messages are delivered. This article covers modern Internet email, but many earlier email systems used different address formats.

An email address such as John.Smith@example.com is made up of a local part, an @ symbol, then a domain part. The domain part is not case-sensitive, but local-parts normally are. In practice, the mail system at example.com may choose to treat John.Smith as equivalent john.smith or even johnsmith.^[1] Mail systems often limit their users' choice of name to a subset of the technically valid characters, and may in some cases also limit which addresses it is possible to send mail to.

With the introduction of Internationalized domain names efforts are progressing to permit non-ASCII characters in email addresses.

Overview

The transmission of electronic mail on the Internet uses the Simple Mail Transfer Protocol (SMTP), defined in Internet standards RFC 5321 and RFC 5322, and extensions like RFC 6531. Mailboxes themselves are most often accessed using the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP)^{[citation needed]}, though the use of webmail (where the mailbox contents are rendered in a client browser by HTML) is becoming more common.

The general format of an email address is jsmith@example.org. It consists of two parts: the part before the @ sign is the local-part of the address, often the username of the recipient (e.g., jsmith), and the part after the @ symbol is a domain name to which the email message will be sent (e.g., example.org).

A mail server uses the Domain Name System (DNS) to locate the destination mail server for the domain of the recipient by querying for mail exchanger records (MX records). The responsible mail exchanger name is furthermore resolved to its IP address. The organization holding the delegation for a given domain, the Mailbox provider, can define the target hosts for all email destined to its domain. The mail exchanger does not need to be located in the domain of the destination mail box, it must simply accept mail for the domain. The target hosts are configured with a mechanism to deliver mail to all destination mail boxes. If no MX servers are configured, a mail server queries the A record for the domain.

The local-part of an email address has no significance to intermediate mail relay systems other than the final mailbox host. Email programs and intermediate mail relay systems must not assume it to be case-insensitive, since the final mailbox host may or may not treat it as such. The same mailbox can be set up to receive emails from multiple email addresses. Conversely, a single email address may be an alias and have a distribution function to many mailboxes. Email aliases, electronic mailing lists, sub-addressing, and catch-all addresses, the latter being mailboxes that receive messages regardless of the local part, are common patterns for achieving such results.

The addresses found in the header fields of an email message are not the ones used by SMTP servers to deliver the message. Servers use the so-called message envelope to route mail. While envelope and header addresses may be equal, forged email addresses are often seen in spam, phishing, and many other internet-based scams. This has led to several initiatives which aim to make such forgeries easier to spot.

To indicate the message recipient, an email address also may have an associated display name for the recipient, which is followed by the address specification surrounded by angled brackets, for example: John Smith <john.smith@example.org>.

Earlier forms of email addresses on other networks than the Internet included the longer notation 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 generally more convenient SMTP form.

Syntax

The format of email addresses is local-part@domain where the local-part may be up to 64 characters long and the domain name may have a maximum of 255 characters – but the maximum 256 characters length of a forward or reverse path restricts the entire email address to be no more than 254 characters.^[2] 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^[3] and the associated errata.

Local part

The local-part of the email address may use any of these ASCII characters RFC 5322 Section 3.2.3, RFC 6531 permits Unicode beyond the ASCII range:

• Uppercase and lowercase English letters (a–z, A–Z) (ASCII: 65–90, 97–122)
• Digits 0 to 9 (ASCII: 48–57)
• These special characters: ! # $ % & ' * + - / = ? ^ _ ` { | } ~ (Support for these is limited)
• Character . (dot, period, full stop) (ASCII: 46) provided that it is not the first or last character, and provided also that it does not appear two or more times consecutively (e.g. John..Doe@example.com is not allowed).
• Special characters are allowed with restrictions. They are:
  • Space and "(),:;<>@[\] (ASCII: 32, 34, 40, 41, 44, 58, 59, 60, 62, 64, 91–93)

The restrictions for special characters are that they must only be used when contained between quotation marks, and that 2 of them (the backslash \ and quotation mark " (ASCII: 92, 34)) must also be preceded by a backslash \ (e.g. "\\\"").

• Comments are allowed with parentheses at either end of the local part; e.g. "john.smith(comment)@example.com" and "(comment)john.smith@example.com" are both equivalent to "john.smith@example.com".
• International characters above U+007F are permitted by RFC 6531, though mail systems may restrict which characters to use when assigning local parts.

A quoted string may exist as a dot separated entity within the local-part, or it may exist when the outermost quotes are the outermost characters of the local-part (e.g. abc."defghi".xyz@example.com or "abcdefghixyz"@example.com are allowed. Conversely, abc"defghi"xyz@example.com is not; neither is abc\"def\"ghi@example.com). 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 server's administrator. Technically all other local-parts are case sensitive, therefore jsmith@example.com and JSmith@example.com specify different mailboxes; however, many organizations treat uppercase and lowercase letters as equivalent.

Most organizations do not allow use of many of the technically valid special characters. Organizations are free to restrict the forms of their own email addresses as desired, e.g., Windows Live Hotmail, for example, only allows creation of email addresses using alphanumerics, dot (.), underscore (_) and hyphen (-).^[4]

Systems that send mail must be capable of handling outgoing mail for all valid addresses. Contrary to the relevant standards, some defective systems treat certain legitimate addresses as invalid and fail to handle mail to these addresses. Hotmail, for example, refuses to send mail to any address containing any of the following standards-permissible characters: !#$%*/?^`{|}~.^{[citation needed]}

Domain part

The domain name part of an email address has to conform to strict guidelines: it must match the requirements for a hostname, consisting of letters, digits, hyphens and dots. In addition, the domain part may be an IP address literal, surrounded by square braces, such as jsmith@[192.168.2.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 domain parts.

Comments are allowed in the domain part as well as in the local part. E.g. "john.smith@(comment)example.com" and "john.smith@example.com(comment)" are equivalent to "john.smith@example.com".

Examples

Valid email addresses

• niceandsimple@example.com
• very.common@example.com
• a.little.lengthy.but.fine@dept.example.com
• disposable.style.email.with+symbol@example.com
• other.email-with-dash@example.com
• user@[IPv6:2001:db8:1ff::a0b:dbd0]
• "much.more unusual"@example.com
• "very.unusual.@.unusual.com"@example.com
• "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com
• postbox@com (top-level domains are valid hostnames)
• admin@mailserver1 (local domain name with no TLD)
• !#$%&'*+-/=?^_`{}|~@example.org
• "()<>[]:,;@\\\"!#$%&'*+-/=?^_`{}| ~.a"@example.org
• " "@example.org (space between the quotes)
• üñîçøðé@example.com (Unicode characters in local part)
• üñîçøðé@üñîçøðé.com (Unicode characters in domain part)

Invalid email addresses

• Abc.example.com (an @ character must separate the local and domain parts)
• A@b@c@example.com (only one @ is allowed outside quotation marks)
• a"b(c)d,e:f;g<h>i[j\k]l@example.com (none of the special characters in this local part is allowed outside quotation marks)
• just"not"right@example.com (quoted strings must be dot separated, or the only element making up the local-part)
• this is"not\allowed@example.com (spaces, quotes, and backslashes may only exist when within quoted strings and preceded by a backslash)
• this\ still\"not\\allowed@example.com (even if escaped (preceded by a backslash), spaces, quotes, and backslashes must still be contained by quotes)
• email@brazil.b (top-level domain following up a dot require minimum two alphabetic characters (ISO_3166-1_alpha-2 code), for Brazil e.g. it must be br according to ISO 3166-1).

Common local-part semantics

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 part 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.

Local-part normalization

Interpretation of the local-part of an email address 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.^[5] Gmail ignores all dots in the local-part for the purposes of determining account identity.^[6] This prevents the creation of user accounts your.user.name or yourusername when the account your.username already exists.

Address tags

Some mail services allow a user to append a tag to their email address (e.g., where joeuser@example.com is the main address, which would also accept mail for joeuser+work@example.com or joeuser-family@example.com). The text of tag may be used to apply filtering and to create single-use addresses.^[7] Some IETF standards-track documents, such as RFC 5233 refer to this convention as "sub-addressing". However, many websites' automatic form validation scripts or software will reject + as an invalid character in the email address.

Disposable email addresses of this form, using various separators between the base name and the tag, are supported by several email services, including Runbox (plus and hyphen), Gmail (plus),^[8] Yahoo! Mail Plus (hyphen),^[9] Apple's MobileMe (this site is now closed and changed to iCloud.com) (plus), Outlook.com (plus),^[10] FastMail.FM (plus and Subdomain Addressing),^[11] and MMDF (equals).

Most installations of the qmail and Courier Mail Server products support the use of a hyphen '-' as a separator within the local-part, such as joeuser-tag@example.com or joeuser-tag-sub-anything-else@example.com. This allows qmail through .qmail-default or .qmail-tag-sub-anything-else files to sort, filter, forward, or run an application based on the tagging system established.^[12][13]

Postfix allows configuring an arbitrary separator from the legal character set. The separator info remains available on the email (address is not rewritten to remove it), and thus is useful in internal mail-routing, filtering, and forwarding via any of the mechanisms existing in Postfix.^[14]

Validation & Verification

Not only are email addresses used in a mail client or on a mail server, but also used in websites where a user-supplied email address is often validated.

An email address is generally recognized as having two parts joined with an at-sign (@); this in itself is a basic form of validation. However, the technical specification detailed in RFC 822 and subsequent RFCs go far beyond this, offering very complex and strict restrictions.^[15]

It is impossible to match these restrictions with a single technique and using for instance regular expressions will result in long and still not a perfect pattern.^[16]

Unfortunately syntactically correct, "verified" email addresses will not guarantee Email box existence. Thus many mail servers use other techniques and check the mailbox existence against relevant systems such as DNS for the domain part or using callback verification to check if the mailbox exists. (This is however often disabled to avoid Directory Harvest Attack).

Assuring an email address is of a good quality, requires a combination of various validation techniques. Large websites, bulk mailers or spammers, require fast algorithms that will predict validity of email address. Such methods depend heavily on Heuristic algorithms and Statistical_models.^[17]

Conversely, many websites check and validate email addresses much more strictly than the standard specifies, rejecting addresses containing valid characters like + or / signs, or setting arbitrary length limitations (e.g., 30 characters). RFC 3696 was written to give specific advice for validating internet identifiers, including email addresses.

With many browsers now having implemented support for HTML5 forms, using the new 'email' state of the input element allows email address validation to be handled by the browser.

Email Address Internationalization (EAI) provides for a much larger range of characters than many current validation algorithms allow, such as all Unicode characters above U+0080.

Identity validation

Despite the growth of the World Wide Web as a primary interface for communication, email addresses continue to remain the primary means, besides cell phone number validation, postal mail validation, fax validation, etc., of identity validation for website account activation. This is usually accomplished by the website sending a temporary hyperlink to the inbox of the user-provided email address in order to open, immediately activating the account. Email addresses are also useful as means of forwarding messages from the website, e.g., user messages, user actions, to the email inbox.

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).^[18] This group produced RFCs 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", which enabled non-ASCII characters to be used in both the local and domain parts 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 mechanisms for legacy systems this has now been dropped.^[19] The local servers are responsible for the "local" part of the address, whereas the domain portion 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.

Internationalization examples

These addresses are permitted by RFC 6530 and compliant servers will be able to handle these. Many existing servers and clients are restricted to the earlier RFC 5322 and will therefore not work with the newer Unicode enabled email addresses. Most email providers are currently updating their systems to handle RFC6530.

• Latin Alphabet (with diacritics): Pelé@example.com
• Greek Alphabet: δοκιμή@παράδειγμα.δοκιμή
• Japanese Characters: 甲斐@黒川.日本
• Cyrillic Characters: чебурашка@ящик-с-апельсинами.рф

Internationalization support

Modified versions of sendmail and postfix exist that support the EAI rules.^{[citation needed]} Google has limited support for the earlier experimental RFC.

Standards documentation

• RFC 821 – Simple Mail Transfer Protocol (Obsoleted by RFC 2821)
• RFC 822 – Standard for the Format of ARPA Internet Text Messages (Obsoleted by RFC 2822) (Errata)
• RFC 1035 – Domain names – implementation and specification (Errata)
• RFC 1123 – Requirements for Internet Hosts – Application and Support (Updated by RFC 2821, RFC 5321) (Errata)
• RFC 2142 – Mailbox Names for Common Services, Roles and Functions (Errata)
• RFC 2821 – Simple Mail Transfer Protocol (Obsoletes RFC 821, Updates RFC 1123, Obsoleted by RFC 5321) (Errata)
• RFC 2822 – Internet Message Format (Obsoletes RFC 822, Obsoleted by RFC 5322) (Errata)
• RFC 3696 – Application Techniques for Checking and Transformation of Names (Errata)
• RFC 4291 – IP Version 6 Addressing Architecture (Updated by RFC 5952) (Errata)
• RFC 5321 – Simple Mail Transfer Protocol (Obsoletes RFC 2821, Updates RFC 1123) (Errata)
• RFC 5322 – Internet Message Format (Obsoletes RFC 2822) (Errata)
• RFC 5952 – A Recommendation for IPv6 Address Text Representation (Updates RFC 4291) (Errata)

See also

• Bounce address
• Email client
• Email mailbox

References

External links

The Wikibook Coding Cookbook has a page on the topic of: Validate Email Address

The Wikibook JavaScript has a page on the topic of: Best Practices