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.
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.
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 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.
When an email is sent, the following addresses are set by the sender:
|The reply address (optional)
*This is the command used in SMTP, or name of the header in the email message.
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:
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
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
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
Since this address is only used in SMTP (the envelope), it will be discarded upon delivery to the inbox.
RFC5321.MailFrom most email servers will store this address in the message headers as a
RFC5322.DeliveredTo address for tracing purposes.
This is the sender address that is in the email message
It is the sender address that is actually shown to the receiver in the email program.
RFC5321.MailFrom there is no formal name for this header, so it may also be known as
from address or simply the
For this article (and all other articles in the Mailhardener knowledge base) we'll use the term
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.
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
RFC5421.RcptTo, but there is no practical use-case for that.
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.
The following addresses may be added to the email headers by email servers during transport, they are used for troubleshooting:
|The return path
|The delivery path
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
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
An email can contain multiple
Return-Path headers. The
Return-Path values can be used to trace back the path the email took.
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.
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.
The sender address on the envelope (
RFC5321.MailFrom) may differ from the sender address on the message itself (
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
firstname.lastname@example.org as the
RFC5322.From address, and
email@example.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
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
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
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
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).
On last thing: If you have questions, comments or thoughts on this article, don't hesitate to shoot us an email.
You can also follow and reach us on Twitter @Mailhardener.