Email address types explained

Emails can contain multiple addresses like the sender address, receiver address, 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.

Envelope and message

Just like a paper letter, an email consists of 2 parts: the envelope and the message (letter) itself. The envelope is used by the email servers for routing, just like a paper envelope is used by the postal services. The envelope contains the address where the message must be delivered, and the return address of the sender. Inside the envelope is the message (the letter) itself, it contains the address of the receiver and the sender. Just like on a paper letter, the return address on the envelope may differ from the sender address on the letter. If the email is undeliverable it will be returned to the sender address on the envelope, hence why this address is sometimes referred to as the return address.

The envelope

For email, the envelope is the information that is exchanged between email servers using the simple mail transfer protocol (SMTP). SMTP is defined in a standard known as RFC5321.

As the name implies, SMTP is a simple protocol, the commands exchanged between email servers are in fact so simple that they can be typed by hand. SMTP is only used for communication between email servers. Once the email is delivered into the receiver's mailbox, a different protocol is used to get the email message to the computer of the receiver.

Note that an email can pass through multiple email servers before it reaches the inbox of the recipient. Each server communicates with SMTP to the next, and on every hop the envelope is discarded and replaced with a new one.

The message

The message in an email is also inspired by paper mail, its format is defined in the RFC5322 standard. The message consists of headers and the message body. The headers contain information about the email, just as the header on a (formal) letter. Here you find things like the sender address (as shown in your email program), the recipient, the time and the subject of the email. The header can also contain more technical information such as styling (font, fontsize, etc.), 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. It may also contain file attachments.

The different addresses on an email

When an email is sent, the following addresses are set by the sender:

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

SMTP addresses

RFC5321.MailFrom

This is the sender email address that is used in SMTP (the envelope). It is used by email servers to use as a return path if the message turns out to be undeliverable.

When SMTP was first defined in 1982 (the standard that later became RFC5321), it was simply called the 'from' address. The name of this address was never formally defined, and as a result there are many names used for this address. Some of them are: RFC5321.FROM, bounce address, envelope from, envelope sender, MAIL FROM, 5321-FROM, return address, From_, Errors-to. All these terms are used to describe the same address: the sender address on the envelope.

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

Note that the SMTP envelope is discarded on delivery, so the RFC5321.MailFrom address is lost. Most email servers will inject the RFC5321.MailFrom address into the email headers as a RFC5322.ReturnPath address.

RFC5321.RcptTo

This is the recipient email address that is used in SMTP (the envelope). It is used by email servers to determine where the message should be routed to.

This address is usually equal to the RFC5322.To address, there is no real use-case to use different addresses in RFC5321.RctTo and RFC5322.To.

Since this address is only used in SMTP (the envelope), it will be discarded upon delivery to the inbox. As with RFC5321.MailFrom most email servers will store this address in the message headers as a RFC5322.DeliveredTo address for tracing purposes.

Email headers

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 is no formal name for this header, so 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 RFC5421.RcptTo, but there is no practical use-case for that.

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

The following addresses may be added to the email headers by email servers during transport, they are used for troubleshooting:

RFC5322.ReturnPath

As we explained an email can travel through multiple servers before it reaches the inbox of the recipient. Each server discards the SMTP envelope and creates a new one for the next hop.

If, at some point the message cannot reach the next hop, it will be sent back to the previous server using the RFC5321.MailFrom address. The problem is that on each hop the SMTP envelope, and thus the previous RFC5321.MailFrom value is discarded.

To retain information on the path the email took, each server injects the RFC5321.MailFrom address into a header called Return-Path. An email can contain multiple Return-Path headers. The Return-Path values can be used to trace back the path the email took.

RFC5322.DeliveredTo

This address is usually injected into the email headers by the last email server the email passes through.

Just like with the Return-Path header, the Delivered-To header is added mainly for troubleshooting. The Delivered-To header is set to the RFC5321.RcptTo value from the SMTP envelope, so the information is not lost when the SMTP envelope is discarded.

An email should contain 1 Delivered-To header maximum. It may be a different value than the RFC5322.To header, this happens if an email is automatically forwarded.

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 RCF5321.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 their own domain name in the RFC5321.MailFrom address, and your domain in the RFC5322.From address.

Addresses and 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 and DKIM

DKIM is an email hardening 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 and DMARC

DMARC is an anti-spam and fraud mechanism that extends SPF and DKIM by checking the used domains for alignment. You can read more about DMARC in our main article about DMARC.

In DMARC terms a message is SPF aligned if the domain names in the RFC5321.MailFrom and RFC5322.From address are equal. If an email is not aligned, the email may fail DMARC inspection and the receiver will follow the policy published by the domain owner on how to treat that email.

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
• DMARC

Updates

• 01-08-2019: Added information on the Return-Path and Delivered-To header.

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