Header-From vs envelope-from: the two From addresses

6 April 2026 · 12 min read

Every email you send carries two different "From" addresses, and almost no one ever sees the second one. The address your recipient reads in their mail client is one thing. The address the sending and receiving servers actually argue about during delivery is something else entirely. When people are confused about why DMARC passes for one message and fails for another that looks identical, the answer is nearly always that they have mixed up these two addresses, or assumed there was only one.

This article is about those two addresses: the header-from (formally RFC5322.From, sometimes written 5322.From) and the envelope-from (formally RFC5321.MailFrom, also called the MAIL FROM, the bounce address, or the return-path). Getting the distinction right is the single biggest unlock for understanding SPF, DMARC alignment, forwarding breakage, and why a "valid SPF pass" can still mean your domain is wide open to spoofing.

The envelope and the letter

The cleanest way to hold the two addresses in your head is the postal analogy that the email standards themselves lean on.

When you post a physical letter, there are two layers:

• The envelope has a delivery address and a return address. The postal service reads only the envelope. It never opens the letter.
• The letter inside has its own "Dear..." greeting and its own sign-off at the bottom. The postal service does not care what the letter says.

Email works exactly the same way. SMTP, the protocol that moves mail between servers, is the postal service. It reads the envelope. The message your recipient eventually opens, with its From:, To:, Subject: and body, is the letter inside. The receiving mail server treats those as two distinct sets of addresses, set at two different moments in the conversation, and they do not have to match.

That last point is the whole story. They do not have to match, attackers exploit the gap, and DMARC exists precisely to close it.

The envelope-from (RFC5321.MailFrom)

The envelope-from is set during the SMTP conversation itself, before any message content is transmitted. When a sending server connects to a receiving server, the exchange looks roughly like this:

220 mx.recipient.com ESMTP ready
HELO mail.sender.com
250 Hello mail.sender.com
MAIL FROM:<bounces@sender.com>
250 OK
RCPT TO:<alice@recipient.com>
250 OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
... the message headers and body go here ...
.
250 OK: queued

The address inside MAIL FROM:<...> is the envelope-from. In this example it is bounces@sender.com. Notice that it is transmitted before DATA, which means it is set before the receiving server has even seen the From: header. It is part of the transport-level conversation, not part of the message.

The envelope-from has one practical job in normal operation: it is the return address for bounces. If alice@recipient.com does not exist, or her mailbox is full, the receiving server generates a non-delivery report and sends it back to the envelope-from address. This is why bulk senders almost always use a dedicated address such as bounces@, bounce@, or a per-message VERP address like bounce+alice=recipient.com@sender.com. Those addresses feed automated bounce processing and list hygiene, so it makes sense to keep them separate from the human-facing brand address.

Once the message is accepted, the envelope-from is recorded in a header called Return-Path:, which the receiving server stamps at the top of the message. That is the one place a curious recipient can actually see it, but only by opening the raw headers. We cover this header in the glossary entry for the return-path.

The key facts about the envelope-from:

• It is set at the SMTP MAIL FROM command, before the message body.
• The recipient never sees it in their normal inbox view.
• It is the address bounces are returned to.
• SPF checks this address, not the one the human reads. Hold that thought.

The header-from (RFC5322.From)

The header-from is the From: line inside the message itself, part of the DATA payload. It is what your mail client displays as the sender. When Outlook or Gmail shows you "Acme Billing <billing@acme.com>", it is rendering the header-from.

A header-from has two parts: an optional display name and the actual address.

From: Acme Billing <billing@acme.com>

Here "Acme Billing" is the display name and billing@acme.com is the addr-spec, the part that matters for authentication. The domain of the addr-spec, acme.com, is what we call the header-from domain or the organisational domain of the visible sender. (Strictly, DMARC reduces it to the organisational domain using the public suffix list, so mail.acme.com and acme.com share a policy unless a subdomain policy says otherwise.)

The header-from is the address a human trusts. Nobody inspects the envelope. People glance at the visible From: and decide whether to trust the message. That is exactly why spoofers care about it, and why DMARC anchors its entire model to it. The glossary entry for header-from goes deeper on the structure.

The key facts about the header-from:

• It lives inside the message DATA, in the From: header.
• It is the address the recipient actually sees and trusts.
• DMARC checks this address. Its domain is the identity DMARC is protecting.
• Display-name spoofing abuses the human-readable label without changing the domain, which DMARC alone cannot stop (see display-name spoofing).

Why two addresses at all

If this seems needlessly complicated, there is a good historical reason. SMTP was designed in 1982, long before spam and phishing were a concern. The split between envelope and content existed so that mailing lists, gateways and relays could rewrite the bounce destination without touching the message a human reads.

A mailing list is the classic example. When you post to list@discuss.example, the list software resends your message to hundreds of subscribers. It keeps your From: header so people can see who wrote the post, but it changes the envelope-from to the list's own bounce-handling address, because the list operator, not you, needs to process the bounces from dead subscriber addresses. This is sensible engineering, and it predates any notion of authentication.

The trouble is that this same flexibility means an attacker can put billing@yourbank.com in the visible From: while using attacker@randomvps.cloud as the envelope-from. The two layers were never required to agree, so for decades anyone could forge the visible sender for free. SPF, DKIM and DMARC are the layers bolted on afterwards to constrain that freedom.

Which protocol checks which address

This is the part people get wrong most often, so it is worth being blunt.

SPF checks the envelope-from domain. When a receiver evaluates SPF, it takes the domain from the MAIL FROM (falling back to the HELO identity if MAIL FROM is empty, as it is for bounce messages) and looks up that domain's SPF record. It then asks: was the connecting IP authorised to send for that domain? SPF has no knowledge of, and never inspects, the visible From: header. You can confirm what a domain publishes with our SPF checker, but remember it is checking the envelope domain's policy.

DKIM checks whatever domain signed the message. DKIM is independent of both From addresses. The signing server adds a DKIM-Signature: header containing a d= tag naming the signing domain, and a cryptographic signature over selected headers and the body. The d= domain is whatever the signer chose. It might equal the header-from domain, it might not. Validate a published key with the DKIM checker.

DMARC checks the header-from domain, and only that. DMARC looks up the DMARC record at _dmarc.<header-from-domain>, then checks whether at least one of SPF or DKIM passed and aligned with the header-from domain. Use the DMARC checker to see a domain's published policy.

That phrase "passed and aligned" is the hinge, and it is the reason the two From addresses matter at all.

Alignment: where the two addresses finally meet

SPF can pass while DMARC fails. This single fact surprises almost everyone, and the cause is the two From addresses.

DMARC does not just ask "did SPF pass?" It asks "did SPF pass for a domain that matches the header-from?" That matching requirement is alignment. We have a full explainer in DMARC alignment, explained and the dmarc-alignment glossary entry, but here is the core mechanism.

For SPF alignment, DMARC compares:

• the envelope-from domain (the one SPF authenticated), against
• the header-from domain (the one the human sees).

If they match, SPF is aligned and contributes a DMARC pass. If they do not match, SPF can still pass on its own terms, but it does not satisfy DMARC.

For DKIM alignment, DMARC compares:

• the DKIM d= domain (the one that signed), against
• the header-from domain.

If they match, DKIM is aligned and contributes a DMARC pass.

DMARC passes if either SPF or DKIM passes and is aligned. It does not require both.

Alignment has two modes, set by the aspf and adkim tags in the DMARC record. Relaxed (the default) treats subdomains as aligned with their organisational domain, so an envelope-from of bounces.acme.com aligns with a header-from of acme.com. Strict demands an exact domain match. Most senders should stay in relaxed mode; strict alignment breaks more legitimate mail than it gains in security.

A worked example: SPF passes, DMARC fails

Consider a marketing email sent through an email service provider (ESP) that has not been configured for alignment. The headers might look like this:

Return-Path: <bounce@esp-shared-mail.net>
From: Acme News <news@acme.com>
DKIM-Signature: v=1; d=esp-shared-mail.net; s=k1; ...

Walk it through:

• SPF authenticates the envelope-from domain esp-shared-mail.net. The ESP's IP is listed in that domain's SPF record, so SPF passes.
• SPF alignment compares esp-shared-mail.net (envelope) with acme.com (header-from). They do not match, so SPF is not aligned.
• DKIM verifies against d=esp-shared-mail.net. The signature is valid, so DKIM passes.
• DKIM alignment compares esp-shared-mail.net (signer) with acme.com (header-from). They do not match, so DKIM is not aligned.
• DMARC result: neither SPF nor DKIM is aligned, so DMARC fails, even though both SPF and DKIM individually passed.

If acme.com is at p=reject, this perfectly legitimate newsletter is rejected. The fix is not to weaken DMARC. The fix is to make at least one identity align: have the ESP send from a custom bounce domain like bounce.acme.com (which aligns the envelope-from in relaxed mode), or sign with a key whose d= is acme.com using a CNAME'd selector that the ESP provides. Most reputable ESPs support one or both. This misconfiguration is so common we wrote it up as one of the most common DMARC mistakes.

Now flip it. Here is the same acme.com brand, but this time with DKIM properly aligned:

Return-Path: <bounce@esp-shared-mail.net>
From: Acme News <news@acme.com>
DKIM-Signature: v=1; d=acme.com; s=esp1; ...

SPF is still unaligned, but DKIM now signs with d=acme.com, which matches the header-from. DKIM is aligned, DMARC passes on the strength of DKIM alone, and the envelope-from being a shared ESP domain no longer matters. This is exactly why DKIM alignment is the more robust of the two, and why we generally recommend leaning on it.

Why DKIM alignment survives forwarding and SPF does not

There is a second reason the header-from versus envelope-from split matters: forwarding.

When a message is forwarded, for instance from a .alumni redirect or a mailing list, the forwarding server connects to the next hop and issues its own MAIL FROM. It almost always rewrites the envelope-from to its own bounce address, because it now owns the bounce handling. The original envelope-from is gone. SPF at the final destination therefore checks the forwarder's domain against the forwarder's IP, which passes, but it is now hopelessly misaligned with the original header-from. SPF alignment is destroyed by forwarding, every time.

DKIM, by contrast, signs the message content, including the From: header. As long as the forwarder does not modify the signed headers or the body, the DKIM signature still verifies at the destination, still names the original d= domain, and still aligns with the unchanged header-from. This is why a sender relying only on SPF alignment sees DMARC failures whenever their mail is forwarded, while a sender with aligned DKIM rides through forwarding intact. We go deeper in DKIM alignment and forwarding and forwarding and DMARC.

The practical takeaway: never rely on SPF alignment alone. Treat aligned DKIM as your primary DMARC pass and SPF alignment as a bonus.

How spoofers abuse the gap, and how DMARC closes it

Understanding the two addresses also explains exactly what DMARC defends against and what it does not.

A classic exact-domain spoof puts your domain in the visible From: while sending from infrastructure you do not control:

Return-Path: <noreply@attacker-vps.example>
From: Acme Billing <billing@acme.com>

SPF authenticates attacker-vps.example, which may well pass for the attacker's own domain, but it is not aligned with acme.com. There is no DKIM signature with d=acme.com because the attacker does not have your private key. So both alignment checks fail, DMARC fails, and at p=reject the message is thrown away before it reaches the inbox. This is the core protection DMARC provides, and it works precisely because DMARC anchors to the header-from that the victim would actually read. See email spoofing, explained for the broader picture.

What DMARC does not stop is anything that leaves the header-from domain untouched:

• Display-name spoofing, where the attacker writes From: Acme Billing <billing@totally-different.com>. The domain is honestly the attacker's, DMARC for acme.com is never consulted, and only the display name is misleading. DMARC is silent here by design.
• Lookalike domains, such as acme-billing.com or acrne.com. Each of those is a real, attacker-owned domain that can publish its own passing, aligned DMARC. DMARC confirms the message genuinely came from acrne.com; it cannot know you meant acme.com.

These are not DMARC failures, they are the boundary of what authentication can do. They are why DMARC sits alongside BIMI, user training and lookalike monitoring rather than replacing them.

Reading the two addresses in a real message

You can see all of this yourself in any message you receive. Open the raw source (in Gmail, "Show original"; in Outlook, "View source") and look for:

• Return-Path: near the top, stamped by the receiving server. This is the envelope-from, the address SPF checked.
• From: in the message headers. This is the header-from, the address DMARC checked.
• Authentication-Results: if your provider adds it, which spells out spf=, dkim= and dmarc= verdicts and frequently shows the domains each one used.

If Return-Path: and the From: domain differ, that is not automatically suspicious. It is completely normal for ESP-sent and forwarded mail. What matters is whether at least one of SPF or DKIM aligned with the From: domain. Our email header analyzer parses all of this for you, and the DMARC report analyzer shows the same alignment verdicts aggregated across every source sending as your domain, which is where misconfigured services reveal themselves.

Putting it together for your own domain

If you take one thing from this article, let it be the mapping:

• Envelope-from (RFC5321.MailFrom): set at SMTP MAIL FROM, invisible to recipients, the bounce address, checked by SPF.
• Header-from (RFC5322.From): inside the message, the address humans see and trust, checked by DMARC.
• DMARC alignment is the rule that the SPF-authenticated domain (envelope) or the DKIM-signing domain must match the header-from. Without alignment, a passing SPF or DKIM does nothing for DMARC.
• Aligned DKIM survives forwarding; SPF alignment does not. Build your DMARC pass on DKIM.

The reason this matters in practice is that almost every "DMARC fails but the email is fine" ticket comes down to a service that is authenticated on the envelope but not aligned to the header-from. The diagnosis is always to identify which domain SPF and DKIM used, compare each to the header-from, and bring at least one into alignment, usually by configuring a custom return-path or a CNAME'd DKIM selector at the offending provider. You can review your current setup against the sender requirements, and our understanding your DMARC record doc explains the policy tags that govern alignment mode.

Start by running your domain through the DMARC checker to confirm your published policy, then feed a few days of real reports into the DMARC report analyzer to see exactly which sources are aligned and which are not. If untangling envelope-versus-header alignment across a dozen sending services sounds like more than you want to own, that is precisely the work our done-for-you hosted DMARC service handles: we align every legitimate source and walk your domain from p=none to p=reject without dropping a single real message.