Design — Google Workspace rebrand: thecloudbasefoundation.org → cloudbase.foundation

Date: 2026-06-09 · Owner: Both (Jonathan = Admin console + Cloudflare DNS; Claude = repo/app changes) · Status: Phase 1 complete — Phase 2 flip pending

Progress (2026-06-09): Phase 1 mail cutover for cloudbase.foundation is done and DNS-verified — MX → Google (aspmx.l.google.com set), SPF → include:_spf.google.com, DKIM google._domainkey published (2048-bit), DMARC _dmarc at p=none with rua=mailto:dmarc@cloudbase.foundation (alias live), and Cloudflare Email Routing turned off. Exact record values + verification in the companion doc 2026-06-09-workspace-domain-rebrand-dns-records.md. The golden rule is satisfied, so the Phase 2 primary-domain flip is now safe to perform. Still pending: Phase 2 flip (Jonathan) and the Phase 3 downstream repo/OAuth updates (Claude).

Goal

Make cloudbase.foundation the primary domain of the Google Workspace org. Every user's primary email becomes name@cloudbase.foundation; name@thecloudbasefoundation.org is retained as a permanent alias so old mail keeps arriving and nothing breaks. The old domain is never removed.

Decisions (locked)

1. End-state: rebrand identity to the new domain, keep the old domain as a lifelong alias.
2. Method: Approach A — Google Workspace's "change primary domain" flow (one admin action re-points every user's primary address and auto-demotes the old domain to an alias). Not a per-user rename.

Current state (verified via DNS, 2026-06-09)

So part of this job is moving cloudbase.foundation's mail off Cloudflare routing into Google Workspace (MX cutover) before the identity flip.

To confirm in Admin console (Phase 0, not blocking design): whether cloudbase.foundation is already added as a secondary domain in Workspace (vs only Search-Console-verified); user/mailbox count; the exact Cloudflare Email Routing rules; any Google-SSO apps beyond kan.

The golden rule

Stand up the new domain's mail completely BEFORE the primary-domain flip. If the flip happens first, users' new @cloudbase.foundation primary addresses can't receive mail yet.

Migration phases

Phase 0 — Pre-flight (Jonathan)

Confirm the Phase-0 facts above. Inventory the Cloudflare forwards so each is recreated in Workspace.

Phase 1 — Stand up cloudbase.foundation mail (critical prep)

1. Add + verify cloudbase.foundation as a secondary domain in Workspace (verification TXT present).
2. Recreate the info@/contact@ Cloudflare forwards as Workspace aliases/mailboxes so they keep receiving after the MX move.
3. Cloudflare DNS changes for cloudbase.foundation:
   • MX: replace route{1,2,3}.mx.cloudflare.net → Google (smtp.google.com, or the 5 classic aspmx records).
   • SPF: v=spf1 include:_spf.google.com ~all (was Cloudflare's include).
   • DKIM: generate in Admin → Apps → Gmail → Authenticate email (for cloudbase.foundation), publish the google._domainkey TXT.
   • DMARC: add _dmarc.cloudbase.foundation TXT at p=none (monitor first; tighten later — aligns with the CRM roadmap Phase 6 email-auth work).
   • Turn OFF Cloudflare Email Routing for the domain so it doesn't fight Google's MX.
4. Verify: test-mail to info@cloudbase.foundation lands in Workspace; MX/SPF/DKIM check clean (e.g. MXToolbox).

Phase 2 — Primary-domain flip (Jonathan)

1. Admin Console → Account → Domains → Manage domains → Change to a different primary domain → cloudbase.foundation.
2. Google rewrites every user's primary address → @cloudbase.foundation; old address auto-becomes an alias; old domain demoted to secondary. ~24 h propagation; each user re-signs-in once.
3. Verify: a sample user's primary is now @cloudbase.foundation and the old address still receives.

Phase 3 — Downstream / dependency updates (Claude + Jonathan)

• kan (CBF-kanban): Google-OAuth domain lock → cloudbase.foundation. Touch ~/kan/.env, CBF-kanban/.env.example, README. Update the OAuth client's authorized domain + redirect URIs in Google Cloud. Test login with a @cloudbase.foundation account. (Consider allowing BOTH domains during the transition window so no one is locked out mid-propagation.)
• Google Cloud OAuth consent screen: add cloudbase.foundation to authorized domains.
• CBF-site: replace displayed @thecloudbasefoundation.org addresses → @cloudbase.foundation (Footer, contact, about, get-involved, past-projects — the files found in the repo grep).
• Twenty CRM: determine whether admins sign in via Google (then the email change matters) or email/password; update workspace-member emails if needed.
• Docs: documents/tech/domain-map.html + roadmap.html, CBF-crm/docs/strategy/domain-map.html
  • roadmap.html references.

Phase 4 — Comms & cleanup

• Notify the team: new primary address, one-time re-sign-in, update signatures.
• Update sender addresses on GiveLively / Donorbox / social (old still works as alias).
• Keep thecloudbasefoundation.org as an alias indefinitely. Do not remove it.

Risks & rollback

• Flip-before-mail-ready → new primary addresses can't receive. Mitigated by the golden rule (Phase 1 before Phase 2).
• SSO/kan lockout if the OAuth allowed-domain isn't updated around the flip → update Phase 3 kan/OAuth in the same window; allow both domains during transition.
• New-domain mail to spam if DKIM/DMARC missing → set them in Phase 1 before sending.
• Rollback: all DNS changes are revertible; the primary-domain change can be switched back in Admin console if needed.

Ownership split

• Jonathan: all Admin-console actions (domain add/verify, mailboxes/aliases, DKIM generation, primary-domain change), Cloudflare DNS edits, Google Cloud OAuth client/consent edits.
• Claude: repo changes (kan config, CBF-site addresses, docs), drafting DNS record values and the comms, verification scripting (dig/MXToolbox-style checks).