How HelpMesh handles BYOD email — without rewriting your MX
A walkthrough of the asymmetric BYOD email architecture: outbound on your custom domain, inbound through Postmark, Reply-To routing for everything in between.
By HelpMesh Engineering
BYOD (Bring Your Own Domain) email is one of the most-requested features for any white-label support platform. Customers want their tenants to receive replies from support@yourdomain.com, not support@helpmesh.io.
The naive solution — "point your MX records at us" — does not work for most customers. Their domain is also their corporate email, hosted on Google Workspace or Microsoft 365. Pointing the MX at a third party would break primary email for the whole company.
The asymmetric solution
HelpMesh runs an asymmetric BYOD architecture. Outbound mail is signed with your domain and DKIM, looking authentic to the customer's inbox. Inbound mail flows through a HelpMesh-owned subdomain (inbound.helpmesh.io). The two are bridged with a Reply-To header that makes customer replies seamless.
Outbound
When a tenant verifies a custom domain, we provision DKIM keys via Postmark. Postmark publishes a CNAME pointing the DKIM selector at their key infrastructure. We sign every outbound message with that DKIM record, and the From header reads support@yourdomain.com. The customer's inbox sees a valid DMARC pass.
Inbound
HelpMesh owns the MX for inbound.helpmesh.io. Each tenant gets a Pattern A address: {tenantSlug}@inbound.helpmesh.io. Mail to that address is parsed by Postmark's inbound webhook, which posts a JSON payload to our /api/webhooks/postmark endpoint with the threading headers, attachments, and full HTML body intact.
The Reply-To bridge
Without intervention, a customer hitting "Reply" on a HelpMesh-sent message would route the reply to support@yourdomain.com — which lives in the tenant's Workspace mailbox, not HelpMesh. To fix this, every outbound message includes a Reply-To: {tenantSlug}@inbound.helpmesh.io header. Every major email client respects Reply-To over From for the "Reply" action, so the customer's reply lands in HelpMesh automatically — even though the From header pointed at a different domain.
What about brand-new emails?
The Reply-To bridge handles 95% of inbound traffic — replies to existing threads. The remaining 5% is when a customer types support@yourdomain.com from scratch into a blank email. That email lands in the tenant's Workspace inbox, not HelpMesh. We document two workarounds:
- Set up a forwarding rule in Workspace / Outlook to copy every email arriving at
support@yourdomain.comto{tenantSlug}@inbound.helpmesh.io. - Share the
{tenantSlug}@inbound.helpmesh.ioaddress directly on the website's contact page.
Why not just MX
An ideal architecture would have the customer point their MX at HelpMesh, eliminating the Reply-To bridge. We support that for customers who do not need primary email on the same domain — but the asymmetric approach is the default because it does not require touching primary email infrastructure. Setup is one DKIM CNAME and one verification round-trip; total time to BYOD is under 10 minutes.
For the full setup walkthrough, see /docs/email-setup.