DNS & Domain Setup

Return-Path vs Envelope-Sender — What Each Does in AcelleMail

The "From" address recipients see isn't the address that handles bounces. That's the envelope-sender (also called the return-path or MAIL FROM). This guide separates the three sender concepts and shows where AcelleMail configures each.

June 1, 2026 6 min read Intermediate

The 3 sender concepts (different things)

Email has 3 "sender" addresses, often confused:

Concept	Where it lives	Used by
From: header	Email body header	Displayed to recipient — what they see in the inbox
Envelope-sender (MAIL FROM, Return-Path)	SMTP envelope (before the message body)	Receiving servers — where bounces go back to
Reply-To: header	Email body header	Recipients clicking "Reply" — where their reply goes

These can all be different addresses. Sometimes useful, sometimes confusing. Let's separate them.

From: header (what recipients see)

From: Brand Marketing <[email protected]> in the email body. Recipients see "Brand Marketing" in the sender column. Inbox previews display this.

In AcelleMail: campaign settings → From email + From name. Per-campaign override of the sending server's default.

Envelope-sender (where bounces go)

Set during SMTP transmission via MAIL FROM: command. NOT visible in the email body. Receivers use it for:

Sending bounce messages back to (so AcelleMail can process them)
SPF check (the sender domain's SPF record must authorize the sending IP)
Reputation tracking (one of the inputs to per-domain reputation)

In AcelleMail: handled automatically by the sending-server config. Typically [email protected] or a vendor-rotated address like [email protected].

Verify the envelope-sender by opening "Show original" in Gmail:

Return-Path: <[email protected]>
X-Original-Sender: [email protected]

This is the envelope-sender, NOT the From: header.

Reply-To: header (where replies go)

Reply-To: [email protected]. When a recipient clicks "Reply," their reply goes to this address (not the From: address).

Useful for:

Sending from [email protected] but accepting replies at [email protected]
Routing replies to a different team/inbox per campaign

In AcelleMail: campaign settings → Reply-to email.

Open the sending-domain detail

In AcelleMail's sidebar, Sending → Sending domains. The list shows every domain you've registered with status chips (Verified / Pending / Failed) and per-auth indicators:

Sending domains list

Click into your domain row. The detail page surfaces exactly which DNS records to publish (TXT for SPF, CNAMEs for DKIM, TXT for DMARC) with copy-paste-ready values + current verification state per check:

Sending-domain detail — DNS records + auth status

The sending-domain detail page shows the active envelope-sender pattern + verification status — confirming that the bounces will route correctly back to AcelleMail's processor.

Why all 3 matter for deliverability

Receiving servers check alignment between these addresses + your DNS records:

Check	Aligned when
SPF	Envelope-sender's domain has the sending IP in its SPF record
DKIM	The DKIM signature's `d=` parameter matches the From: domain
DMARC alignment	SPF and/or DKIM domain matches the From: domain

Strict DMARC alignment = the bounce/envelope domain MUST match the From: domain (no subdomain leeway). Relaxed = subdomain leeway allowed.

If you send From: <[email protected]> but the envelope-sender is [email protected], DMARC may fail (envelope-sender domain amazonses.com doesn't align with From: domain brand.com).

The fix: use a custom Return-Path domain that aligns. AcelleMail's sending-server config → MAIL FROM (Return-Path) field — set to bounce.brand.com so the envelope-sender becomes [email protected], aligned with brand.com.

Common UI signals + fixes

Symptom	Likely cause	UI fix
Bounces never come back to AcelleMail	Envelope-sender misconfigured (pointing elsewhere)	Sending server detail → MAIL FROM field
DMARC fails despite SPF/DKIM green	Envelope-sender domain doesn't align with From:	Set up custom return-path subdomain
Recipients reply but I never see it	Reply-To: pointing to dead address	Campaign settings → Reply-to email
From: shows weird formatting	Display name not set or quotes broken	Campaign settings → From name
Spam folder placement on B2B receivers	Strict DMARC alignment expected by some B2B filters	Set up aligned return-path domain

Common configurations

Setup	Best for
From: = Envelope = Reply-To, all on `brand.com`	Simplest; strict DMARC alignment works automatically
From: `brand.com`, Envelope: `bounce.brand.com`, Reply-To: `[email protected]`	Most common for marketing — aligned envelope subdomain handles bounces; replies go to support
From: `[email protected]`, Reply-To: empty (suppress replies)	Transactional emails; "do not reply" pattern
From: `brand.com`, Envelope: `amazonses.com`	Default SES setup — DMARC alignment may need relaxed mode

Advanced: per-vendor envelope-sender mechanics + DMARC alignment math + multi-tenant return-paths

Per-vendor envelope-sender:

Vendor	Default envelope-sender	Customizable?
Amazon SES (API)	`[email protected]`	Yes — set "MAIL FROM domain" in SES verified-identity config
SendGrid SMTP	`[email protected]`	Yes — Whitelabel feature (paid)
Mailgun	`[email protected]`	Yes — included in standard config
Postmark	`[email protected]`	Yes — included in standard config
Self-hosted Postfix	Whatever you configure in postfix's `myorigin`	Fully customizable

For DMARC strict alignment, the envelope-sender domain must match (or be a subdomain of) the From: domain. Each vendor has a different way to set this:

SES: Verify identities → custom MAIL FROM domain → publish MX record at mail.brand.com
SendGrid: Whitelabel feature → reverse DNS + CNAME setup
Mailgun: Auto-handled per their domain setup

DMARC alignment math:

DMARC pass requires AT LEAST ONE of:
  - SPF pass + From: domain matches MAIL FROM domain (or aligned subdomain)
  - DKIM pass + From: domain matches DKIM d= (or aligned subdomain)

Strict alignment = exact domain match (e.g. brand.com = brand.com)
Relaxed alignment = subdomain leeway (e.g. mail.brand.com aligns with brand.com)

Default DMARC is relaxed alignment. Some receivers (financial-services-side filters) enforce strict.

Multi-tenant return-paths (for SaaS operators):

Each customer needs their own envelope-sender subdomain:

Customer A: From: [email protected]   Envelope: [email protected]
Customer B: From: [email protected]   Envelope: [email protected]

Each customer adds the bounce CNAME at their DNS host pointing to your AcelleMail processor. AcelleMail's per-customer sending server config holds the right envelope-sender setting.

Vendor-rotated envelope-sender (default SES pattern):

[email protected]
[email protected]
[email protected]  ...

The +abcXXX is a unique ID per outgoing message. SES uses it to route bounces to your account.

SRS (Sender Rewriting Scheme):

For forwarding scenarios — when you receive a message and forward it elsewhere. SRS rewrites the envelope-sender to maintain SPF authentication through the forward.

Original sender:  [email protected] → SPF check passes for external.com
After SRS rewrite: [email protected] → SPF check passes for brand.com

Most modern SMTP relays handle SRS automatically. Verify on your sending server if you do forwarding.

Reply-To: pitfalls:

From: [email protected]
Reply-To: [email protected]  ← BAD! Recipients reply, mail bounces to noreply (likely no inbox)

Always set Reply-To: to a real-inbox address that someone reads.

From: [email protected]
Reply-To: <empty>           ← OK — recipients can't reply via standard reply; explicit communication channel mentioned in body

Tagged

Acellemail

10 comments

Join the conversation. Comments are open to AcelleMail community members.

Create an account Sign in

Aditi 1 month ago

What's your recommendation for sub-domains? We send from mail.example.com AND notifications.example.com. Same DKIM selector r separate?

0
1. Admin 1 month ago
  
  Separate keys. The selector name is scoped per domain, so technically you could reuse the same label on both mail.example.com and notifications.example.com and nothing breaks, since the lookup is selector._domainkey.mail.example.com and selector._domainkey.notifications.example.com, two different records. But reusing the same private key across both means rotating one forces you to rotate the other, and if notification traffic ever gets you into trouble you can't isolate it. Give each subdomain its own identity with its own key, and set the Return-Path to match the subdomain that's actually sending so the envelope sender aligns with the DKIM d= for DMARC.
  
  0
Quân 2 months ago

the SPF flattening explanation finally made it click for me. I'd been hitting the 10-lookup limit and didn't understand why nesting includes counted

0
1. Admin 2 months ago
  
  The lookup counter is what trips everyone up. Each `include:` costs one, and the includes inside it cost their own, so one nested provider record can eat 4 or 5 before you've added anything of your own. `a` and `mx` count too, `ip4`/`ip6` don't, which is the whole reason flattening works. Caveat worth knowing since you're heading that way: flattened records go stale. Whoever's IPs you inlined can rotate them without telling you, and your SPF passes right up until it doesn't. If you flatten, re-check the source records on a schedule rather than treating it as done. The other option is just pointing the Return-Path at a subdomain you control so the sending server's SPF is the only one being evaluated, which the article covers further down.
  
  0
Priya 3 months ago

Worth noting: our DNS provider (Cloudflare) caches negative responses for 1 hour. We added a TXT record, dig showed it, but mail-tester said missing for another 40 minutes. Almost lost our minds. TTL was set to 300 but the parent zone NS cache held.

2
1. Admin 3 months ago
  
  That's negative caching, and the TTL that governs it isn't the one you set on the record. It's the minimum field in the parent zone's SOA, which is why your 300 didn't help. Once a resolver has cached the NXDOMAIN for the bounce-domain TXT, dig against 1.1.1.1 will look fine while mail-tester's resolver is still sitting on the miss. The practical fix is to create the record before you point the Return-Path at it in the sending domain settings, not after. Verification queries the name, and a failed check is what plants the negative cache in the first place. I'll add a note on this to the article. It's a real trap and the current text says nothing about resolver-side caching.
  
  0
Rafael 3 months ago

thanks for the explicit cautionary tales. The alignment-vs-pass distinction is exactly where I lost a week last year.

0
Thuỳ 4 months ago

Hit the 10-lookup SPF limit when we tried to layer SES on top of an existing Google Workspace setup. Flattened with a tool (spfwizard.com) and it's been fine since. That tool's worth a mention. anyway

0
1. Admin 4 months ago
  
  Flattened records go stale silently when SES or Google rotate IPs, so re-run it on a schedule. The 10-lookup limit only applies to the Return-Path domain, so a custom bounce domain avoids it entirely.
  
  0
Tomas 4 months ago

how do you handle dns for clients in white-label setups? the customer would need to add records to their domain — is there a clean way to bulk-verify those?

0
1. Admin 4 months ago
  
  There's no bulk-verify button today. Each sending domain gets checked on its own screen, where the customer adds the SPF/DKIM and the Return-Path CNAME for the bounce subdomain, then hits verify and we do the lookup live. For white-label that means one pass per customer domain, which is fine at ten and painful at two hundred. What people usually do is stand up their own poller against the same records rather than clicking through the UI. The check is just a DNS resolve, so you can dig the CNAME on the bounce subdomain yourself and only send the customer back to the panel once it resolves. Worth knowing the Return-Path CNAME is the one that most often lags, since it lives on a subdomain the customer's DNS team may not own. A bulk re-verify across a customer's domains is on the list, it isn't built. If you tell me roughly how many domains you're managing I'll use that when I scope it.
  
  0
Yuki 4 months ago

Easy win: set up dmarcian.com (free tier) to receive your DMARC RUA reports. The first 2 weeks of reports tell you everything you didn't know about who's sending as you.

0
1. Admin 4 months ago
  
  RUA reports are useful here for a reason that's specific to this article: the SPF result in each report row is evaluated against the envelope sender domain, not the From: header. So when you see SPF pass on a domain you don't recognise, that's your Return-Path, and it's usually the ESP's bounce domain rather than yours. That's the fastest way to spot that you never set up a custom Return-Path. Two caveats worth knowing before people go set it up. Aggregate reports are XML summaries with no message content, so they won't tell you which campaign caused a fail, only counts per source IP. And most reporters send daily, so the first useful picture takes about 72 hours, not minutes. I'll add a short section on reading the SPF column against envelope sender. It fits the article better than anything currently in it.
  
  0
Lucas 4 months ago

if you use Vercel or Netlify for the apex, watch out — they sometimes override TXT records via their auto-DNS feature. Bit us once with a stripped SPF record

0
Linh 5 months ago

dNS setup is one of those things where you don't know what you don't know. This article should be required eading for anyone running their own mail

0
Anna 5 months ago

our dkim rotation broke for 2 days because we upated the active selector first, then waited to delete the old. should be the other way — publish new, wait 48h for cache, switch sending, then remove old.

0