Envelope Sender vs Header From: Email's Two From Addresses

Almost every email carries two different 'from' addresses, and most of the time you only ever see one of them. The distinction — envelope sender vs header From — is the single idea that makes SPF, DMARC, bounce handling, and Gmail's 'via' notice click into place.

One address rides on the outside of the message, in the SMTP delivery conversation. The other sits inside the message, in the From: line your mail app prints at the top. They usually match. When they do not, that mismatch is either completely normal or a warning sign — and this article is about telling the two apart.

The short version: two addresses, two jobs#

The envelope sender is the address the mail servers talk about while they hand the message from one server to the next. It is set by the SMTP MAIL FROM command and defined in RFC 5321. Its job is delivery: routing the message and receiving a bounce if delivery fails.

The header From is the From: line defined in RFC 5322. Its job is human: it tells the reader who wrote the message. Your mail client shows it; the sending servers largely ignore it.

Because they serve different jobs, they are allowed to hold different addresses. A newsletter from a brand often has the brand in the header From and the sending platform in the envelope sender. That is legitimate. The trouble starts only when you assume the visible From has been checked — it usually has not.

Envelope sender vs header From at a glance#

Here is the whole distinction in one view. Most email-authentication confusion comes from mixing up which column a rule applies to, so keep this table handy.

The envelope sender: MAIL FROM, Return-Path, and where bounces go#

The envelope sender begins life as one line in the SMTP conversation: MAIL FROM followed by a reverse-path. RFC 5321 calls the address in that command the reverse-path, and says it 'contains the source mailbox... which can be used to report errors.' In plain terms: this is the address that receives bounces.

You do not normally see the envelope sender, because it is part of the envelope, not the message. But it leaves a trace. When the delivery server makes final delivery, RFC 5321 says it inserts a Return-Path: header at the top of the message, preserving the reverse-path from the MAIL command. So the Return-Path header you can find in an email's raw source is the envelope sender, written down.

This is why 'Return-Path', 'envelope sender', 'envelope from', '5321.MailFrom', and 'bounce address' all name the same thing. They are one address seen from different stages of delivery.

It also answers the bounce question directly. If a message cannot be delivered, the error report goes to the envelope sender — the Return-Path — not to the From address the reader sees. Email platforms rely on this: they set a Return-Path on their own domain so bounces land in their system for processing, while your brand stays in the From line.

The header From: what you actually see#

The header From is the From: field defined in RFC 5322, section 3.6.2. The standard says it 'specifies the author(s) of the message, that is, the mailbox(es) of the person(s)... responsible for the writing of the message.' It lives inside the message headers, and it is the address every mail client displays at the top of the email.

Two things about it matter here. First, it is content: the sender writes it, the same way they write the subject line or the body. Nothing in the SMTP delivery layer forces it to match the envelope sender. Second, RFC 5322 also defines a separate Sender: header for the case where the person who sent the message is not its author — a secretary sending on behalf of an executive, in the standard's own example.

Because the From line is just text, a sender can put any name and any address in it. A message sent from an attacker's own server can still display a From line reading PayPal, service at paypal.com. The mail arrived from somewhere else entirely, but the From line says what the attacker typed. This is display-From spoofing, and it is why the From address alone is not proof of who sent an email.

Does SPF check the From address? No — and that is the point#

No, and this is the most useful thing to understand in the whole topic. SPF, defined in RFC 7208, authenticates the envelope sender — the RFC5321.MailFrom identity — and the server's HELO name. It does not check the From: header the reader sees.

RFC 7208 is explicit that SPF is scoped to those envelope-level identities, and warns that checking other identities against an SPF record 'is NOT RECOMMENDED,' partly because senders such as mailing lists rewrite the envelope while leaving the message headers unchanged.

The consequence is the gap that catches people out: a message can pass SPF and still carry a forged From line. An SPF pass means 'the server that sent this was authorized for the envelope sender's domain' — nothing more. It says nothing about whether the visible From is real.

DMARC is the standard that closes the gap. DMARC — defined in RFC 9989, published in 2026 to replace the older RFC 7489 — requires the domain in the header From to 'align' with a domain that actually authenticated: either the SPF-checked envelope domain, or the domain that signed the message with DKIM. Only when the visible From lines up with real authentication does DMARC pass. That is why DMARC, not SPF, is what protects the address your reader sees.

Why does Gmail show 'sent via another domain'?#

Once you can see the two addresses, the 'via' note stops being mysterious. Gmail — and other mail clients with similar labels — adds 'via example.com' when the domain that actually sent and authenticated the message differs from the domain in the From line.

The everyday example is a newsletter. The From line says a brand address, but the message was sent and DKIM-signed through an email platform on a different domain. Gmail authenticated the platform's domain, noticed it does not match the From domain, and tells you so with 'via'.

When the 'via' note matters, and when it does not#

That note is usually not a problem — it is the normal shape of mail sent through a third-party platform. But it is a visible symptom of the same split this article is about: what you see (the From domain) is not always what authenticated (the envelope or DKIM domain).

Senders remove the 'via' note by aligning the two — using a Return-Path and a DKIM signature on the same domain as the From address. That alignment is also what makes DMARC pass, so fixing one fixes the other.

Who needs to care about which#

Which address you should focus on depends on what you are trying to do.

• Reading email: the header From is what you judge a message by — but never on its own. A name you recognise plus an unexpected request is exactly the pattern spoofing exploits.
• Running a mail server or app: the envelope sender is what you set for bounces and what SPF authenticates. Get the Return-Path right or your bounce handling breaks quietly.
• Sending marketing or transactional mail: align the envelope sender and DKIM domain with your From domain. That is what removes the 'via' note and lets DMARC pass.
• Securing an organisation: assume the From line is spoofable and lean on DMARC alignment, not SPF alone, to decide whether a message's visible sender can be trusted.

What a mail client can do about the gap#

No mail client can change how SMTP works — the two addresses are part of the protocol, and any tool claiming to 'fix' the split is misdescribing it. What a client can do is read the authentication results already sitting in the headers and put them in front of you, instead of leaving you to open the raw source.

That is where our own product fits. AI Emaily's spam and phishing protection reads the SPF and DMARC results in each message's headers and flags mail whose visible From does not align with what actually authenticated — the exact display-From spoofing gap this article describes. It also treats message content as untrusted input, so a convincing From line does not buy an email any special trust. We build AI Emaily.

The honest limit: AI Emaily is a mail client, not a DMARC monitoring service. It does not publish or audit your domain's DNS records, and it will not generate aggregate DMARC reports for a domain you send from — that is a separate class of tool. What it does is make the authentication story of the mail you receive legible, and stop the spoofed messages that rely on you not checking.