> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thread.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Email domain
> Set up one custom domain that both sends your customer email and receives the replies that wake your guides.
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.
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
Thread pre-fills it from your work email (e.g. `acme.com`).
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.
The part before the @ (the local part). `handoff` is the default; you can change it any time after setup.
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 ` — before you commit.
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](/guides/channels) for how guide email behaves.
Click **Turn on receiving**. Thread adds one MX record to your record list — the routing rule that delivers replies back to Thread.
Copy the host, value, and priority into your DNS, alongside the sending records.
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.
## Related pages
How guide email sends as a real person and wakes on replies.
Where each guide's email channel gets configured.
The SMS and voice counterpart to this page.
Logos, colors, and the rest of your customer-facing identity.