DNS & Domain Setup

Return-Path and Envelope-Sender — Quick Setup in AcelleMail

The 5-minute setup: pick a bounce subdomain, publish the MX record, set the sending-server config, verify. This is the practical companion to [Return-path and envelope-sender explained](/kb/articles/return-path-and-envelope-sender-explained) — when you just want to do it.

July 4, 2026 5 min read Beginner

What you're doing

You're setting up a custom envelope-sender (also called "return-path" or "MAIL FROM domain") aligned to your sending domain. Instead of AcelleMail using the vendor's default like [email protected], your envelope-sender becomes [email protected] — passing strict DMARC alignment.

This article is the 5-minute setup. For the concept + why it matters, see Return-path and envelope-sender explained.

Step 1: Pick a subdomain

Convention: bounce.yourdomain.com or mail.yourdomain.com. Reserved for envelope-sender / return-path.

bounce.brand.com   (recommended; explicit)
mail.brand.com     (also common)
return.brand.com   (sometimes used)

Step 2: Publish the MX record

At your DNS host:

Type:     MX
Name:     bounce.yourdomain.com
Value:    feedback.acellemail.com   (or your install's bounce processor)
Priority: 10
TTL:      3600

The exact MX target is shown in your AcelleMail sending-domain detail page. Use that value.

Wait for DNS propagation (5-60 minutes typical).

Step 3: Configure the sending server in AcelleMail

In AcelleMail's sidebar, Sending → Sending servers → click your active server. The detail page surfaces Connection settings + Configuration + Identity:

Sending server detail — Configuration section

In the server detail's Configuration section, find the MAIL FROM (Return-Path) field. Enter your subdomain:

MAIL FROM: bounce.yourdomain.com

Save. From the next send onwards, AcelleMail uses this as the envelope-sender.

Step 4: Verify

Send a test campaign to yourself. Open the received message → Gmail's "Show original" (or equivalent in your email client). Look for:

Return-Path: <[email protected]>

If you see your custom subdomain — done. If you see the vendor default (e.g. [email protected]) — Step 3 didn't save; re-check sending server config.

Verify the DMARC alignment in AcelleMail's auth chips:

The auth chips on the sending-server detail

Open Settings → Sending servers → click your active server. The toolbar shows the live SPF / DKIM / DMARC chip status:

Sending server detail with auth chips

Green chips on all three = receiving servers can confirm you're authorized to send from this domain.
Any chip red = receiving servers immediately downgrade reputation. Click Verify domain in the toolbar to walk through the DNS-fix wizard.

DMARC chip should remain Green. If it flips Red after this change, your DMARC record needs subdomain alignment too — see DMARC enforcement migration.

Common UI signals + fixes

Symptom	Likely cause	UI fix
Bounces stop arriving in AcelleMail	MX record not propagated	`dig MX bounce.yourdomain.com` — verify target matches AcelleMail's expected value
MAIL FROM field grayed out	Vendor doesn't support custom MAIL FROM (some shared-pool setups)	Switch to a vendor that supports custom MAIL FROM (SES, dedicated Mailgun, etc.)
Custom MAIL FROM saved but messages still use vendor default	Old campaign sends using cached config	Send a fresh test; only new campaigns use the new MAIL FROM
DMARC chip flips Red	DMARC alignment lost	Verify SPF includes the new MAIL FROM domain

Aligned vs unaligned

Aligned:

From:          [email protected]
Envelope-Sender: [email protected]
SPF check on:  bounce.brand.com (subdomain of brand.com)
DMARC: pass via aligned SPF

Unaligned (default vendor):

From:          [email protected]
Envelope-Sender: [email protected]
SPF check on:  amazonses.com (different domain)
DMARC: pass via DKIM only (or fail if strict alignment)

Both work for most receivers. Aligned is preferred for B2B + strict-alignment-enforcing receivers.

Advanced: multi-vendor envelope-sender management + per-tenant subdomains + automated verification

Multi-vendor envelope-sender:

If you use multiple sending vendors, each can have its own envelope-sender subdomain:

Server A (SES):       bounce-ses.brand.com  → feedback-ses.acellemail.com
Server B (Mailgun):   bounce-mg.brand.com   → feedback-mg.acellemail.com
Server C (Postmark):  bounce-pm.brand.com   → feedback-pm.acellemail.com

Per-vendor MX. Per-vendor sending-server config. All envelope-senders align to brand.com via subdomain leeway.

Per-tenant in SaaS context:

For SaaS sending-on-behalf-of-customers:

Customer A: bounce.customerA.com → managed by your platform
Customer B: bounce.customerB.com → managed by your platform

Each customer adds the MX record at their DNS host. Your platform's AcelleMail config sets per-customer envelope-sender.

Automated verification:

#!/bin/bash
# Daily check — verify all sending-server MAIL FROM domains have correct MX
servers=$(curl -sH "Authorization: Bearer $TOKEN" \
  "https://acellemail.com/api/v1/admin/sending-servers" | jq -r '.data[].uid')

for server in $servers; do
  mail_from=$(curl -sH "Authorization: Bearer $TOKEN" \
    "https://acellemail.com/api/v1/admin/sending-servers/$server" \
    | jq -r '.mail_from_domain')

  if [ -n "$mail_from" ]; then
    mx=$(dig MX $mail_from +short | head -1)
    if [ -z "$mx" ]; then
      echo "🚨 Server $server: MAIL FROM=$mail_from has no MX record"
    fi
  fi
done

Custom envelope-sender for transactional vs marketing:

Transactional server: bounce-txn.brand.com  (separate reputation pool)
Marketing server:     bounce-mkt.brand.com  (separate reputation pool)

Bounces from each route separately. Marketing reputation problems don't pollute transactional reputation.

Vendor-specific notes:

Amazon SES: Set "MAIL FROM domain" in SES Verified Identities. Add MX record bounce.brand.com → feedback-smtp.us-east-1.amazonses.com (region-dependent)
SendGrid: Whitelabel feature (paid tier). Configure via SendGrid Senders → Domain Authentication
Mailgun: Built-in; configure via Domain → DNS Records
Postmark: Built-in; configure via Servers → Server Settings → Custom MAIL FROM

Each vendor has slightly different MX target. Refer to vendor docs OR check AcelleMail's sending-domain detail page for the right value.

Tagged

Acellemail

11 comments

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

Create an account Sign in

Minh 1 month ago

Quick question: do receivers actually enforce the SPF -all hard fail, or do most just downrate? I've heard mixed things and I'm hesitant to switch from ~all.

0
Linh 2 months ago

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

0
James 2 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 ulk-verify those? :)

0
1. Admin 2 months ago
  
  There's no bulk-verify button today. Verification is per sending domain, you add the CNAME/TXT for the bounce subdomain and hit verify on that domain's row. For white-label you're stuck sending each client their own record set, since the bounce host is derived per domain and can't be shared. Two things that make it less painful in practice. First, if you control the parent zone, have clients CNAME a single subdomain (like bounce.theirdomain.com) to your host, then you only manage records on your side once. Second, the verify check is just a DNS lookup, so you can loop it from a script against the sending domains list rather than clicking through the UI. A proper bulk verify on the domains list is a fair ask and it's not there. I'll put it on the list.
  
  0
Isabella 3 months ago

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

0
Chen 3 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 didnt know about who's sending as you.

0
1. Admin 3 months ago
  
  Agreed, the aggregate XML shows the SPF domain the receiver actually checked, so a misaligned Return-Path shows up as spf pass but dmarc fail. I'll add RUA setup as the verification step at the end.
  
  0
Aditi 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
Joel 4 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 4 months ago
  
  The part that catches most people is that the limit counts DNS lookups, not include statements, so one include that itself nests three more costs you four. And a permerror doesn't fail soft, most receivers treat it as no SPF at all, which is why it shows up as sudden bulk-foldering rather than a clean bounce. One caveat on flattening since the article is a bit light on it: hardcoded IP blocks go stale. ESPs rotate sending ranges without telling you, so if you flatten, put a recheck on a schedule and re-resolve the source includes rather than treating the flat record as permanent. If you're mostly stuck at 10 because of tools you no longer use, pruning first is safer than flattening.
  
  0
Nadia 4 months ago

whats your recommendation for sub-domains? we send from mail.example.com and notifications.example.com. same dkim selector or separate?

0
1. Admin 4 months ago
  
  Separate keys per subdomain, and I'd use separate selectors too. The keys have to be separate regardless, since the DKIM record lives at `selector._domainkey.mail.example.com` and `selector._domainkey.notifications.example.com`. Those are different DNS zones as far as the resolver is concerned, so even if you name both selectors `s1` you're publishing two distinct records and signing with two distinct private keys. Naming them the same buys you nothing and makes debugging worse, because when a verify fails you can't tell from the selector alone which sending domain it came from. Name them something you can read at a glance, `mail1` and `notif1` or whatever fits your rotation scheme. Practical reason to keep them apart: reputation. mail.example.com and notifications.example.com are almost certainly different traffic. Transactional notifications get opened, marketing mail gets ignored or complained about. Split selectors plus split subdomains means a bad week on one doesn't drag the other down. On the Return-Path side, which is what this article is actually about, set the envelope sender per subdomain to match. If you're sending from `mail.example.com`, the bounce domain should be under `mail.example.com` too, not a shared `bounce.example.com`. Otherwise you're back to relaxed alignment for SPF and you lose the isolation you just built. Each sending domain in the app gets its own DKIM key pair, so this falls out naturally if you add both subdomains as separate sending domains rather than trying to cover both with one.
  
  0
Priya 5 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

3
1. Admin 5 months ago
  
  Flattening works, but it's worth knowing the tradeoff before anyone copies it: you're freezing SES and Google's IP ranges into your own TXT record, and those change without telling you. If you flatten, you need something re-checking the record on a schedule, otherwise SPF quietly starts failing months later when a range rotates. The other route on that same problem is a dedicated subdomain for the envelope sender, say bounce.yourdomain.com, with only the SES include on it. Return-Path is what SPF actually checks, so the Google Workspace includes on your root domain never enter the count. That's the setup the article's DNS step is pointing at. I'll add a note about the 10-lookup limit and both fixes. Won't link a specific flattening tool since I can't vouch for what happens to those records long term, but the caveat belongs in there.
  
  0
Sofia 5 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. tbh

1
Yuki 5 months ago

Our DKIM rotation broke for 2 days because we updated 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
1. Admin 5 months ago
  
  That's the right order. Publish the new selector, let it propagate, flip the signing selector, and only remove the old one once nothing in flight is still signed with it. The wait is really about your old record's TTL plus whatever resolvers ignore it, so 48h is a sane default but if your old selector had a 24h TTL you can usually cut it shorter. The part people miss is that mail already queued at a receiver can get verified hours after you sent it, which is why deleting the old selector last matters even after you've switched. Two selectors live at once is fine, verifiers only look up the one named in the d=/s= of the signature. I'll add a rotation ordering note to this article since envelope-sender and DKIM setup tend to get touched in the same change window.
  
  0