Sending from your own domain
Why any of this is necessary
Nothing stops you typing your own address into a From field. The problem is that nothing stops anyone else either, which is why receivers do not take the From line at face value. They check whether the domain in it has authorised the server that sent the message.
The records below are that authorisation. Publish them and your mail arrives with your name on it; skip them and your mail either arrives from a BusinessDash address or lands in spam.
Adding the domain
In Email Builder → Sending, add the domain you want to send from. The platform registers it as a sending identity and gives you a set of DNS records to publish. Add them at your DNS provider, then run the check.
If you bought the domain through BusinessDash, this is already done — the records were written into the zone when the domain registered. See Buying a domain.
The records, and what each one is for
| Record | Type | Host | Purpose |
|---|---|---|---|
| DKIM (three of them) | CNAME | <token>._domainkey.yourdomain.com | Signs your mail so a receiver can verify it was not altered in transit |
| Bounce return path | MX | send.yourdomain.com | Lets your own domain carry the envelope, which is what makes SPF align |
| SPF | TXT | send.yourdomain.com | Authorises the platform's servers for your envelope domain |
| DMARC | TXT | _dmarc.yourdomain.com | Tells receivers your domain authenticates its mail |
The exact values are shown in the dashboard. Copy them rather than typing them: a DKIM token with one character wrong fails in exactly the same way as no record at all.
Why the bounce domain matters
Without a bounce return path on your own domain, the envelope on your mail carries the sending provider's domain instead of yours. SPF then passes for their domain, never aligning with the one in your From line, and DMARC can only ever pass on the DKIM half.
Configuring it is a single step in the dashboard — pick a label, usually
send — and it is what gets you authentication on both pillars instead of one.
DMARC starts at monitor
The DMARC record you are given starts at p=none, which means "I authenticate
my mail, do not act on failures yet". That is the right starting point: a
strict policy published before your aligned mail is actually flowing will
reject your own messages.
Once your mail is flowing and authenticating, tighten it to quarantine.
The checks are tolerant of your own additions. A DMARC record counts as
present if it starts with v=DMARC1, so your own reporting addresses are
fine, and an SPF record counts if it declares v=spf1 and includes the
platform's sender, so your other mail services can stay in it.
Verification states
| State | Meaning |
|---|---|
pending | Added, not yet confirmed |
verified | Authentication confirmed. Mail sends from this domain |
failed | The check ran and did not pass |
disabled | Turned off and not used for sending |
The panel also reports each record individually as found or missing, from the same source that generated the instructions. The instructions, the live check and the automated watch all read one definition, so they can never disagree about what "configured correctly" means.
Drift is watched hourly
Every other domain check on the platform is click-to-verify-once. Mail is the place where that fails quietly: a registrar change drops one DKIM record months after setup, deliverability decays for weeks, and nobody typed anything wrong today.
So verified sending domains are re-read every hour, and your admins are notified when a record that was present at the last sweep has gone.
You are notified on the transition from working to broken, not on every broken check. A domain halfway through setup would otherwise page someone every hour.
Which domain your mail sends from
Mail for your workspace is sent from your verified sending domain. The address
is your configured default, or notifications@yourdomain.com if you have not
set one, and your configured sender name goes in front of it.
If no verified domain exists, mail falls back to the platform address carrying your business name. The fallback is silent on purpose — a quote that does not go out because a DNS record is missing is worse for you than a quote that goes out from a BusinessDash address.
One verified domain is used for sending. If you add a second, do not assume you can choose between them per message — the first verified domain is what sends.
Testing it
The Sending tab has a test send. Use it after verifying, and read the result in the recipient's inbox rather than in the dashboard: what you are checking is the From name, the reply address, and whether it landed in the inbox or the spam folder.