Every email carries two sender addresses that serve entirely different purposes. MAIL FROM is a low-level Simple Mail Transfer Protocol (SMTP) instruction that mail servers use to route messages and handle bounces — recipients never see it. The FROM field is what appears in the recipient's inbox as the visible sender. Understanding this distinction is essential for diagnosing deliverability issues and identifying spoofed or phishing emails.
MAIL FROM
MAIL FROM is a command in the SMTP protocol that one mail server uses to identify itself to another during an email transaction. It is also called the envelope from, Return-Path, or bounce address — you may encounter any of these names in mail logs, email headers, or tool documentation.
When a message cannot be delivered, the receiving server sends a bounce notification to the address specified in MAIL FROM. This address is also used for reverse path validation to confirm the email's source, and is evaluated during Sender Policy Framework (SPF) authentication: the receiving server checks whether the sending server is authorized to send mail on behalf of the MAIL FROM domain.
MAIL FROM is not displayed to the recipient. It is infrastructure-level data, handled entirely between servers.
FROM field
The FROM field (also called the header from or From: header) is part of the message header and is displayed directly in the recipient's email client. It contains the sender's email address and, optionally, a display name — for example, Alice Johnson <alice@example.com>. The FROM field can contain one or more email addresses.
Unlike MAIL FROM, the FROM field is not validated by the SMTP protocol itself. Its content can be set to any value, which makes it the primary vector for email spoofing and phishing.
Summary of differences
|
Aspect |
MAIL FROM (envelope from) |
FROM field (header from) |
|
Purpose |
Routes the message and handles bounces |
Displays the sender to the recipient |
|
Visibility |
Hidden — used only between mail servers |
Visible in the recipient's email client |
|
Authentication |
Evaluated by SPF and DMARC |
Evaluated by DomainKeys Identified Mail (DKIM) and DMARC |
|
Can be spoofed |
Constrained by SPF |
Yes, without additional controls |
MAIL FROM is a technical SMTP command used between mail servers to identify the bounce address and authorize the sending domain. It is validated by SPF authentication and is never shown to the recipient.
The FROM field is part of the message header and is what recipients see as the sender. Its content is not enforced by the SMTP protocol, so it must be verified through DKIM signatures and Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy.
When MAIL FROM and FROM legitimately differ
A mismatch between MAIL FROM and FROM is not always a sign of spoofing. Many legitimate email configurations intentionally use different values:
Bounce handling: A sender may use a dedicated subdomain for MAIL FROM (such as
bounces.example.com) to isolate bounce traffic and track delivery failures without mixing them with other inbound mail.Email service providers: When sending through a third-party provider, the provider often sets MAIL FROM to a domain it controls (for SPF alignment), while FROM displays your branded address.
A mismatch is a concern when the MAIL FROM domain has no legitimate relationship to the FROM domain — for example, when a phishing email shows a trusted brand in FROM but routes bounces to an unrelated domain.
Security implications
Because the FROM field can be freely set, authentication protocols are required to verify that it accurately reflects the true sender:
SPF checks whether the sending server is authorized for the MAIL FROM domain.
DKIM adds a cryptographic signature tied to the FROM domain, confirming the message was not altered in transit.
DMARC defines a policy that links SPF and DKIM results back to the FROM domain, and specifies what to do when alignment fails.
When handling sensitive or high-value emails, verify that the MAIL FROM domain and the FROM domain are aligned and that DMARC policy is enforced. A mismatch with no SPF or DKIM coverage is a strong indicator of spoofing.