A branded support address is only convincing when it works in both directions.
If customers write to [email protected], then ticket notifications should come from [email protected] too. Otherwise the first reply arrives from [email protected], which is technically fine and emotionally indistinguishable from a small support mystery.
MuninX now lets an admin use one custom address for ticket notifications. The useful part is not the text field. It is keeping two separate jobs—receiving customer mail and sending ticket updates—aligned.
The two jobs are independent
The custom address does not receive mail merely because it can send it. Nor does it become a sender merely because its inbox forwards messages somewhere useful. These are separate configurations, owned in separate places.
Receiving is your mailbox rule. Configure server-side automatic forwarding from [email protected] to the current MuninX address for your tenant, such as [email protected]. That creates tickets from mail sent to the address customers already know.
Sending is your Tenant setting. Add that same address under Custom Sending Address, publish the DNS records MuninX provides, and check verification. Once it is active, MuninX can use it for ticket notifications.
This split is intentional. MuninX can confirm whether it is allowed to send from the address. It cannot inspect the forwarding rule in your mailbox, and it should not pretend otherwise. Your email provider owns that rule; MuninX owns the ticket queue.
The four states customers can accidentally meet
The bottom row is the one to aim for. The other three are useful while you are setting things up, but they are not an especially elegant long-term customer experience.
The sender follows the ticket, not the entry door
Once the custom sender is active, it is used for every ticket notification in that tenant. A ticket can arrive through [email protected], through the default MuninX address, or through the customer portal. The outgoing notification still uses the active custom address.
That rule matters because support work is a queue, not a collection of mailbox loyalties. A customer should not need to remember which entrance they used in order to recognize a reply from your team.
The default address remains available too. It is still the receiving destination for forwarding and it remains the fallback sender if the custom address is absent, disabled, or needs verification again. The custom address adds a customer-facing sender; it does not retire the default route.
Replies take the narrow road on purpose
Ticket notifications show the custom address as the sender, but their Reply-To address is specific to the ticket. When a customer clicks Reply, the response returns to the existing conversation instead of travelling through the general forwarding rule.
That avoids two predictable problems:
- a reply being treated as a brand-new ticket after it passes through a general mailbox rule;
- a forwarding loop that turns one customer response into a small, self-sustaining weather system.
The visible From address can stay familiar while the actual reply route stays precise. That is the boring kind of email detail worth being boring about.
Set it up like an operator, not an archaeologist
Use this sequence:
- Choose the customer-facing address, such as
[email protected]. - Add server-side automatic forwarding to the current address shown in Tenant settings.
- Add the same custom address in MuninX and publish its DNS records.
- Check verification until the sending state is active.
- Send a real email to
[email protected]; confirm that it creates a ticket and that the resulting notification comes from the same address.
Do not use a manual forward as the test. Manual forwarding often changes the sender context and adds a human step to the one workflow people only remember when it breaks.
There are two operational caveats worth putting somewhere more durable than a launch-day memory. MuninX does not monitor your mailbox forwarding rule, so a later provider or admin change can stop inbound mail without changing the sending state. And the forwarding destination depends on the tenant slug: change the slug, update the forwarding rule immediately, then repeat the real-email test. Historical slug addresses are not retained.
Invitations, account verification, and password-reset emails are platform messages. They continue to come from a MuninX address rather than your custom support address.
For the exact setup, provider forwarding links, verification checks, disabling or re-enabling the sender, and troubleshooting, use the Custom support email guide.