某上海外贸公司，主营跨境电商，团队 42 人，长期使用个人 Gmail 账号处理业务邮件。问题在于：员工离职后，与客户的往来邮件无法收回；公司域名在邮件中毫无体现，客户认为不专业；内部也没有统一的通讯录和文件共享机制。
他们找到我们时提出的需求很简单："用公司域名发邮件，能统一管理账号，安全一点。"实际交付的内容远不止如此。以下是完整实施记录。
规模：42 人 · 域名：已有，托管于阿里云 · 历史邮件：各自 Gmail，约 3 年数据 · 实施周期：3 个工作日
第一步：环境准备与决策确认
在动手之前，我们花了半天时间和客户确认三件事：
- 域名控制权——确认可以修改 DNS 记录，这是整个部署的前提
- 版本选择——Business Starter（¥42/用户/月）还是 Business Standard（¥84/用户/月）。对于他们的需求，Starter 足够，但我们建议 Standard，原因是 Meet 录制和增强搜索在外贸场景有实际价值
- 割接窗口——选择了周五晚上到周六早上，业务低峰期
第二步：域名验证与 MX 配置
Google Workspace 需要验证你对域名的控制权，方式是在 DNS 中添加一条 TXT 记录。这一步通常在 10 分钟内完成，但 DNS 传播需要等待，实际验证通过的时间从几分钟到数小时不等。
添加域名验证 TXT 记录
在 Google Admin 控制台获取验证码，格式类似 google-site-verification=xxxxx，添加到域名的 TXT 记录中。
修改 MX 记录
删除原有 MX 记录，添加 Google 提供的 5 条 MX 记录（ASPMX.L.GOOGLE.COM 等），优先级按照文档配置。注意：修改 MX 之前务必确保邮件迁移已经完成，否则新邮件会直接进入 Google，而不是原系统。
配置 SPF 记录
添加 TXT 记录：v=spf1 include:_spf.google.com ~all。如果域名还在用阿里云发送营销邮件，需要合并为 v=spf1 include:_spf.google.com include:spf.mxhichina.com ~all。
第三步：DKIM 和 DMARC 配置
这是很多小企业忽略的部分，也是最容易被钓鱼仿冒的漏洞。
DKIM 需要在 Google Admin 控制台生成密钥对，将公钥以 TXT 记录的形式发布到 DNS，名称格式为 google._domainkey.yourdomain.com。DMARC 则是在 DNS 中添加一条 _dmarc.yourdomain.com 的 TXT 记录，指定收件方如何处理验证失败的邮件。
DMARC 策略建议从 p=none（仅监控，不拦截）开始，观察 2-4 周报告后再切换到 p=quarantine 或 p=reject。直接上 reject 会导致合法邮件被拒。
第四步：批量创建账号与组织架构
42 个账号手动创建既耗时也容易出错。我们使用 Google Admin 的 CSV 批量导入功能，模板包含：用户名、姓名、部门、初始密码（统一设置为临时密码，强制首次登录修改）。
组织架构按业务部门划分为三级：公司 → 部门 → 小组。这个结构决定了后续共享通讯录、Google Drive 权限和 Meet 许可证的分配方式。
第五步：历史邮件迁移
这是整个项目耗时最长的部分，也是最容易出岔子的地方。42 个人，3 年的 Gmail 数据，总量约 180GB。
我们使用 Google Workspace Migration for Gmail（GWMG）工具，授权源账号后批量迁移。需要注意：每个账号的迁移任务是独立的，需要分批提交，并且迁移期间不要修改源账号密码或启用 2FA，否则会中断任务。
第六步：MFA 推行
这是技术上最简单、推行上最复杂的一步。
我们的做法是：先在管理员账号强制开启，观察一周；再向技术和管理层推行，收集反馈；最后全员推行，同时提供一对一的设置支持（通过微信群）。从通知到全员完成，历时 9 天。
遇到的最大阻力是一位销售主管——手机号在国外，无法接收短信验证码。解决方案是切换为 Google Authenticator App，问题解决。
交付与后续
项目完成后交付的文档包括：DNS 配置记录（含修改前后对比）、账号清单（含部门和角色）、管理员操作手册（中文，适配 Google Admin 中国访问环境）、以及 DMARC 报告订阅设置说明。
客户在实施完成后 3 个月签订了月度运维托管合同，内容包括：入离职账号管理、月度安全报告、以及 Google Workspace 版本和许可证管理。