From, Return-Path, and Envelope Sender: What They Are and Why DMARC Alignment Cares

An email carries three different sender identities. DMARC alignment deliberately checks two of them against the visible From header, and that single decision is the cause of most "DMARC failed but SPF and DKIM both passed" tickets. The From and Return-Path alignment is the underlying mechanism behind the majority of DMARC failures teams hit when they wire up a new sending tool. Once you understand which address is which, the failure mode stops looking like a bug and starts looking like the system working exactly as designed.

What are the three sender addresses in an email?

Every email has three different sender identities. None of them is a mistake. They are independent layers of SMTP and MIME.

The From header (RFC 5322) is set inside the message itself. It is what the recipient sees in their inbox. It is the brand of the email.

The Return-Path, also called the envelope sender or MAIL FROM, is set by the SMTP envelope during the SMTP conversation. It is where bounces and out-of-office auto-replies go.

The DKIM signing domain is identified by the d= tag inside the DKIM signature. It is the domain that owns the private key used to sign the message. It may or may not be the brand.

Here is what those three look like in a real header for a marketing message sent through a typical ESP that has been configured correctly:

From: Marketing 
Return-Path: 
DKIM-Signature: ... d=em.yourbrand.com ...

In this example all three point at your domain. Authentication passes. Alignment passes. The message is treated as legitimately from your brand.

Now the same brand, sent through an ESP that has not been configured for custom alignment:

From: Marketing 
Return-Path: 
DKIM-Signature: ... d=em1234.sendgrid.net ...

Authentication still passes. SPF checks the SendGrid sending infrastructure and returns pass. DKIM verifies against the SendGrid public key and returns pass. Alignment fails on both paths because neither the Return-Path domain nor the d= domain matches the From header.

What does DMARC alignment actually check?

DMARC checks alignment, not just authentication. Authentication is whether SPF and DKIM technically verify. Alignment is whether the verified domain matches the From header in the visible message.

SPF alignment requires the Return-Path domain to match the From header domain. DKIM alignment requires the d= domain in the signature to match the From header domain. Either alignment passing is enough to pass DMARC. Both can pass authentication and still fail alignment if they use a shared domain.

DMARC supports two alignment modes. Relaxed alignment (the default) accepts the same organizational domain, so bounces.brand.com aligns with From = brand.com. Strict alignment requires an exact match and must be requested explicitly with aspf=s and adkim=s.

Why do ESPs break alignment by default?

ESPs want their own domain in the Return-Path and in the DKIM signature. They use a shared Return-Path like bounces.em1234.sendgrid.net to serve thousands of customers from one infrastructure. They sign DKIM with em1234.sendgrid.net so the same key and signature can be reused across all customers. The ESP's perspective: this scales. The brand's perspective: this fails DMARC.

This is why a marketing team can see "everything passed" in the ESP dashboard and still get a DMARC aggregate report full of alignment failures. The dashboard reports authentication. The receiver enforces alignment. Those are two different checks.

How do you find out which sender is the offender?

Before changing any DNS records, open your DMARC aggregate report data and look for the alignment failures by sending source. Most teams have multiple ESPs sending on their behalf (transactional, marketing, billing, support) and only one of them is misconfigured.

A monitoring tool like DMARCFlow is built for exactly this step. It parses the XML aggregate reports, groups them by source IP and ESP, and shows the alignment pass rate per sender. A brand sending through SendGrid, Mailchimp, and an internal CRM can open DMARCFlow and see at a glance which one is the offender. Most teams find that one of their sources is at fault, not all of them. Knowing which one lets you fix the actual problem instead of guessing.

How do you fix alignment without changing ESPs?

The fix is to give the ESP a subdomain you control and configure it as both the Return-Path subdomain and the DKIM signing domain. Conventional naming:

• Custom Return-Path subdomain: bounces.brand.com
• Custom DKIM signing domain: em.brand.com

The ESP will tell you which subdomain to use and what records to publish. You will add an MX record at the Return-Path subdomain pointing to the ESP's bounce handler, a TXT record at selector._domainkey.signingdomain.brand.com containing the DKIM public key, and an SPF include for the ESP in your existing SPF record. Once published, the ESP switches its signing and Return-Path to your subdomain. Under relaxed alignment, bounces.brand.com aligns with From = brand.com, and em.brand.com aligns with From = brand.com. DMARC passes on both paths.

How do you verify alignment in the aggregate report?

Open the most recent aggregate report for your domain. The relevant columns are header.from (the visible From), the SPF auth_results domain (the Return-Path domain on the SPF path), the DKIM d= domain, the DKIM and SPF result (pass, fail, none), and the disposition (none, quarantine, reject).

A passing DMARC result shows either SPF alignment passing or DKIM alignment passing (or both). A failing DMARC result shows both paths failing to align. The most common pattern in a default ESP setup is SPF auth domain = em1234.sendgrid.net with header.from = brand.com, which is a clear SPF alignment failure.

A DMARC monitoring tool like DMARCFlow shows the same data grouped by sending source. If your domain has three ESPs and one of them is misconfigured, the dashboard shows the alignment failures concentrated on that one source's IP space. That is the fastest way to figure out which ESP is the offender without reading raw XML reports by hand. DMARCFlow also surfaces the per-day alignment trend, which makes it easy to confirm the fix actually worked after you publish the new DNS records.

Frequently asked questions

What is the difference between From and envelope sender in email?
The From header is the visible address the recipient sees in their inbox, set in the message itself. The envelope sender (also called Return-Path) is set during the SMTP conversation and is where bounces go. They are usually different addresses.

Why does DMARC fail when both SPF and DKIM pass?
DMARC requires alignment, not just authentication. SPF can pass while the Return-Path domain is on a shared ESP domain like em1234.sendgrid.net. DKIM can pass while the d= domain is on a shared ESP domain. In both cases DMARC fails because the alignment condition is not met.

Can the From header and the Return-Path be different domains?
Yes. This is the default with most ESPs, where the From header is the brand domain and the Return-Path is an ESP-controlled subdomain. Under DMARC relaxed alignment, the Return-Path subdomain needs to share the brand's organizational domain, so bounces.brand.com aligns with From = brand.com.

Does DMARC use strict or relaxed alignment by default?
Relaxed. Strict alignment must be explicitly requested with adkim=s and aspf=s. Relaxed alignment accepts any subdomain match.

Do I need both SPF alignment and DKIM alignment to pass DMARC?
No. DMARC passes if either alignment path succeeds. In practice, most teams aim for both so a single ESP configuration mistake does not break delivery.