Skip to main content

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.

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.
AddressWhere It AppearsPurposeExample
From headerVisible to the recipient in their inboxIdentifies the sender to the readerhello@yourapp.com
Return-Path (MAIL FROM)Hidden in message headers; set during the SMTP MAIL FROM commandReceives bounce notifications when delivery failsbounces+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 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

BenefitExplanation
Full DMARC alignmentBoth 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” labelsSome 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 deliverabilitySome mailbox providers give a slight deliverability boost to messages with full alignment across both SPF and DKIM.
Professional appearanceThe 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.
1

Verify the CNAME Record

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 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.
2

Open the Domain Detail Page

From Domains → Sending Domains, click the domain you want to configure. This opens the domain’s detail and settings page.
3

Locate the Bounce Domain Card

Scroll to the Bounce Domain card. It contains a single toggle labeled Use this sending domain as bounce domain along with a short description.
4

Enable the Toggle

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.
5

Confirm Alignment

Send a test email and inspect the headers. You should see:
Return-Path: <bounces+abc123@yourapp.com>
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:
ModeDMARC TagWhat It ChecksExample
Relaxed (default)aspf=rThe organizational domain of the Return-Path must match the organizational domain of the From headermail.yourapp.com aligns with yourapp.com
Strictaspf=sThe exact domain of the Return-Path must match the exact From domainmail.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: <bounces+abc123@mail.yourapp.com>

​
Check via Command Line

Verify that the DNS records for your custom Return-Path are published: 
# 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.
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.

SPF, DKIM & DMARC

How SPF, DKIM, and DMARC work together to authenticate your email.

Email Headers Explained

Understand Return-Path, From, and other headers in depth.

Sending Domains

Set up and verify your sending domain in Lettr.

Authentication Troubleshooting

Diagnose and fix SPF, DKIM, and DMARC failures.