> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lettr.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Custom Return-Path and MAIL FROM
> What the Return-Path and MAIL FROM addresses do, and how a custom MAIL FROM domain fixes SPF alignment and removes via labels in Lettr.
Every email has two "from" addresses: the one the recipient sees in their inbox (the **From header**) and a hidden technical address used for bounce handling (the **Return-Path**, also called the envelope sender or MAIL FROM). These two addresses are often different — and understanding why is key to diagnosing authentication issues, eliminating "via" labels in recipient inboxes, and achieving full DMARC alignment.
***
## Two "From" Addresses
When you send an email through Lettr, the message carries two distinct sender addresses that serve different purposes.
| Address | Where It Appears | Purpose | Example |
| --------------------------- | ------------------------------------------------------------------ | ------------------------------------------------- | --------------------------------- |
| **From header** | Visible to the recipient in their inbox | Identifies the sender to the reader | `hello@yourapp.com` |
| **Return-Path** (MAIL FROM) | Hidden in message headers; set during the SMTP `MAIL FROM` command | Receives bounce notifications when delivery fails | `bounces+abc123@bounce.lettr.com` |
The `From` header is what your recipients see and recognize. The Return-Path is a technical address that mail servers use behind the scenes. When a message bounces, the bounce notification is sent to the Return-Path address — not to the From address.
### Why They Differ
By default, Lettr sets the Return-Path to an address on Lettr's bounce-processing domain (e.g., `bounces+abc123@bounce.lettr.com`). This allows Lettr to receive and process bounce notifications automatically — parsing bounce codes, classifying bounce types, updating suppression lists, and surfacing bounce data in your dashboard and webhooks.
If Lettr used your From address as the Return-Path, bounces would go directly to your mailbox instead, and Lettr would have no way to track or process them.
***
## The Problem: SPF Alignment
Having a different Return-Path domain creates a specific authentication challenge: **SPF alignment failure**.
[SPF](/knowledge-base/fundamentals/spf-dkim-dmarc) is verified against the **Return-Path domain**, not the From header domain. When the Return-Path is `bounces@bounce.lettr.com` but the From header shows `hello@yourapp.com`, SPF passes for `bounce.lettr.com` — but it does not align with `yourapp.com`.
```
From: hello@yourapp.com ← what the recipient sees
Return-Path: bounces@bounce.lettr.com ← what SPF checks
```
DMARC requires that at least one of SPF or DKIM passes **and** aligns with the From domain. In the default Lettr configuration, DKIM handles alignment (Lettr signs with your domain), so DMARC still passes. But you are relying entirely on DKIM for DMARC alignment, with no SPF alignment as a fallback.
***
## What a Custom Return-Path Fixes
A custom Return-Path (also called a custom MAIL FROM domain or custom bounce domain) replaces Lettr's default bounce domain with a subdomain of your own domain. This achieves **SPF alignment** alongside the existing DKIM alignment.
### Before (Default)
```
From: hello@yourapp.com
Return-Path: bounces+abc123@bounce.lettr.com
SPF aligns: No (bounce.lettr.com ≠ yourapp.com)
DKIM aligns: Yes (signed with d=yourapp.com)
DMARC: Pass (via DKIM alignment only)
```
### After (Custom Return-Path)
```
From: hello@yourapp.com
Return-Path: bounces+abc123@mail.yourapp.com
SPF aligns: Yes (mail.yourapp.com aligns with yourapp.com)
DKIM aligns: Yes (signed with d=yourapp.com)
DMARC: Pass (via both SPF and DKIM alignment)
```
### Benefits
| Benefit | Explanation |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Full DMARC alignment** | Both SPF and DKIM align with your From domain, providing redundancy. If one fails (e.g., DKIM breaks during forwarding), the other can still satisfy DMARC. |
| **Removes "via" labels** | Some email clients (notably Gmail) display a "via lettr.com" label when the Return-Path domain differs from the From domain. A custom Return-Path eliminates this. |
| **Improved deliverability** | Some mailbox providers give a slight deliverability boost to messages with full alignment across both SPF and DKIM. |
| **Professional appearance** | The bounce domain matches your brand rather than showing a third-party infrastructure domain in the headers. |
***
## Setting Up a Custom Return-Path in Lettr
Lettr uses the sending domain itself as the bounce domain — there is no separate subdomain to configure. Once a sending domain's CNAME record is verified, you can enable it as the bounce domain with a single toggle.
Open **Domains → Sending Domains** and confirm that your sending domain's `cname_status` is **valid**. The Bounce Domain toggle is disabled until the CNAME is verified.
If the CNAME is not yet valid, follow the [Sending Domains setup guide](/learn/domains/sending-domains) to add and verify the record before continuing.
The CNAME record is the same one used for standard domain verification (pointing to `sparkpostmail.com`). No additional DNS changes are required to enable the bounce domain.
From **Domains → Sending Domains**, click the domain you want to configure. This opens the domain's detail and settings page.
Scroll to the **Bounce Domain** card. It contains a single toggle labeled **Use this sending domain as bounce domain** along with a short description.
Switch **Use this sending domain as bounce domain** on. When enabled, bounce messages will use this domain's Return-Path instead of the SparkPost default, giving you SPF alignment alongside DKIM.
You will see a confirmation: *"This domain is now used as the bounce domain."* Disabling the toggle reverts the Return-Path to Lettr's default bounce domain.
Send a test email and inspect the headers. You should see:
```
Return-Path:
```
And in the `Authentication-Results` header:
```
spf=pass smtp.mailfrom=yourapp.com
dkim=pass header.d=yourapp.com
dmarc=pass header.from=yourapp.com
```
Both SPF and DKIM should show `pass` with domains that align with your From address.
***
## How SPF Alignment Works
SPF alignment is the check that DMARC performs to ensure the domain authenticated by SPF matches the domain in the From header.
### Relaxed vs Strict Alignment
DMARC supports two alignment modes, configured in your DMARC record with the `aspf` tag:
| Mode | DMARC Tag | What It Checks | Example |
| --------------------- | --------- | ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **Relaxed** (default) | `aspf=r` | The organizational domain of the Return-Path must match the organizational domain of the From header | `mail.yourapp.com` aligns with `yourapp.com` |
| **Strict** | `aspf=s` | The exact domain of the Return-Path must match the exact From domain | `mail.yourapp.com` does **not** align with `yourapp.com` — only `yourapp.com` matches `yourapp.com` |
Most domains use **relaxed alignment** (the default). With relaxed alignment, a Return-Path subdomain like `mail.yourapp.com` aligns with a From address on `yourapp.com`. This is the standard configuration and works correctly with Lettr's custom Return-Path setup.
***
## Verifying Your Return-Path Configuration
You can check the Return-Path of any email by viewing its full headers.
### Check via Email Headers
Send a test email to yourself and view the raw headers. Look for the `Return-Path` header:
```
Return-Path:
```
### Check via Command Line
Verify that the DNS records for your custom Return-Path are published:
```bash theme={null}
# Check the CNAME record
dig CNAME mail.yourapp.com
# Check SPF resolution for the subdomain
dig TXT mail.yourapp.com
```
### Check via Lettr Dashboard
The domain settings page in your Lettr dashboard shows the verification status of your custom Return-Path configuration, including whether DNS records are correctly published and whether SPF alignment is passing.
***
## Common Mistakes
The From header (`hello@yourapp.com`) and the Return-Path (`bounces@mail.yourapp.com`) serve completely different purposes. The From header is what recipients see. The Return-Path is where bounces go and what SPF checks. Changing your From address does not affect SPF alignment — only the Return-Path domain matters for SPF.
The **Bounce Domain** toggle is disabled until the domain's CNAME record shows a `valid` status. If you see the amber "Verify the CNAME record before enabling." warning, finish verifying the sending domain first — see [Sending Domains](/learn/domains/sending-domains).
If you migrate between email service providers, your SPF include statements need to be updated to authorize the new provider's sending IPs. An outdated SPF record will cause SPF failures even with a custom Return-Path configured. Verify your SPF record includes the correct `include:` directive for Lettr.
If your DMARC record specifies `aspf=s` (strict alignment) and you send from a subdomain such as `mail.yourapp.com`, the Return-Path (which matches the sending domain) will not align with a From address on the root `yourapp.com`. Either use relaxed alignment (`aspf=r`, the default) or publish a DMARC record at the subdomain level.
***
## Related Topics
How SPF, DKIM, and DMARC work together to authenticate your email.
Understand Return-Path, From, and other headers in depth.
Set up and verify your sending domain in Lettr.
Diagnose and fix SPF, DKIM, and DMARC failures.