Email address types explained

Emails can contain multiple addresses, such as the sender, receiver, return-to, and reply-to addresses. These addresses can be from different domains. The various names of the addresses are often mixed up and can be confusing. In this article we'll discuss the various addresses that can be found in an email message.

How email works

To understand the various addresses used in email, it is important to get a grasp of how email works.

Email messages are exchanged between email servers using the Simple Mail Transfer Protocol (SMTP).

SMTP was originally defined in RFC821 in 1982, the authors designed the protocol to resemble the postal system. Emails are like paper letters, wrapped in an envelope (the SMTP protocol) and processed through different mail distribution centers (SMTP servers).

SMTP was originally designed before wide-area networking was common, before the internet was widespread, and before the invention of DNS. Back then, an SMTP service may not have known the address of the SMTP host for the recipient's inbox or even been on the same network. To address this, an SMTP service could deliver email to a connected 'gateway' SMTP service, which would relay it to the next SMTP service in the chain, and so forth. This is known as 'relaying', each SMTP service (mail distribution center) the message passes through is known as a 'hop'.

In the paper analogy, relaying is like wrapping the message in a new envelope that contains the address of the mail distribution center as the return address. If an email turns out to be undeliverable, the message is returned (bounced) by relaying back, passing each hop until the original sender is reached.

Nowadays SMTP hosts are connected to the internet and have access to the DNS. It is no longer necessary to relay email between multiple SMTP services, an outbound host will typically connect directly to the SMTP service that is authoritative for the recipient. Contemporary SMTP services no longer allow relaying to external SMTP services, known as an 'open relay', due to its high potential for being abused for distributing spam.

The envelope (SMTP)

Email messages are delivered using SMTP. The outbound (sending) SMTP service connects to the inbound (receiving) SMTP service, the outbound service then sends SMTP commands to establish an SMTP session. During the session initiation the outbound SMTP service identifies itself and sends the delivery address and return address. If the inbound SMTP service accepts then the session is established and the outbound SMTP sends the message.

The SMTP session can be viewed as the envelope used in paper mail, it is used to encapsulate the message. The envelope contains addresses for the SMTP services (the postal system) to know where to deliver or return the message.

The message

During an SMTP session (the envelope) the email message itself (the letter) is exchanged. The message is encoded in a format known as the 'Internet Message Format' (IMF), which is specified in RFC5322. IMF is not only used for email, in HTTP for example the content (HTML, images, etc.) is also transported using IMF.

Just like on a (formal) paper letter, an IMF format email message contains a header followed by the actual message, known as the body. And just like on a paper letter, the headers contain the sender name and address, the recipients name and address, a date and a subject.

The headers can also contain more technical information such as rendering options, spam check results, the path the email took for delivery, and things like DKIM signatures. The headers are usually hidden from the reader by your email application, but with most email programs you can still view them if you want to.

Finally, there is the actual content of the message known as the body of the email. This may be plain text, or styled content in HTML, and may also contain images, file attachments, etc. In the headers will be a description of the type of content, so your email application knows how to render the message.

RFC5321 vs RFC5322

RFC5321 and RFC5322 are the respective standards for SMTP and IMF.

In this article (and many other) you'll frequently see RFC5321 and RFC5322 mentioned. RFC (Request for Comments) documents define technical specifications for internet protocols.

RFC5321 (SMTP) defines the transport protocol for email (how email is sent). RFC5322 (IMF) defines the structure of an email (how the email looks to users).

The Simple Mail Transfer Protocol (SMTP) was first introduced in RFC821 in 1982, which was replaced by RFC2821 in 2001, then finally replaced by RFC5321 in 2008. The Internet Message Format (IMF) was first introduced in RFC822 in 1982, which was replaced by RFC2822 in 2001, then finally replaced by RFC5322 in 2008.

The different addresses in an email

Now that we understand how email is modelled after the postal system, we can start to make sense of the various addresses that are used within email.

It's also important to understand that the addresses on an envelope and the letter don't necessarily have to be the same.

^{*This is either the command used in SMTP, or the name of the header in the email message.}

Addresses on the SMTP envelope

To deliver an email the outbound (sending) host connects to the inbound (receiving) SMTP host. The outbound service issues SMTP commands to establish an SMTP session. During this session initiation the inbound and outbound SMTP service exchange various addresses for routing and basic authorization purposes.

It is important to understand that in SMTP the envelope is discarded upon delivery. This means that the recipient will not see addresses that are on the envelope in their email application, only the addresses in the headers are visible to the recipient.

RFC5321.Helo

RFC5321.Helo is the hostname of the outbound (sending) SMTP service. It is used by the inbound SMTP service for basic authentication of the sender.

During the SMTP session initiation phase the outbound (sending) SMTP host issues the EHLO command to identify itself with its hostname. The inbound (receiving) SMTP verifies that the IP address of the outbound service matches the DNS response for the hostname.

Notice that HELO and EHLO aren't typos. In very early SMTP standards the command to start the SMTP handshake process was HELO (abbreviation of 'hello'). This command was later deprecated in favor of the EHLO (extended hello), which added support for negotiating SMTP options.

Even though EHLO was introduced in 1995 and has been the recommended handshake command since, this address is still typically referred to as the 'helo' address.

RFC5321.MailFrom

Once the SMTP session is initiated using the EHLO command the mail transaction is initiated by the outbound (sending) host by issuing the MAIL FROM command followed by an email address that identifies the origin of the message. This does not necessarily have to be the address of the sender of the message itself, it may also be the address of the organization providing the SMTP service. In the paper analogy this could be the address of the corporate mail room that stamped and sent the message, not the address of the desk of the sender.

Initially this address's sole intended purpose was to serve as a path 'back' to the sender, to send an error message to if the message turned out to be undeliverable at a later stage. This is the process now better known as 'bouncing'. The original SMTP standard RFC821 from 1982 referred to this address as the reverse-path address, and even marked it as optional.

Later the SMTP standard evolved to where this address is no longer just used as a return path. The address following the MAIL FROM command also began to be used for basic authorization. For example: the inbound host may use SPF to determine if the outbound host (identified using the RFC5321.Helo address) is a delegated sender for the domain in the MAIL FROM address.

In later versions of the SMTP standard (RFC2821 in 2001 and finally RFC5321 in 2008) the name reverse-path was retained mainly for legacy reasons. But due to it no longer accurately describing its purpose, a sprawl of different names for this address started to emerge. Some common names are mfrom, return-path, bounce address, envelope from, envelope sender, MAIL FROM, return address and Errors-to. All these terms are used to describe the same address: the address followed after the MAIL FROM SMTP command.

For this article (and all other articles in the Mailhardener knowledge base) we'll use the name RFC5321.MailFrom.

This is the naming convention commonly used in more contemporary RFCs. We believe this name clarifies the address is used at the SMTP level (RFC5321) following the MAIL FROM command, and does not make assumptions about its intended purpose.

The RFC5321.MailFrom address is the address of the organization providing the outbound SMTP service. If for example you send email from info@yourdomain.tld using a third-party marketing platform, then the RFC5321.MailFrom address may be something like bounces@marketingplatform.tld.

RFC5321.RcptTo

After the MAIL FROM command is accepted by the inbound SMTP host, the outbound host issues the RCPT TO (recipient to) command, followed by the email address of the recipient, the inbox address that the email message is intended for.

It is used by the inbound (receiving) SMTP service to determine where the message should be routed to. This route can be internal (for delivery), or external by relaying to a different SMTP service.

The RFC5321.RcptTo address is typically equal to the RFC5322.To address, though technically they can differ. Contemporary SMTP services may reject the email if the addresses do not match.

After the RCPT TO command is accepted the outbound SMTP sends the email message using IMF encoding, after which the session is closed.

Addresses in email message headers

An email message in Internet Message Format (IMF) contains various headers, some of which are used for addressing the sender and recipient.

RFC5322.From

This is the sender address that is in the email message From header. It is the sender address that is actually shown to the receiver in the email program.

As with RFC5321.MailFrom there are many different names used for this address. It may also be known as RFC5322.Sender, from address or simply the sender.

For this article (and all other articles in the Mailhardener knowledge base) we'll use the term RFC5322.From.

If you use the reply function in your email application, this is where your reply is sent to unless there is a RFC5322.ReplyTo address defined.

RFC5322.To

This is the address of the intended recipient as placed in the message headers. In the paper analogy, this is the receiver address written on the letter itself.

Technically it's possible to have different addresses in RFC5322.To and RFC5321.RcptTo, but there is no practical use-case for that. Most contemporary SMTP services will reject the email if the addresses do not match.

RFC5322.ReplyTo

This is an optional address that can be defined in the email message headers. The header is Reply-To and can contain exactly one email address.

This address is used when an organization prefers any follow-ups to a message to be handled by a certain person or department.

If you use the reply function in your email application and this header was set in the original message, then your email application will use that email address to send the reply to. If the RFC5322.ReplyTo address is not set, it will use the RFC5322.From address to send the reply to.

Diagnostic headers

SMTP sessions are only used during transport, after delivery the SMTP session (the envelope) is typically discarded. In the paper mail analogy the envelope (the SMTP session) would be discarded by the mail room before the letter is delivered to the mail inbox of the recipients' desk.

The envelope addresses and other relevant information would be lost after the email is delivered. For this reason, the inbound SMTP service may inject headers containing information from the envelope, that may help to diagnose delivery issues.

Note that due to security, efficiency and privacy reasons header injection (particularly that of the return path) may also not be desirable anymore. Some larger email infrastructures (such as email service providers) may be using proprietary systems (not SMTP) for internal routing of email, and as such won't be using standardized diagnostic headers.

RFC5322.ReturnPath

In the original relaying design of SMTP, the various SMTP hosts the email passed through (the 'hops') would have to store the RFC5321.MailFrom address somewhere to be able to relay the email back in case it bounced later on. Though this information could be stored by the SMTP service itself, it was more flexible and cost-effective to store the path in the email message itself by injecting path information into the email headers.

The various email message standards provisions this by specifying the Return-Path as a 'trace' header that inbound SMTP services can inject into the email message.

Due to contemporary email systems no longer using public relaying anymore the reliance on the path headers has declined. As such, the purpose of the RFC5322.ReturnPath header has shifted from being a technical requirement to an optional solution for diagnosing delivery issues and helping the recipient assess the authenticity of an email.

Some email applications will show the origin of the email if the domain in the RFC5322.ReturnPath differs from that of the sender address. It typically looks like John Doe <john@domain.tld> via <marketingplatform.tld>.

RFC5322.DeliveredTo

The address (inbox) this email was eventually delivered to.

Emails may be delivered in a different inbox than what the sender specified in the RFC5322.To header in a process known as address rewriting (sometimes incorrectly referred to as 'forwarding').

Typical use-cases of address rewriting are:

• catch-all inboxes
• creating automatic copies to a specific inbox (typical for support or sales inboxes).
• redirecting email from former inbox (for example: former employees, former departments) to alternative inbox
• changing (domain)name of organization, for example email sent to recipient@oldname.tld getting delivered to recipient@newname.tld.
• catching common typos in the recipient name or domain (prevent typo-squatting fraud)

Just like with the Return-Path header, the Delivered-To header is added by the inbound (receiving) SMTP service mainly for troubleshooting.

If no address rewriting is used, the Delivered-To header can be expected to match RFC5322.To address, which in turn should match the RFC5321.RcptTo value if SMTP was used.

In case SMTP relaying was used, the Delivered-To can be expected to match the RFC5321.RcptTo of the last hop before delivery. The delivered-to header is then injected by the last inbound SMTP service in the path, which is authoritative for the inbox and making the final delivery.

An email should contain 1 Delivered-To header maximum. If the email had multiple recipients, the Delivered-To contains the address of the recipient that this copy was delivered to.

Different sender on envelope

The sender address on the envelope (RFC5321.MailFrom) may differ from the sender address on the message itself (RFC5322.From).

In the paper mail analogy this usually happens for large corporations where an undeliverable letter should be returned to the mail room, instead of the office of the sender.

With email, a different RFC5321.MailFrom address is commonly used for bounce tracking. For instance: we may use info@mailhardener.com as the RFC5322.From address, and bounces@mailhardener.com as the RFC5321.MailFrom address for automated bounce detection.

If an external service is used to send email, such as an e-commerce or marketing platform, it is common that this service uses its own domain name in the RFC5321.MailFrom address, and your domain in the RFC5322.From address.

Addresses affecting SPF

SPF is an anti-spam mechanism where a domain owner can publish a policy on which servers are allowed to send email for their domain. You can read more about SPF in our main article about SPF.

SPF uses the RFC5321.MailFrom address on the envelope to determine if the sending server is allowed to send email for the domain name in the address.

A common 'workaround' for SPF by spammers is to use a RFC5321.MailFrom address from a domain that they control, and then publish a policy allowing themselves to send email for that domain. This is why many email services now show a warning if the RFC5321.MailFrom domain differs from the domain in the RFC5322.From address.

Addresses affecting DKIM

DKIM is an email authentication and authorization mechanism that adds cryptographic signatures to email messages. This enables authentication (proof that the email is authentic) and authorization (proof that the sender is allowed to send on behalf of the domain). You can read more about DKIM in our main article about DKIM.

DKIM signatures are independent of the sender address, as the domain that hosts the public key DNS record can be specified in the d= (domain) part of the DKIM header. An email message can contain multiple DKIM signatures, signed by various domains.

However, in order to achieve DMARC DKIM alignment, at least one on the DKIM signatures must have a d= value that matches the RFC5322.From address.

Addresses affecting DMARC

DMARC is a standard that aims at reducing spam and fraud by extending SPF and DKIM with the alignment requirement. You can read more about DMARC in our main article about DMARC.

In DMARC terms, a message is considered SPF aligned if the domain names in the RFC5321.MailFrom and RFC5322.From address are equal. An email is considered DKIM aligned if it contains at least one DKIM signature where the d= property matches the domain in the RFC5322.From address.

If an email is not SPF or DKIM aligned, the receiver may reject the email, following the DMARC policy published by the domain in the RFC5322.From address.

In the DMARC policy published by the domain owner it can be specified if the domains in the various email addresses must be an exact match (known as strict alignment), or if subdomains are allowed (known as relaxed alignment).

See also

• SPF
• DKIM
• DMARC

Updates

• 01-08-2022: Added information on the Return-Path and Delivered-To header.
• 10-10-2023: Added information on the HELO/EHLO host address.
• 23-01-2025: Restructured article to clarify inner workings of SMTP

Written by: Léon Melis
Illustrations by: Margot Beun