Create a mailbox for a person

When to use

A person joining the company needs a company mailbox. Not for a person leaving — that is tech.remove-mailbox. Not for setting up the mail program on their laptop or phone — that is tech.setup-mail-client, which runs after this one. If the company does not yet hold the domain the mailbox should be on, run tech.register-domain first.

Before you start

• The person exists in the people module with a start date.
• The address scheme is known (read it from an existing mailbox, do not invent a new pattern per request).
• The domain is held by the company and already serves mail (MX points at Brain Club). If unsure, check

What a run requires1

The trail8 steps

1. S1

   Confirm the requestagent

   Read the trigger: who, which domain, which aliases and groups. If anything is ambiguous (two spellings of the name, a role address instead of a personal one), ask the owner before creating.

   Done when address, aliases and groups are written down in one line.

2. S2

   Check for conflictsagent

   bc mail search <proposed address> — the address must not already exist as a mailbox or alias.

   Done when the search shows no existing mailbox and no alias pointing at one.

   ⛔ An alias of a departed employee is not free space — flag it; the old mailbox is handled by tech.remove-mailbox, not silently reused.

3. S3

   Approve the addressownerneeds approval · owner

   Approval · S3 · owner — the run stops until a named person records the decision

   Present the proposed address, aliases and groups.

   Done when the owner has confirmed the exact address in writing (chat message or task comment is enough).

4. S4

   Create the mailboxagent

   Create it in the mail module with the agreed address, a generated password, and no forwarding rules. Add aliases and group memberships as approved.

   Done when the mailbox appears in the mail module with the agreed address and zero forwarding rules.

   ⛔ Never send credentials to a manager, a colleague or a chat channel — hand them to the person only, through the onboarding channel the company uses.

5. S5

   Verify the domain serves mailagent

   bc dns <domain> (read) — MX, SPF, DKIM and DMARC records must match the expected values.

   Done when all four record types are present and match on every Brain Club nameserver.

6. S6

   Test both directionsagent

   Send a test message from an existing company mailbox to the new address, and one from the new mailbox to an external address. Ask the person to check both arrived — and that the outbound one did not land in the recipient's spam.

   Done when one inbound and one outbound test message are confirmed delivered, with timestamps.

7. S7

   First loginagent

   The person logs in (webmail or via tech.setup-mail-client, which runs next) and changes the generated password to their own.

   Done when the person has confirmed a successful login.

8. S8

   Record and hand backagent

   Link the mailbox to the person record; add a renewal/review note with bc tasks add only if the company tracks mailbox reviews; send the owner a two-line summary: address, aliases, test results.

   Done when the mailbox is linked to the person and the summary is sent.

Checks — how we know it worked

• The address in the mail module reads back exactly as approved in S3 (character by character — gn. vs
• Outbound test message passes SPF and DKIM (check the headers of the received test, not the send log).
• Forwarding rules: zero.
• The mailbox appears in the person's record and in no one else's.

If it goes wrong

What each step leaves behind

1. S1address, aliases and groups are written down in one line.
2. S2the search shows no existing mailbox and no alias pointing at one.
3. S3the owner has confirmed the exact address in writing (chat message or task comment is enough).
4. S4the mailbox appears in the mail module with the agreed address and zero forwarding rules.
5. S5all four record types are present and match on every Brain Club nameserver.
6. S6one inbound and one outbound test message are confirmed delivered, with timestamps.
7. S7the person has confirmed a successful login.
8. S8the mailbox is linked to the person and the summary is sent.

Evidence to keep

Approved address from S3 (who, when) · bc mail search output from S2 · mailbox creation date · test message timestamps both directions · the person's login confirmation.

How this playbook improves

After every 10 runs ask: how long from person-joined to confirmed first mail, and which step waited longest? Did any test message land in spam, and was the cause on our side? Did any mailbox end up with forwarding rules or a reused departed person's address? A new version changes the step that caused the wait or the failure, and says so in its change note.