An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to addr-spec in RFC 5322, not to address or mailbox; i.e., a raw address without a display-name.
An email address, such as firstname.lastname@example.org, is made up from a local-part, the symbol @, and a domain , which may be a domain name or an IP address enclosed in brackets. Although the standard requires the local part to be 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 John.Smith as equivalent to john.smith; some mail systems even treat them as equivalent to johnsmith. Mail systems often limit the users' choice of name to a subset of the technically permitted characters.
With the introduction of internationalized domain names, efforts are progressing to permit non-ASCII characters in email addresses.
An email address consists of two parts, a local part [192.168.1.2], email@example.com. The SMTP client transmits the message to the mail exchange, which may forward it to another mail exchange until it eventually arrives at the host of the recipient's mail system.and a domain; if the domain is a domain name rather than an IP address then the SMTP client uses the domain name to look up the mail exchange IP address. The general format of an email address is local-part@domain, e.g., , jsmith@
The transmission of electronic mail from the author's computer and between mail hosts in the Internet uses the Simple Mail Transfer Protocol (SMTP), defined in RFC 5321 and 5322, and extensions such as RFC 6531. 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 exchanger resource record (MX record) contains the name of the recipient's mailserver. In absence of an MX record, an address record (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, the latter being mailboxes that receive messages regardless of the local part, are common patterns for achieving a variety of delivery goals.
The addresses found in the header fields of an email message are not directly used by mail exchanges to deliver the message. An email message also contains a message envelope that contains the information for mail routing. While envelope and header addresses may be equal, forged email addresses - also called spoofed 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 of fraudulent emails easier to spot.
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. RFC 5322 (sections 3.2.3 and 3.4.1) and RFC 5321—with a more readable form given in the informational RFC 3696 and the associated errata.The formal definitions are in
An email address also may have an associated display name for the recipient, which precedes the address specification, now surrounded by angled brackets, for example: John Smith <firstname.lastname@example.org>.
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).
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:
., provided that it is not the first or last character and provided also that it does not appear consecutively (e.g.,
John..Doe@example.comis 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
"John..Doe"@example.com are allowed.
The maximum total length of the local-part of an email address is 64 octets.
Note that some mail servers support wildcard recognition of local parts, typically the characters following a plus and less often the characters following a minus, so fred+bah@domain and fred+foo@domain might end up in the same inbox as fred+@domain or even as fred@domain. This can be useful for tagging emails for sorting (see below), and for spam control.
} are also used in that fashion, although less often. [ citation needed ]
"(),:;<>@[\]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);
(comment)email@example.com both equivalent to
In addition to the above ASCII characters, international characters above U+007F, encoded as UTF-8, are permitted by RFC 6531, though even mail systems that support SMTPUTF8 and 8BITMIME may restrict which 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.[ citation needed ]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".
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
JSmith@example.com 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 which 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.
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: §2:
9, provided that top-level domain names are not all-numeric;
-, 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@[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,
firstname.lastname@example.org(comment) are equivalent to
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 e-mail are example, invalid, example.com, example.net, and example.org.
email@example.com(may go to
firstname.lastname@example.org depending on mail server)
email@example.com(slashes are a printable character, and allowed)
admin@mailserver1(local domain name with no TLD, although ICANN highly discourages dotless email addresses )
firstname.lastname@example.org(see the List of Internet top-level domains)
" "@example.org(space between the quotes)
"john..doe"@example.org(quoted double dot)
email@example.com(bangified host route used for uucp mailers)
firstname.lastname@example.org(% escaped mail route to email@example.com via example.org)
firstname.lastname@example.org(local part ending with non-alphanumeric character from the list of allowed printable characters)
Abc.example.com(no @ character)
A@b@email@example.com(only one @ is allowed outside quotation marks)
a"b(c)d,e:f;g<h>i[j\k]firstname.lastname@example.org(none of the special characters in this local-part are allowed outside quotation marks)
just"not"email@example.com(quoted strings must be dot separated or the only element making up the local-part)
this is"not\firstname.lastname@example.org(spaces, quotes, and backslashes may only exist when within quoted strings and preceded by a backslash)
this\ still\"not\\email@example.com(even if escaped (preceded by a backslash), spaces, quotes, and backslashes must still be contained by quotes)
firstname.lastname@example.org(local-part is longer than 64 characters)
i_like_underscore@but_its_not_allowed_in_this_part.example.com(Underscore is not allowed in domain part)
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 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.Gmail ignores all dots in the local-part of a @gmail.com address for the purposes of determining account identity.
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. For example, the address email@example.com denotes the same delivery address as firstname.lastname@example.org. RFC 5233, refers to this convention as sub-addressing, but it is also known as plus addressing, tagged addressing or mail extensions.
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), ProtonMail (plus), Fastmail (plus and Subdomain Addressing), postale.io (plus), Pobox (plus), MeMail (plus), 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.
In practice, the form validation of some web sites may reject characters such as "+" in an email address – treating them, incorrectly, as invalid characters. This can lead to an incorrect user receiving an e-mail if the "+" is silently stripped by a website without any warning or error messages. For example, an email intended for the user-entered email address email@example.com could be incorrectly sent to firstname.lastname@example.org. In other cases a poor user experience can occur if some parts of a site, such as a user registration page, allow the "+" character whilst other parts, such as a page for unsubscribing from a site's mailing list, do not.
This section needs additional citations for verification .(July 2019)
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 technical specification 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 mail servers use incorrectly 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.
Several validation techniques may be utilized to validate an user email address. For example,
Some companies offer services to validate an email address, often using an application programming interface, but there is no guarantee that it will provide accurate results.
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). 6530 , 6531 , 6532 and 6533, and continues to work on additional EAI-related RFCs.This group produced RFC
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-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 2011got 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 5322 based servers, but are permitted by RFC 6530. Servers compliant with this will be able to handle these:
Electronic mail is a method of exchanging messages ("mail") between people using electronic devices. Email entered limited use in the 1960s, but users could only send to users of the same computer, and some early email systems required the author and the recipient to both be online simultaneously, similar to instant messaging. Ray Tomlinson is credited as the inventor of email; in 1971, he developed the first system able to send mail between users on different hosts across the ARPANET, using the @ sign to link the user name with a destination server. By the mid-1970s, this was the form recognized as email.
In computing, the Internet Message Access Protocol (IMAP) is an Internet standard protocol used by email clients to retrieve email messages from a mail server over a TCP/IP connection. IMAP is defined by RFC 3501.
The Simple Mail Transfer Protocol (SMTP) is an internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP and POP3 are standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.
An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.
A mail exchanger record specifies the mail server responsible for accepting email messages on behalf of a domain name. It is a resource record in the Domain Name System (DNS). It is possible to configure several MX records, typically pointing to an array of mail servers for load balancing and redundancy.
Sender Policy Framework (SPF) is an email authentication method designed to detect forging sender addresses during the delivery of the email. SPF alone, though, is limited to detecting a forged sender claim in the envelope of the email, which is used when the mail gets bounced. Only in combination with DMARC can it be used to detect the forging of the visible sender in emails, a technique often used in phishing and email spam.
A bounce message or just "bounce" is an automated message from an email system, informing the sender of a previous message that the message has not been delivered. The original message is said to have "bounced".
Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.
Percent-encoding, also known as URL encoding, is a method to encode arbitrary data in a Uniform Resource Identifier (URI) using only the limited US-ASCII characters legal within a URI. Although it is known as URL encoding, it is also used more generally within the main Uniform Resource Identifier (URI) set, which includes both Uniform Resource Locator (URL) and Uniform Resource Name (URN). As such, it is also used in the preparation of data of the
/x-www-form-urlencoded media type, as is often used in the submission of HTML form data in HTTP requests.
Many email clients now offer some support for Unicode. Some clients will automatically choose between a legacy encoding and Unicode depending on the mail's content, either automatically or when the user requests it.
For amail transfer agent (MTA), the Sender Rewriting Scheme (SRS) is a scheme for rewriting the envelope sender address of an email message, in view of remailing it. In this context, remailing is a kind of email forwarding. SRS was devised in order to forward email without breaking the Sender Policy Framework (SPF), in 2003.
Sieve is a programming language that can be used for email filtering. It owes its creation to the CMU Cyrus Project, creators of Cyrus IMAP server.
In computing, Author Domain Signing Practices (ADSP) is an optional extension to the DKIM E-mail authentication scheme, whereby a domain can publish the signing practices it adopts when relaying mail on behalf of associated authors.
DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email, a technique often used in phishing and email spam.
DMARC is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing emails, email scams and other cyber threat activities.
Email forwarding generically refers to the operation of re-sending an email message delivered to one email address to one or more different email addresses.
International email arises from the combined provision of internationalized domain names (IDN) and email address internationalization (EAI). The result is email that contains international characters, encoded as UTF-8, in the email header and in supporting mail transfer protocols. The most significant aspect of this is the allowance of email addresses in most of the world's writing systems, at both interface and transport levels.
A mailbox is the destination to which electronic mail messages are delivered. It is the equivalent of a letter box in the postal system.
A bounce address is an email address to which bounce messages are delivered. There are many variants of the name, none of them used universally, including return path, reverse path, envelope from, envelope sender, MAIL FROM, 5321-FROM, return address, From_, Errors-to, etc. It is not uncommon for a single document to use several of these names.
A mailbox provider, mail service provider or, somewhat improperly, email service provider is a provider of email hosting. It implements email servers to send, receive, accept, and store email for other organizations or end users, on their behalf.
The local-part of a mailbox MUST BE treated as case sensitive.
However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
Pobox supports the use of "+anystring" (plus extensions) with any address.