Workspace Administration
Domains & email
Configure custom domains, CNAME records, SMTP, and workspace email settings.
Domains & email
Domains & email covers custom domains, DNS verification, tenant email configuration, SMTP delivery, reply-to details, and channel email integrations. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: custom domains, DNS verification, tenant email configuration, SMTP delivery, reply-to details, and channel email integrations.
- Where users start: Domain Settings are inside
/global-settings/company/settings; application integrations are at/settings/application/integrations. - Where administrators configure it: SMTP sender settings are saved with tenant company settings and include host, port, TLS/SSL, username, from address, and reply-to address.
- Runtime/detail surface: Verified domains shape tenant URLs, public links, portal links, email links, and embedded experiences.
- Platform connections: Domain and mail setup connects authentication, invitations, password reset, notifications, invoices, tickets, and Omnichannel.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Domain Settings are inside /global-settings/company/settings; application integrations are at /settings/application/integrations. | Day-to-day work and review. |
| Configuration | SMTP sender settings are saved with tenant company settings and include host, port, TLS/SSL, username, from address, and reply-to address. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Verified domains shape tenant URLs, public links, portal links, email links, and embedded experiences. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: Domain Settings are inside
/global-settings/company/settings; application integrations are at/settings/application/integrations. - Review the configuration route and permissions before changing live behaviour: SMTP sender settings are saved with tenant company settings and include host, port, TLS/SSL, username, from address, and reply-to address.
- Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Custom domain, SMTP delivery, and Reply-to email first because they shape the rest of the rollout.
- Add Mailbox integration and Gmail/Office365 only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Verified domains shape tenant URLs, public links, portal links, email links, and embedded experiences.
- Check downstream connections after saving: Domain and mail setup connects authentication, invitations, password reset, notifications, invoices, tickets, and Omnichannel.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Custom domain | Users need a branded tenant URL | Requires DNS CNAME verification. |
| SMTP delivery | Tenant email should use your mail provider | Configure host, port, TLS/SSL, and credentials. |
| Reply-to email | Replies should reach a monitored inbox | Set alongside from name and from email. |
| Mailbox integration | Inbound support mail should create conversations | Configure Omnichannel mailboxes. |
| Gmail/Office365 | OAuth mailbox connection is preferred | Configure under application integrations. |
| Notification templates | Message content needs editing | Configure at /settings/application/notification-templates. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Custom domain and SMTP delivery.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.
- /developer/authentication-classes
- /developer/inbound-webhooks
- /developer/outbound-webhooks
- /reference/system-identity