Skip to content

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.

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:

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

Related articles

16 comments

10 comments

  1. aditi.s.bom
    What's your recommendation for sub-domains? We send from mail.example.com AND notifications.example.com. Same DKIM selector r separate?
    1. admin
      Good catch. The bounds (200/32) are hardcoded in the runtime. We've discussed making them configurable; not a near-term priority but it's tracked
  2. lequan.saigon
    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
    1. admin
      Thanks. Pass it along if it helps your team.
  3. priya.iyer.ops
    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.
    1. admin
      Confirming your experience matches what we see in support cases. We'll cite the cause-#5 'wait it out' guidance more prominently in the next revision.
  4. rafa.silva.br
    thanks for the explicit cautionary tales. The alignment-vs-pass distinction is exactly where I lost a week last year.
  5. linhvu.dev
    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
    1. admin
      thanks for the breakdown. Saving for our customer-success team's eference library.
  6. y.yamamoto
    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.
    1. admin
      Worth adding to the article. PR welcome if you want to author the addition
  7. tnovak.cz
    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?
    1. admin
      Yes, that pattern is supported. The undocumented bit is the order — config:cache MUST come after the migration, not before. Updating the docs to make that explicit.
  8. lucas.bernard.…
    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
  9. linhpm.devs
    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
  10. anna.k.pm
    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.

More in DNS & Domain Setup