Return-Path and Envelope Sender for AcelleMail

The Return-Path (also called "envelope sender" or "MAIL FROM") is one of the most-misunderstood email headers — partly because it's invisible in most clients (Gmail hides it; Outlook only shows it if you click "View source"), and partly because it's distinct from the visible From: header. Configuring it incorrectly breaks bounce handling AND DMARC alignment AND eventually deliverability.

This article unpacks what each piece is, how AcelleMail handles them, and the configurations that work versus the ones that silently break.

The three "from" addresses in an email#

Every message has three potentially-different from addresses:

In a typical AcelleMail send, all three (or at least MAIL FROM and From) are configured per the customer's sending domain.

How AcelleMail sets each#

When AcelleMail dispatches a campaign:

1. MAIL FROM is set from the customer's bounce-handler email — typically bounces@bounces.example.com (a per-customer or per-domain subdomain reserved for bounce ingestion).
2. From: header is set from the campaign's From Address field — typically marketing@example.com or whichever the customer configured.
3. Sender: is usually unset.

The receiver flow:

1. Receiver sees the SMTP MAIL FROM and runs SPF on it: "is the sending IP authorized for bounces.example.com?"
2. If yes → SPF PASS.
3. Receiver also checks DMARC alignment: does the MAIL FROM domain align with the From: header domain?
4. With relaxed alignment (aspf=r), bounces.example.com aligns with example.com (both share the org-domain). PASS.
5. With strict alignment (aspf=s), they don't align. FAIL.

DMARC alignment requirement#

DMARC requires alignment of either:

• SPF + From (relaxed: same org-domain; strict: exact match), OR
• DKIM + From (relaxed: same org-domain; strict: exact match)

In practice, most senders satisfy DMARC via DKIM alignment alone — DKIM signs with a d=example.com tag that matches the From: domain. SPF alignment is a bonus.

But: when DKIM fails for any reason (key rotation issue, forwarding strips signature), SPF alignment becomes the load-bearing column. Configure both correctly so neither is the single point of failure.

AcelleMail bounce-handler architecture#

Bounces arrive in two ways:

IMAP-based (legacy + non-API drivers)#

For sending servers that don't have a structured complaint webhook (generic SMTP relay, PowerMTA, etc.):

1. Set the MAIL FROM to a real mailbox — e.g. bounces@bounces.example.com.
2. AcelleMail's bounce-handler (cron + queue worker) polls this mailbox via IMAP every minute.
3. Each bounce DSN is parsed; the BounceLog row is created (per app/Model/BounceLog.php — bounce_type is hard/soft/unknown).
4. The original send is correlated via the Message-ID header in the DSN.

Configuration:

Admin → Bounce Handlers → New
   Name: bounces.example.com handler
   Server: mail.example.com
   Port: 993
   Username: bounces@bounces.example.com
   Password: <strong>
   Encryption: SSL/TLS
   Mailbox: INBOX

Webhook-based (SES, Mailgun, SendGrid, etc.)#

For modern API-based sending, the provider delivers bounce + complaint notifications directly to AcelleMail's webhook endpoint:

• AWS SES: SNS topics for bounce + complaint events; AcelleMail's SES driver auto-subscribes during sending-server setup.
• Mailgun: webhook URL configured in Mailgun's UI.
• SendGrid: webhook URL configured in SendGrid's UI.

The webhook bypasses IMAP entirely — events arrive in near-real-time, and AcelleMail processes them via the queue worker.

Common misconfigurations + fixes#

Misconfig 1 — MAIL FROM = From: header (no separate bounce mailbox)#

MAIL FROM: marketing@example.com
From: marketing@example.com

This works for SPF + DMARC alignment, but bounces arrive at marketing@example.com — usually a real human's inbox, not the bounce-handler's IMAP mailbox. Hard bounces aren't suppressed automatically; the mailbox fills with thousands of DSN messages.

Fix: dedicated bounce-handler mailbox (bounces@bounces.example.com) — this is what AcelleMail's setup wizard prompts for.

Misconfig 2 — MAIL FROM and From in different org-domains#

MAIL FROM: bounces@acellemail-shared-host.com    (different domain)
From: marketing@example.com

SPF authenticates the bounce-handler's domain (acellemail-shared-host.com). DMARC alignment fails (different org-domain). Receivers reject or quarantine.

Fix: bounce-handler subdomain under the same org-domain as From (bounces@bounces.example.com).

Misconfig 3 — bounce-handler not polling#

Mailbox configured correctly, but the AcelleMail bounce-handler cron isn't running (or the IMAP credentials expired). DSNs accumulate in the mailbox; suppression-list never updates; subsequent sends repeatedly hit the same bad addresses; reputation drops.

Fix: monitor IMAP-handler runs. The app/Model/FeedbackLoopHandler $logfile field points at feedback-loop-handler-YYYY-MM-DD.log; rotate + monitor for "no activity" alerts.

Misconfig 4 — webhook unsubscribed silently#

For SES specifically: SNS subscriptions can be unsubscribed by anyone with the unsubscribe link (delivered to the configured endpoint email). If someone clicks it, AcelleMail stops receiving bounce events.

Fix: monitor the SNS subscription state; alert if subscriptions go from "Confirmed" to "Pending" or "Unsubscribed."

Verification#

# Send a test message; check the recipient's "View Source" / "Show Original":
# Headers to verify:
#   Return-Path: bounces@bounces.example.com    ← matches your bounce-handler
#   From: marketing@example.com                ← what you configured
#   Authentication-Results: spf=pass dkim=pass dmarc=pass  ← all three pass

If any of these is wrong, the corrective is in your AcelleMail SendingDomain or per-campaign config.

Related reading#

• Bounce Types Deep Dive — what AcelleMail does with received DSNs
• Setting up Feedback Loops (FBL) — the FBL handler
• SPF Record Deep Dive — alignment requirements
• DMARC Enforcement Migration — alignment becomes critical
• Complete DNS Setup for Email Sending — first-time setup

FAQ#

Should I make Return-Path the same as From?#

No — separate them. From is for human display; Return-Path is for machine processing of bounces. Mixing them clutters the From inbox with DSNs.

What if I want bounces to go to my main inbox for monitoring?#

Set up forwarding from the bounce-handler mailbox to your main inbox, but keep the bounce-handler ingestion as the primary. Forwarding is a "carbon copy" not a "redirect."

Does the Return-Path need its own SPF?#

Yes — SPF authenticates against the Return-Path domain. Configure bounces.example.com with its own SPF (often the same include:amazonses.com -all as the parent).

Can I use a wildcard MAIL FROM (e.g. for many customers)?#

You can configure each customer's bounce-handler with their own subdomain. Wildcard MAIL FROM patterns aren't supported by SMTP; you need per-recipient or per-customer routing.