message.comDevelopers

Connect a custom email domain for tickets

Receive customer email at [email protected] and reply from the same address. Replaces the default [email protected] sending identity with your brand domain. Requires MX, SPF, DKIM, and DMARC records, set in your DNS host.

Pointing MX records at us replaces your existing mail provider for the chosen domain or subdomain. If your team currently uses [email protected] in Gmail or Outlook, set up a subdomain (help.yourdomain.com) instead, or migrate the team to message.com first.

1. Pick a domain or subdomain

Two patterns:

  • Apex domain. [email protected]. Cleanest brand. Only works if you do not currently use that local part on another mail provider.
  • Subdomain. [email protected]. Coexists with your existing mail provider on yourdomain.com. Recommended when migrating.

2. Add the domain in message.com

  1. Open app.message.com.
  2. Go to Settings → Tickets → Email domains.
  3. Click Add domain. Enter the apex or subdomain.
  4. The dashboard shows the exact DNS records you need.

3. Add the DNS records

In your DNS host (Cloudflare, Namecheap, AWS Route 53, GoDaddy, etc.), add four records:

Example DNS zone
; MX (inbound mail)
@   IN MX 10 inbound.message.com.

; SPF (outbound, include the sending ESP)
@   IN TXT "v=spf1 include:_spf.message.com -all"

; DKIM (rotates; copy exact value from message.com dashboard)
mxc._domainkey   IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

; DMARC (start in monitor mode)
_dmarc   IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
  • MX directs inbound mail to our SMTP receivers.
  • SPF authorises our outbound ESP to send on your behalf. If you already have an SPF record, merge the include:_spf.message.com mechanism into it.
  • DKIM proves messages we send are cryptographically tied to your domain. The key shown in the dashboard is unique to your workspace.
  • DMARC tells receivers what to do with mail that fails SPF or DKIM. Start with p=none to monitor; tighten to p=quarantine or p=reject once you confirm legitimate mail is passing.

Avoid -all in your SPF record on day one if you have several mail senders (marketing tools, transactional ESPs). Start with ~all while you audit.

4. Verify in message.com

  1. Wait a few minutes for DNS to propagate (longer if your TTL is high).
  2. In message.com, click Verify.
  3. Each of MX, SPF, and DKIM flips green when the record is observed.
  4. Once all three are green, the domain is connected.

5. Route ticket replies through the new domain

  1. Open Settings → Tickets → Inbound.
  2. Edit your inbound address. Change the address to [email protected] (or whatever local part you want on the new domain).
  3. Save. Replies now come from this address.

Verify end to end

  1. From an external account, send a test email to [email protected].
  2. The ticket appears in app.message.com within seconds.
  3. Reply. The outbound message arrives at the sender with From: [email protected].
  4. In the sender's mail client, view headers. Authentication-Results should show spf=pass dkim=pass dmarc=pass.

Common pitfalls

  • Multiple SPF records. A domain can have only one v=spf1 TXT record. Merge our include into your existing record.
  • DKIM selector clash. Our selector is mxc. Unlikely to clash, but check before adding.
  • Subdomain SPF. Subdomains do not inherit the apex SPF record. Add SPF separately on the subdomain.
  • Strict DMARC. Going straight to p=reject can blackhole legitimate mail (marketing tools, contractor senders). Start at p=none and tighten over a week or two.
  • Existing Google Workspace MX. Pointing MX at us removes Google from the receiving path. If you still need Workspace for the team, use a subdomain.

Next steps