Operations, Setup, Email and Domains. Adding your own domain lets addresses be support@yourcompany.com rather than a platform subdomain. It requires publishing DNS records, which means access to wherever your domain is managed.
What You Need First
- Access to your domain's DNS - your registrar or DNS host.
- Agreement from whoever manages mail for the company, because you will be adding records that affect mail.
If you do not control DNS, stop here and get the person who does involved. Half-published DNS records are worse than none.
Adding The Domain
- Add your domain in the domains section.
- The DNS records are generated and shown to you.
- Publish each record at your DNS host, exactly as shown.
- Wait for verification. Each record's status is shown individually.
- Enable inbound once verification succeeds.
The Records
You are given a set of records to publish. Each has a type, a host name and a value.
| Record | Type | Does |
|---|---|---|
| SPF | TXT | Declares who is allowed to send mail as your domain |
| DKIM | TXT | Signs your mail cryptographically so receivers can verify it |
| DMARC | TXT | Tells receivers what to do with mail that fails SPF or DKIM |
| MX | MX | Directs where mail for the domain is delivered |
Caution
SPF is the one that breaks things. A domain may have only one SPF record. If you already have one for your existing mail provider, you must merge the new value into the existing record rather than adding a second. Two SPF records is an invalid configuration and mail from your domain starts failing everywhere, including mail that has nothing to do with the platform.
Copy each value exactly. The most common failure is a trailing space, a missing quote, or a DNS host that silently appends your domain to a host name that already includes it - producing support.yourcompany.com.yourcompany.com.
Verification
Verification is per record, and the status of each is shown. Partial verification is normal for the first hour.
DNS propagation is not instant. Most records resolve within minutes; some hosts take hours. If a record is still failing after 24 hours, it is published wrong rather than propagating slowly.
When you check a failing record, compare it at the DNS level rather than in your host's editor - the editor shows what you typed, not what is being served.
Turning On Inbound
Verification proves you own the domain and can send from it. Receiving is a separate switch, enabled once your MX arrangement is right.
This is deliberate. You may want to send from your domain while your existing provider continues to receive - which is exactly the arrangement most workspaces run, with mail arriving at the existing provider and being forwarded on. See Forwarding Mail From Your Provider.
Sending Versus Receiving
Two independent things, and mixing them up causes most of the confusion here:
- Sending - mail leaving the platform appearing to come from your domain. Needs SPF and DKIM.
- Receiving - mail addressed to your domain reaching the platform. Needs either MX pointed at us, or forwarding from your existing provider.
Most workspaces keep their existing provider for everyday mail and forward specific addresses. That keeps your team's mailboxes untouched and only routes the shared queues.
Common Questions
Will this break our existing email? Not if SPF is merged rather than duplicated, and you do not repoint MX away from your current provider. The forwarding approach is deliberately the low-risk path.
How long does verification take? Usually minutes. Give it 24 hours before concluding something is wrong.
Can I use a subdomain instead? Yes, and it is a good option for keeping platform mail cleanly separated from your primary domain.
One record will not verify. Check for a duplicate SPF, a host name your DNS provider has expanded twice, or a value truncated on paste. Those three cover almost every case.
Do I need my own domain at all? No. Everything works without one. It is a branding decision.
Did this answer your question?
No, ask a person