Email

Databayt's client mail still leaves from personal inboxes. This page is the architecture for replacing that with company-owned hi@ and sales@ on every product domain, plus the tracer that keeps the domains and mail records alive. It is a research document first: nothing in production DNS or any mailbox changes until the one-domain test in §19 passes and Abdout approves.

Labels used throughout:

1. Executive summary

• Domains: databayt.org (company), balqalam.com (Hogwarts), mkan.sd (Mkan), and one upcoming product. All four sit on Cloudflare DNS. The registrars are Namecheap, Cloudflare and sdnic.
• Apple iCloud+ has the capacity but fails the ownership requirement. One iCloud+ plan allows 5 domains and 3 addresses per person per domain, so all 8 addresses fit. But a company Apple Account shared by four salespeople breaks the iCloud Terms: "You should not share your Account and/or password details with another individual". Giving addresses to employees' own Apple Accounts instead means that, after they are removed, "any emails they sent and received… remain in their iCloud Mail account". Apple's 2026 Apple Business email is US-only and allows one domain per organization.
• Microsoft Exchange Online Plan 1 is the recommended draft (Recommendation). It costs $4 per user per month. One tenant holds every domain. hi@ and sales@ become company-owned shared mailboxes, which are free up to 50 GB. People get, and lose, permission to them, and the mail never leaves with a person. Apple Mail on Mac and iPhone connects natively. The core setup costs about $240 a year.
• Google Workspace Business Starter is the close alternative. It costs $7 per user per month, and Google Groups serve as free collaborative inboxes. Choose it if the team lives in Gmail, Docs and Meet.
• Outreach never goes out from hi@ or sales@. Cold sequences run on a separate domain through a dedicated tool. App mail stays on Resend on the send. subdomain, which is already the case for databayt.org.
• Twenty stays the system of record. The mailbox is only a channel. Twenty v1.3+ syncs Google, Microsoft and IMAP mailboxes, but only true mailboxes (see §10).
• Health tracing is live (see Health tracing). Every domain's expiry, auto-renew, nameservers, MX, SPF, DKIM, DMARC and TLS are checked daily, and the inboxes weekly. Problems open an assigned GitHub issue that names the fix.

2. Databayt requirements

1. A professional identity: hi@ and sales@ on each of four domains.
2. Reliable delivery in both directions, with mail never lost.
3. Mail and identity owned by the company. A departing employee loses access the same day and takes nothing with them.
4. Apple Mail on macOS, iPhone and iPad as the daily client.
5. A small sales team (about 4) working human-in-the-loop, out of about 20 staff in total.
6. Twenty CRM as the authoritative customer record.
7. Low cost: cash flow comes first (The Drive).
8. Room for the existing automation: Mail.app scripting, plus read/send loops like the jobs lane.

Not a requirement: an enterprise collaboration suite. Twenty, Slack and the kun engine already cover collaboration.

3. Proposed iCloud architecture (as briefed)

CopyDatabayt
 └── dedicated company Apple Account  (iCloud+)
      ├── databayt.org   hi@  sales@
      ├── balqalam.com   hi@  sales@
      ├── mkan.sd        hi@  sales@
      └── product-4      hi@  sales@

Capacity fits: 4 domains is within the cap of 5, and 2 addresses per domain is within the cap of 3 per person (Verified — Apple 102540, Create and delete addresses). The problem is access, which §4–§9 work through.

4. How Apple custom-domain email actually works

5. Company ownership model

Four separate layers. Most email incidents come from blurring them.

With Apple, layers 3 and 4 merge. The domain owner is whoever subscribed and added the domain. "Only the domain owner can add and remove people." Members can "only create and delete your own email addresses", and every member's mail sits in their own account (Verified add/remove). The company Apple Account can stay the permanent domain owner, but any address it gives an employee lives in the employee's mailbox.

With Microsoft or Google, layers 3 and 4 are separate by design. The tenant owns every mailbox, and a person is only granted access.

6. Employee access model

Sources (Verified): Microsoft shared mailboxes, Google collaborative inbox.

7. Employee onboarding (Recommendation, Microsoft path)

CopyAdmin creates  ali@databayt.org  (licensed, Plan 1)  → MFA enrolled on the employee's phone
  → grant Full Access + Send As on  sales@balqalam.com  (shared)
  → employee adds the account in Apple Mail (Mac + iPhone): Exchange, Microsoft sign-in
  → shared mailbox appears; replies go out "as" sales@balqalam.com
  → Twenty: employee's mailbox connected (Microsoft), owner set on their companies/opportunities

The employee never learns any password except their own.

8. Employee offboarding (Recommendation, Microsoft path)

With Apple, step 4 does not exist. Removing a member deletes their addresses, bounces new mail and leaves their history in their own iCloud account (Verified). Moving an address to another member needs both people to accept, so an uncooperative leaver can block it (Verified transfer). Whether history moves with a transferred address is Must-test (Apple doesn't say).

9. Hostile employee scenario

A salesperson leaves on bad terms. What can they keep?

No mail product stops someone who already downloaded mail. The defence is to keep the history in a company system (Twenty plus company-owned mailboxes) and to revoke access fast.

10. Twenty CRM architecture

CopyTwenty (system of record)
  ├── companies · contacts · opportunities · tasks · workflow state
  ├── connected mailboxes ──sync── each salesperson's licensed mailbox (Microsoft OAuth / Google / IMAP)
  └── workflows ──HTTP Request / webhook──▶ kun automation (drafts, follow-ups, digests)

• Twenty connects Google, Microsoft or IMAP/SMTP/CalDAV accounts. IMAP arrived in v1.3.0 (Aug 2025). "Only true mailboxes can be connected." (Verified docs, releases)
• Workflow Send Email goes to one recipient per action from a connected account. There are also an HTTP Request action, a webhook trigger and record webhooks (Verified send from workflows, actions).
• Must-test: whether mail that arrives in a shared mailbox reaches Twenty. A shared mailbox isn't a "true mailbox", so it can't be connected. Two ways out: (a) make sales@ a Microsoft 365 group or distribution list that delivers into each member's mailbox, which Twenty does sync; or (b) license sales@ as a role mailbox ($48/yr), held by the admin, with the team delegated in.
• Apple mail could reach Twenty through IMAP with an app-specific password, but that is exactly the shared-credential pattern the iCloud Terms rule out for a team.

11. Apple Mail architecture

Sources: Apple + Exchange (Verified), Google LSA → OAuth (Verified). Day to day, all three feel like a normal mailbox in Apple Mail. The difference is who owns what is inside it.

12. Security architecture

• Admin identity: one dedicated admin account per provider (for example admin@databayt.org). It is never used for daily mail. Its MFA uses a hardware key or an authenticator held by two founders, and there is a break-glass second admin with credentials sealed in the company Keychain (credentials skill).
• Apple specifically (if used anywhere): the trusted phone number must be a company SIM, not a person's. The recovery key needs an Apple device, and losing it means permanent lockout (Verified 109345).
• Registrar: 2FA, registrar lock on (checked daily), company card, auto-renew on (verified monthly, see Health tracing).
• DNS: Cloudflare 2FA, least-privilege API tokens, DNSSEC to be turned on (Proposed, §19).
• Phishing and takeover: MFA for every user, Microsoft/Google default anti-phish, and no SMTP basic auth. Microsoft turns SMTP AUTH basic auth off by default at the end of December 2026 (timeline), so automation uses OAuth or Graph.
• Passwords: Keychain (credentials skill), never in chat, .env or docs.

13. DNS / email authentication

Every value comes from the provider's admin console. Never copy values from this page or another domain.

Current state (what the tracer sees today):

• databayt.org: Private Email MX, SPF and DKIM are correct; DMARC is quarantine but has no rua.
• balqalam.com: Cloudflare Routing MX; DMARC is p=none with no rua.
• mkan.sd: no records at all, so anyone can send as @mkan.sd.

14. Deliverability and outreach

Rules from the receivers (Verified):

• Gmail and Yahoo require SPF, DKIM, DMARC, one-click unsubscribe, and a spam rate under 0.3%. Gmail has rejected non-compliant mail since November 2025 (Google 81126).
• Outlook.com requires the same for senders over 5,000 a day from 5 May 2025 (Microsoft).

Provider caps:

• iCloud: 1,000 a day, with bulk prohibited.
• Google: 2,000 messages a day and 3,000 external recipients (limits).
• Exchange: 10,000 recipients a day plus a tenant-wide external limit. Microsoft tells bulk senders to use third parties (limits).

None of the three is an outreach engine. Protecting the main domains' reputation is the point.

15. Apple vs Microsoft vs Google

16. Detailed cost comparison

Prices are in USD, list price on annual commitment, before tax. All three charge per user or account, never per domain.

Mailbox vs suite: Exchange Online Plan 1 is mail only (50 GB mailbox, calendar, contacts). Business Basic adds Teams, SharePoint and OneDrive. That is a collaboration suite we would be paying for without using.

17. Risks and limitations

18. Recommended architecture

Copy                    ┌──────────────── Databayt (company-controlled) ───────────────┐
 Registrars ──────▶ │ Namecheap · Cloudflare · sdnic   (founder 2FA, lock, auto-renew)│
 DNS ─────────────▶ │ Cloudflare zones (MX/SPF/DKIM/DMARC per domain)                 │
                    │                                                                  │
 Mail tenant ─────▶ │ Microsoft 365 tenant  (admin@ + break-glass, founder-held MFA)  │
                    │   licensed: abdout@ · 4 × salesperson@databayt.org             │
                    │   shared:   hi@ + sales@ × {databayt.org, balqalam.com,         │
                    │             mkan.sd, product-4}                                 │
                    │   access:   Full Access + Send As, granted per person           │
                    └──────────────────────────────────────────────────────────────────┘
        ▲ Apple Mail (Mac/iPhone, Exchange OAuth)            │ Microsoft connector
        │                                                    ▼
   salespeople ──────────────────────────────────────▶  Twenty CRM  (system of record)
                                                             │ HTTP / webhooks
                                                             ▼
                                                       kun automation
   Separate:  send.<domain> → Resend (app mail) · outreach domain → sequencing tool
   Watching:  kun domains tracer (daily) → GitHub issue → Abdout's phone

Decision checklist:

• Choose Microsoft if the team works in Apple Mail and Twenty, wants the lowest real cost, and needs strict offboarding (this is Databayt today).
• Choose Google if the team would rather work in Gmail, Docs and Meet, or wants the simplest admin with groups as shared inboxes.
• Choose Apple only for a brand run by one person who will never hand the inbox to someone else.

19. Migration plan

Nothing touches production before step 4.

1. Decide the provider (Abdout) and confirm billing-country availability.
2. Create the tenant with the admin and break-glass identities. Founder-held MFA.
3. Lab test on lab.databayt.org. Add only new records under that subdomain. The apex MX is untouched. Create test@lab.databayt.org (shared) and one licensed test user, then run the checklist in §20.
4. balqalam.com first. Snapshot the zone to cf/dns/balqalam-com-snapshot-<date>.json, set the MX TTL to 300 the day before, add the verification and DKIM records, cut over the MX and SPF, and keep DMARC p=none with rua. Update cf/domains.json in the same commit so the tracer adopts the new baseline.
5. databayt.org next. Export the Private Email mailboxes over IMAP into the new tenant, then cut over. Cancel Private Email at its renewal.
6. mkan.sd and product-4. Fresh setup.
7. DMARC ramp: after 2–4 weeks of clean reports, quarantine, then reject.

Proposed security records (can't break mail, but still need Abdout's yes):

• rua= on the existing DMARC records
• v=spf1 -all + p=reject on mkan.sd until it gets mailboxes
• DNSSEC (Cloudflare one-click, plus the DS record at Namecheap and sdnic)

20. Testing checklist (lab domain)

• Inbound from Gmail, Outlook.com and iCloud reaches test@ (and not spam)
• Outbound as test@ passes SPF, DKIM d=lab.databayt.org, and DMARC aligned (read the headers)
• Apple Mail on the Mac: shared mailbox visible; reply goes out as test@; attachment up to 20 MB
• iPhone Mail: the same
• Reply-from-the-received-address behaviour on all clients
• Sent copy is saved in the shared mailbox's Sent folder
• Twenty: test user's mailbox syncs; a thread on test@ reaches Twenty (§10 a/b)
• Offboarding drill: block the test user, then confirm no access within 5 minutes on Mac and iPhone and that history stays in test@
• Replacement drill: grant a second user and confirm the full history is visible
• Forwarding-rule audit shows in the admin center
• Tracer: add lab.databayt.org to cf/domains.json and see it green

21. Rollback plan

• Before any cutover, the full zone is saved to cf/dns/<domain>-snapshot-<date>.json, and the old provider stays paid until the end of the month.
• Rollback = restore the MX, SPF and DKIM records from the snapshot. With TTL 300, inbound returns to the old provider within minutes. Mail that arrived at the new provider in the meantime is exported over IMAP and imported back.
• The tracer flags any half-done state (MX drift is a blocking alert), so a stalled migration can't go unnoticed.

Health tracing

Kun now traces every domain so none expires and no mail record drifts unnoticed.

Why auto-renew needs a human: no registry or whois shows auto-renew, and Namecheap and sdnic offer no API we hold. So someone (Cowork, in Abdout's Chrome) looks at each registrar page once a month, and autoRenewVerifiedAt in cf/domains.json records that they did. A stale stamp is a warning, and the warning is the reminder.

First findings, 2026-10-03:

• abdoutgroup.com expires 2026-11-05 (33 days).
• mkan.sd and abdoutgroup.com can be spoofed.
• balqalam.com DMARC is p=none.
• No domain's auto-renew has been verified yet.
• The Namecheap Private Email MX refused this Mac after repeated probes. The probe is now weekly, and refusals count as "unreachable", not as a dead inbox.