Receiving email
Hosted mailboxes are in a limited beta and are not open to every workspace yet. They are also purchase-gated: every plan starts with zero mailboxes, and allowance comes from the email module or a mailbox pack. If the Mailboxes section is hidden in your dashboard, one of those two is why.
What a mailbox is here
A mailbox is a real address on your verified sending domain —
dana@yourcompany.com — where BusinessDash is the mail host. Mail sent to it
is delivered into your workspace, where it is read, replied to and filed
against the customer it concerns.
A mailbox has to live on a domain you have verified for sending. Without that there is no authenticated way to reply from the address, so the mailbox would be able to receive and never answer.
| Personal | One staff member's own inbox |
| Shared | A team address like support@ or jobs@ |
Addresses are unique across the whole platform, not just your workspace. An address routes to exactly one mailbox, for the same reason a connected hostname serves exactly one site: delivery cannot be a coin toss.
A mailbox belongs to a workspace member, so the person it is for has to be on
your team first. Each one takes a seat against your mailbox allowance, and the
count includes shared addresses — support@ costs a seat the same as a
person's own inbox does.
Shared inboxes and who can act as them
A shared mailbox is owned by the admin who created it. Everyone else reaches it through a grant, and a grant can name either:
- a person, or
- a whole department, with membership resolved live.
The department form is the one worth using. Moving somebody into Support hands
them support@ with no further admin action, and moving them out takes it
away — there is no second list to remember to update.
A grant is full access to that one mailbox: read it, send as it, file from it. It needs no other mail permission, in the same way that reading your own inbox does not.
Offboarding freezes rather than deletes
When someone leaves, their personal mailbox is frozen:
| Frozen mailbox | |
|---|---|
| Receiving | Continues |
| Sending | Stops |
| Their sign-in | Already gone, with their membership |
It keeps receiving because the mail is often evidence and is owed to the business — a customer replying to a thread started by someone who has left must not vanish. It stops sending because nobody should be able to speak as a person who is no longer there.
For a shared mailbox, an offboarded member simply loses their grant. The address itself is unaffected.
How an incoming message is routed
Mail is delivered by envelope recipient — the address the sending server
actually delivered to — and not by the To or Cc headers.
That distinction matters for one specific case: a blind copy is a real delivery that the headers deliberately hide. Routing on headers would drop it.
Each matched mailbox gets its own copy. Recipients on your domain that match no mailbox are recorded as unknown rather than silently discarded, so a misaddressed message is diagnosable instead of a mystery.
What happens on delivery
| Step | Behaviour |
|---|---|
| Virus verdict fails | The message is not delivered at all |
| Spam verdict fails | Delivered and labelled as junk, with no notification |
| Already delivered | A repeat of the same message is ignored, matched on its message id |
| Reply to an existing thread | Joined to that thread via its reply headers |
| Attachments | Stored on arrival, with the message |
| Anything else | Delivered to the inbox, and the bell rings |
A virus verdict is the one gate that refuses delivery outright: nothing downstream should be able to open that payload, including the person it was addressed to.
The bell rings for the mailbox's owner and, on a shared inbox, for everyone holding a grant — including everyone currently in a granted department. Junk stays silent.
Message bodies are sanitised before they are stored, so an HTML email cannot run anything inside your workspace.
Attachments are stored as they arrive and are not virus-scanned at that point
— there is no scanner wired in yet, and the verdict recorded against each
attachment says skipped rather than clean. The whole message is still
dropped if the mail itself fails the virus check at delivery.
What is not open yet
- The inbound MX record is not being handed out. The receiving pipeline exists and works, but no sending domain currently has inbound switched on, so the MX record that would make BusinessDash your mail host is not included in your DNS instructions. This is on purpose: instructing an MX record before the receiving side is live for your domain would blackhole your mail — your old host stops getting it and nothing else picks it up.
- Adopting a domain already on Google or Microsoft. A domain has exactly one mail host. The model for adopting part of a domain — hosting mail on a dedicated subdomain so your existing mail keeps working — exists in the data but is not something you can configure yet.
Until inbound is open for your domain, treat the email features as outbound: sending from your own domain, campaigns, and the send log all work independently of any of this.