Custom support email
Muninx gives every tenant a default support address such as [email protected]. Admins can also present one custom address, such as [email protected], to customers.
In these examples, acme is the tenant slug. The slug can be changed in Settings > Tenant; the default support address always uses the current slug.
A complete custom email setup has two independent parts:
- Receive: configure your email provider to automatically forward messages from
[email protected]to[email protected]. - Send: add
[email protected]in Settings > Tenant > Custom Sending Address, publish the three DKIM records, and wait for Muninx to verify them.
Muninx verifies that it can send from your address. It cannot see or verify forwarding configured in your mailbox. Configure both parts together so customers see the same address when they write to you and when they receive ticket notifications.
What each configuration does
Section titled “What each configuration does”| Inbound forwarding | Custom sender | Customer experience |
|---|---|---|
| Not configured | Not active | Customers can use the default Muninx address, and notifications come from it. |
| Configured | Not active | Email sent to the custom address can create tickets, but notifications come from the default Muninx address. |
| Not configured | Active | Ticket notifications come from the custom address, but email sent there is not guaranteed to reach Muninx. |
| Configured | Active | Customers can write to the custom address and receive ticket notifications from it. This is the recommended setup. |
An active custom sender applies to every ticket notification. It does not matter whether the ticket was created through the custom address, the default Muninx address, or the customer portal.
The default support@$TENANT_SLUG.muninx.com address for the tenant’s current slug remains operational after a custom sender is activated. Addresses containing historical slugs do not. If the custom sender is absent, disabled, or returned to provisioning by a verification check, Muninx sends ticket notifications from the current default address.
Account verification, workspace invitation, and password-reset emails are platform messages and always come from a Muninx address.
Configure inbound forwarding
Section titled “Configure inbound forwarding”Create server-side automatic forwarding from your custom address to the default address shown in Tenant settings. Use a dedicated mailbox or mailbox rule that preserves the original sender headers. Avoid manually forwarding messages or sending them through multiple forwarding hops, because Muninx might identify the forwarder instead of the customer.
The forwarding destination is derived from the current tenant slug. Changing the slug changes this destination immediately, and Muninx does not redirect the address for the old slug. For example, changing acme to acme-support changes the forwarding destination from [email protected] to [email protected]. If forwarding was already configured, update its external mailbox rule immediately to the new address shown in Tenant settings, then send another test message. A verified custom sender remains configured because it is independent of the tenant slug.
Use your provider’s forwarding instructions:
Use those links only for configuring forwarding in your email provider. Always forward to the exact Muninx address shown in your Tenant settings and use only the DKIM records supplied by Muninx.
Some providers send a confirmation message to the forwarding destination. That message can appear in Muninx as a new ticket. If Customer Access is Restricted or Closed, the confirmation message might be rejected. If necessary, temporarily permit inbound ticket creation while completing the provider’s verification, then restore the previous access setting.
Muninx does not monitor the forwarding rule after setup. Changes made by your email provider or mailbox administrator can stop forwarding without changing the sender’s status in Muninx.
Configure outbound sending
Section titled “Configure outbound sending”- Open Settings > Tenant and find Custom Sending Address.
- Enter the same address used for inbound forwarding.
- Add all three Easy DKIM CNAME records to the DNS provider for the address’s domain.
- Select Check verification after publishing the records. DNS detection can take up to 72 hours.
- When the sending state becomes Active, send a real message to the custom address and confirm that it creates a ticket.
The address is locked after configuration. To use another address, delete the current configuration and create a new one. A sending domain can be reserved by only one Muninx tenant at a time.
Replies and ticket routing
Section titled “Replies and ticket routing”Although the visible sender is the custom address, Muninx sets a ticket-specific internal Reply-To address. When a customer selects Reply, their response goes directly to the existing ticket instead of passing through your general forwarding rule. This prevents a response from being mistaken for a new ticket and avoids forwarding loops.
The ticket-specific Reply-To address also contains the tenant slug that was current when the notification was sent. After a slug change, replies to older notifications can fail because addresses for historical slugs are not retained. Replying to a notification sent after the change uses the current routing address.
Disable, enable, or delete the sender
Section titled “Disable, enable, or delete the sender”- Re-check verification checks whether Muninx can still send from the address. If verification is no longer valid, Muninx returns the sender to provisioning and immediately uses the default sender.
- Disable keeps the configuration and DNS setup needed for the address, but returns outgoing ticket notifications to the default Muninx sender. External forwarding continues until you disable it with your email provider.
- Enable custom sender checks verification again before using the custom address. If verification is no longer valid, publish or correct the displayed DKIM records and check again.
- Delete removes the sending configuration and releases the domain. External forwarding is not changed and must be removed separately if you no longer want custom-address email to create tickets.
Whenever you disable or delete the custom sender, review the external forwarding rule too. Leaving forwarding enabled creates the asymmetric experience where customers write to the custom address but receive notifications from the default Muninx address.