Skip to main content
By default, Thread sends customer email from a shared thread.app address. Configuring your own domain — under Settings → Branding & Identity → Email Domain — makes every customer-facing email come from your brand, and it’s what lets your guides hear back: replies route through the same domain and wake the guide that sent the message.
Email Domain settings: Sending and Receiving tabs, the sending address and display name, and per-DNS-record verification rows with copyable host and value
One domain serves both directions. The section splits into a Sending tab and a Receiving tab, but you set the domain up once.
Only organization admins can open Settings. You’ll need access to your domain’s DNS to add a handful of records — the section gives you each one with a copy button.

​
Create the domain

1

Enter your root domain

Thread pre-fills it from your work email (e.g. acme.com).
2

Pick a subdomain

Customer email sends from a subdomain of your root domain — updates is the default; notifications, onboarding, and mail are common alternatives. Using a subdomain keeps Thread’s sending separate from your company’s own mail.
3

Pick the email name

The part before the @ (the local part). handoff is the default; you can change it any time after setup.
4

Set a sender display name (optional)

How your name appears in customers’ inboxes. Left empty, your company name is used. A live preview shows the exact formatted sender — e.g. Acme Inc <handoff@updates.acme.com> — before you commit.
5

Create and add DNS records

Click Create Domain. Thread generates the DNS records you need and shows them as copyable rows.

​
The DNS record rows

Each record renders as one compact row: a status dot, the real DNS record type you’ll pick at your provider (TXT, CNAME, MX), a two-word purpose (Sending, Ownership, Replies), and the Host and Value as one-click copy fields. MX rows also show the Priority you’ll need to enter. The dot is the verification verdict for that specific record:
  • Green — verified.
  • Red — failed: the value found in DNS doesn’t match what’s expected. Re-copy the value and check for truncation or a doubled domain suffix.
  • Muted — pending: not verified yet.
Click Check Verification any time to re-run the check. It refreshes every record’s status from the live answer, so the dots tell you exactly which records have landed and which are still wrong or missing — no guessing about which line in your zone file is the problem. DNS changes can take a few minutes (occasionally longer) to propagate.

​
Sending

The Sending tab owns everything about outbound mail:
  • Configured Domain — your full sending domain, with the Check Verification button beside it.
  • Sending Email Address — the local part is editable in place (e.g. change handoff@ to onboarding@) without touching DNS.
  • Sender Display Name — also editable in place; this is the name customers see in their email client.
  • DNS Records to Add — the sending records (ownership and sending authorization), shown until the domain verifies.
When every sending record verifies, the header badge flips to Verified and customer-facing emails start sending from your domain. A Send Test Email to Yourself button appears — use it to see exactly what customers will receive, from the real address with the real sender name. If verification fails, the error is shown on the page verbatim so you can fix the record it names.

​
Receiving

The Receiving tab is what turns your domain into a two-way channel. With receiving on and verified, replies to a guide’s emails land at a per-conversation address on your domain (guide+…@updates.acme.com) and wake the guide — same conversation, same memory, exactly like an inbound text. Every guide in your organization inherits this once it’s set up. Customers see that address labelled with your organization’s name (“Acme Support”) next to the sender’s own address when they reply, so the reply reaches both. See Channels for how guide email behaves.
1

Turn on receiving

Click Turn on receiving. Thread adds one MX record to your record list — the routing rule that delivers replies back to Thread.
2

Add the MX record

Copy the host, value, and priority into your DNS, alongside the sending records.
3

Check verification

The Receiving tab’s check reports the MX record’s own status — a pending sending record never makes a genuinely verified reply route read as failed. When it verifies, the header shows a Receiving badge and guides can receive replies.
You can turn receiving off from the same tab without touching the sending setup.

​
Removing the domain

Remove Domain (bottom of the Sending tab) reverts customer email to the thread.app domain. If receiving is on, removal also disconnects your guides’ reply routing: replies to emails already in customers’ inboxes will no longer route back, and guides can no longer send. The confirmation dialog spells this out — it affects every guide in your organization, so treat removal as a last resort.
If guides are actively emailing customers, don’t remove or swap the domain mid-conversation. In-flight replies address the old domain and won’t find their way back.

Channels

How guide email sends as a real person and wakes on replies.

Building a guide

Where each guide’s email channel gets configured.

Phone and registration

The SMS and voice counterpart to this page.

Branding

Logos, colors, and the rest of your customer-facing identity.