Email-sending domain

Settings → Email Domain changes the sender address used by supported portal emails. It is an optional branding setup, not a prerequisite for using the portal's shared sender.

An account owner manages the domain. The page's How your email works right now section shows the resolved sender, the per-conversation reply domain, and the current forwarding destination when one exists.

Set up a branded sender

1. Choose a domain or subdomain you control, such as mail.yourbusiness.com.
2. Enter it with the desired sender name and sender address prefix.
3. Add the exact DNS records generated on the page in your domain's DNS settings.
4. Run the verification/refresh controls and inspect each record's status.
5. After verification, check the current sender shown on the page and send a test through the intended workflow.

Copy the generated names, values, types, and priorities rather than using a static example from a guide. DNS providers differ in whether they append the root domain to record names. Do not replace unrelated website or mailbox records.

DNS updates and provider verification can take time. If records are missing or verification fails, inspect the page's error and refresh the status.

What changes after verification?

A verified custom domain supplies the sender address and optional display-name override. Without a verified domain record, the portal uses its configured shared sender with your business name where supported.

This does not create a general-purpose mailbox, change your login email, or configure Stripe's own email/receipt settings. Support email under Branding is a separate contact/notification-routing field.

The sender fallback is based on the saved domain status. It is not a guarantee of delivery after every DNS or provider failure: stale verification, bounces, spam filtering, suppression, and recipient issues still need investigation.

Where replies go

Supported portal conversations use a dedicated thread reply address. Replies can be stored and a courtesy copy forwarded without a custom domain. However, the current Email hub still requires a verified organization domain to read and manage that inbox. Before verification, the hub shows setup steps.

The settings page shows the forwarding destination when available. It can use the verified domain's configured forwarding address or the organization's owner fallback. Reply routing and access to the Email hub UI are separate requirements.

Reply inside the correct portal conversation to preserve its history and recipient. A message shown as sent is not the same as confirmed delivery; inspect available delivery status before retrying an uncertain send.

Change or remove a domain

Use the sender controls to change the display name or address prefix. Removing the domain returns supported sends to the configured shared sender. Replacing an existing domain requires removing the current organization domain first.

Existing messages in recipients' inboxes do not change. Test new sends and replies after a change. Do not publish or paste a provider API key into DNS records or an email form.

Texting uses a separate opt-in and transport; see Text Messages.

Notification preferences are separate

Settings → Notifications has Client Onboarded and Approval Responses switches for the admin notification bell. Both default on, and saving this form is owner-only. These are not master switches for email, SMS, or every notification type.

Client email preferences live in the client's Profile settings. Changing a sender domain does not change those preferences.