一、为什么必须用自定义域

新建 Microsoft 365 租户时你会得到一个<company>.onmicrosoft.com的"初始域"。这个域名：

• 不能删除；
• 用户 UPN/email 用它能跑，但不适合对外——客户、合作伙伴看到发件人是someone@contoso.onmicrosoft.com是不专业的；
• 与你的品牌、SPF/DKIM/DMARC 策略、DMARC 域名对齐等安全控制绑定不上；
• 后续几乎所有"以域为粒度"的合规、报告、安全策略都不能直接基于.onmicrosoft.com工作。

所以把自定义域（vanity domain，例如contoso.com）接进来并设为主域（Primary），是 M365 上线最关键的一步。

二、规划自定义域：别等迁移到一半才发现

1. 上线前的工程问卷（Module 4 推荐的清单）

1. 所有用户是否都已经迁到 M365？
2. 邮箱可用吗？数据迁移完成了吗？
3. 资源（站点、团队、邮箱、SharePoint、Power BI 工作区）是否都创建好了？
4. 权限是否到位？
5. 自定义域是否已成功接管？
6. Windows 10/11 设备是否已通过 Intune 注册？
7. 移动设备治理（MDM/MAM）策略是否已下发？
8. DNS 记录是否已全球发布？
9. Microsoft Entra Connect / Cloud Sync 是否配置正确？
10. 多因素认证（Passkey / Phishing-resistant MFA）是否已配置？
11. 入站/出站邮件策略（连接器、传输规则、Defender for Office 365）是否已就绪？
12. 组织配置文件是否完整？

2. 域名相关的法律问题（经常被忽略）

• 域名注册信息中域名所有者邮箱必须是你能控制的真实邮箱（建议单独一个 contact@yourcompany.com）；
• 不要让域名在注册商处于"客户冻结 / 注册商保留"状态，否则你后续做域名验证时会失败；
• 域 WHOIS 中的注册人邮箱未必是 Entra 验证时使用的邮箱——Entra 用的是TXT 记录，但注册商邮箱仍会影响转移/续费提醒。

三、DNS 区域规划：内/外部 DNS 的分工

1. 公共 DNS（公网权威 DNS）

• 由第三方 DNS 服务商（GoDaddy、Cloudflare、阿里云 DNS、Route 53、Azure DNS…）或自建权威 DNS 提供；
• 用于MX / Autodiscover CNAME / SPF / SRV / DKIM / DMARC等公网可解析的记录；
• 是用户从外网（家里、酒店、机场）连接 M365 的"地址簿"。

2. 内部 DNS（企业内网权威 DNS）

• 公司内部的 DNS 服务器（Windows DNS、Unbound、BIND、Pi-hole 等）；
• 解析intranet.contoso.com、*.corp.contoso.com、mail.contoso.com（Exchange 本地服务器名）；
• 在内网可通过Split-brain DNS把同一域名指向不同 IP（外网 vs 内网）。

2025 年趋势：很多客户开始把内/外 DNS统一用 Azure Private DNS + Azure DNS Public解决，自动化程度更高。

3. 混合 DNS 的两种模式

四、DNS 记录要求：每条记录都不能少

Module 4 给的清单是 2025 年的事实标准。下面按服务拆开来讲：

1. 域所有权验证（TXT）

Type: TXT Host: @ Value: MS=msXXXXXXXX （微软会自动生成） TTL: 3600

2. Exchange Online

⚠️DMARC 越来越重要：2024 年起 Google / Yahoo 已强制要求批量发件人 ≥5000 封/天的发件域必须发布 DMARC 策略；Microsoft Exchange Online 自身发件则更早就要求启用 DMARC。 生产环境应默认发布 DMARC（即便量小），以便后续能选择性收紧策略。

3. Microsoft Teams

4. 单点登录 / AD FS（如果仍用本地 AD FS）

2025 年的认证路径建议（按优先顺序）：

1. Microsoft Entra Cloud Auth（PHS / PTA） + Phishing-resistant MFA / Passkey — 推荐；
2. Microsoft Entra Federated Auth（ADFS）— 适用于合规明确要求本地身份验证、或复杂 SSO 场景；
3. 已弃用：Basic Auth、SAML 1.1、不合规的 MFA 方式。

也就是说，PTA 与 Cloud Sync 在现代混合部署中仍是合理选择，不是"应被淘汰"。重点是 MFA / Passkey / Conditional Access 这三件套，而不是认证路径本身。

5. SPF 的工程经验

• 不要超过 10 个 include：这是 RFC7208 早期版本的传统上限，超过后部分邮件系统（特别是老版本 Exchange on-prem）会直接拒信。RFC 反垃圾生态中这一数字已在实践中放宽，但遵守 10 个仍是最安全的工程准则；
• 每个第三方发件平台（Marketo、SendGrid、Mailchimp、自家 ERP）通常都需要一个include；
• 用-all（hard fail）而不是~all（soft fail）作为终态；
• 用 SPF Flattening 工具把多级 include 摊平成 IP 列表，降低 DNS 查询次数。

五、添加自定义域的官方流程

Module 4 提到的步骤精简如下：

1. 在 Microsoft 365 管理中心 →设置 → 域→添加域；
2. 输入域名（如contoso.com）；
3. 选择验证方式：TXT 记录（推荐）或 MX 记录；
4. 在域名注册商/公共 DNS 上添加微软提供的 TXT 记录；
5. 等待 DNS 全球传播（通常 5–30 分钟，TTL 决定）；
6. 验证通过后，微软让你选择"用途"：
   • Exchange Online / Microsoft 365 全套服务（推荐，自动加好 MX/Autodiscover/CNAME 等）；
   • 仅用于身份管理（Teams-only 租户场景）；
7. 设置为主域（Primary）→ 现有用户的 UPN 默认后缀会切换；
8. 重新分配用户的主要 SMTP 地址；
9. 完成 DNS 验证。

# 使用 Microsoft Graph 添加域 # 注意：实际流程是先创建 domain，再用单独请求设为主域 # Step 1: 添加 domain New-MgDomain -Id "contoso.com" # Step 2: 验证 domain（需在公共 DNS 添加验证 TXT） # 微软提供 TXT 值后，验证完成后才能设为默认 # Step 3: 设为默认（primary）域 $body = @{ isDefault = $true } # （实际更新走 Graph API：PATCH /domains/{id}，PowerShell 端通过 # Microsoft Graph SDK 的 Update-MgDomain 可达）

易踩坑：把contoso.com设为主域后，onmicrosoft.com仍要保留为备用 alias，以防 OAuth 应用、PowerShell 会话、Graph 调用仍然引用旧域。

六、客户端连接：从 RPC 到 MAPI over HTTP

1. Outlook 客户端连接演进

MAPI over HTTP 的好处：

• 全部走 HTTPS（443），少 1 次防火墙穿透；
• 不需要 RPC 端口动态协商；
• 与零信任网络（ZTNA）兼容；
• 与 Microsoft Defender for Cloud Apps 的会话控制兼容；
• 与 Intune / Conditional Access 协同更精确（按 app control 策略）。

2. 自动配置：Autodiscover

Outlook / Teams / OneDrive / Skype for Business 启动时都会做一次 Autodiscover：

1. 客户端拿到用户邮箱alice@contoso.com；
2. 尝试解析https://contoso.com/autodiscover/autodiscover.xml→ 失败（CNAME 不在）；
3. 尝试https://autodiscover.contoso.com/autodiscover/autodiscover.xml→CNAME 指向 autodiscover.outlook.com→ 成功；
4. Exchange Online 返回 MAPI over HTTP 端点 + 用户邮箱信息；
5. Outlook 与 MAPI endpoint 建立长连接。

这是为什么autodiscover.contoso.com 的 CNAME 几乎不能丢——丢了，Outlook 就退化到人工配置，体验直接崩。

3. 新版 Outlook for Windows（基于 Outlook "Monarch"）

2024 年 GA、2025 年默认推送的New Outlook for Windows：

• 客户端是 WebView2 进程；
• 底层连接大量走Microsoft Graph API（与 MAPI over HTTP 并行）；
• 同样依赖 Autodiscover，但有些配置项改为读取 Graph profile；
• 关键限制：必须保持 Exchange Online 邮箱启用——纯本地 Exchange 邮箱、仅限 Gmail / IMAP / POP 第三方账户、Gov/GCC High 之外的某些合规租户暂不兼容，需要退回 Classic Outlook。

部署时的决策点：是否所有客户端都已迁到 Exchange Online？是否有大量"纯本地邮箱用户"？这些人群是否需要回退到 Classic Outlook？这些必须先于"切换到 New Outlook"动作前问清楚。

七、客户端连通性排障工具

1. Microsoft Remote Connectivity Analyzer（RCA）

• 入口：https://testconnectivity.microsoft.com/；
• 从微软数据中心发测试——能验证 DNS、Autodiscover、Exchange MAPI、Outlook Anywhere、Teams Federation 等；
• 推荐测试集：
  • Exchange Online → Outlook Autodiscover
  • Exchange Online → SMTP
  • Microsoft Teams → Sign-in
  • Microsoft Lync/Skype → Sign-in
  • SharePoint Online → Sign-in

2. Microsoft Support and Recovery Assistant（SaRA）

• 安装到客户端机器上的应用；
• 跑 Outlook、OneDrive、Teams、Office 应用的诊断；
• 能自动修复常见的 Profile、缓存、激活问题；
• 2025 年的新版已经把Loop / Copilot 加载项也纳入诊断范围。

3. 排障顺序的"5 分钟法则"

1. DNS 验证：nslookup autodiscover.contoso.com+nslookup -type=mx contoso.com看是否全球生效；
2. RCA 测试：跑 Outlook Autodiscover；
3. SaRA 跑客户端：拿到 profile 健康报告；
4. Conditional Access / Intune 检查：是否对相关 App 启用了控制；
5. 客户端日志：Outlook 按Ctrl+右键托盘图标 → Test Email AutoConfiguration / Test Autodiscover。

八、客户端连接 Checklist

• 域所有权 TXT 已验证；
• MX 指向*.mail.protection.outlook.com，优先级 0；
• Autodiscover CNAME：autodiscover.contoso.com → autodiscover.outlook.com；
• SPF 包含spf.protection.outlook.com，且总数 ≤10 个 include；
• DKIM（selector1 + selector2）双 CNAME 已配；
• DMARC 策略至少为p=quarantine，理想为p=reject；
• Teams SRV 记录：_sip._tls指向sipfed.online.lync.com；
• 已用 Microsoft 365 管理中心的"域连接性检查"工具验证；
• 用 RCA 跑过一次 Autodiscover 测试；
• 用 SaRA 在至少一台客户端机器上跑过完整诊断；
• 已规划"Classic Outlook → New Outlook"迁移窗口；
• 已制定"Autodiscover 失败 → 兜底"的人工配置文档。

九、几个生产环境的真实坑

1. Autodiscover 解析到 127.0.0.1 / 内网 IP：通常是 AD 域的"重定向到本地"行为，外部 Outlook 看到的是公司内网 IP，连接失败。解决方案：在公共 DNS 中显式写死autodiscover.contoso.com的 CNAME，让客户端绕开内网 DNS。

2. SPF 超过 10 个 include：典型症状是部分邮件被 Yahoo、AOL 直接拒收。解决方案：使用第三方 SPF Flattening 服务（自动把多级 include 合并为 IP 列表）。

3. DKIM 启用但 selector 写错：常见于把selector1._domainkey.contoso.com写成selector1._domainkey.contoso.onmicrosoft.com。验证：用nslookup -type=cname selector1._domainkey.contoso.com必须指向selector1-contoso-com._domainkey.contoso.onmicrosoft.com。

4. DMARC 策略过早 p=reject：上线初期没有 DKIM/SPF 调整稳定前就 reject 会导致自家邮件被丢。建议先用p=none; rua=mailto:dmarc@contoso.com观察 2–4 周，再升级到 quarantine，最终 reject。

5. 客户端走 IPv6 失败：纯 IPv6 网络（如部分 5G CPE）需要 Microsoft 365 端支持 IPv6。2024 年起 Microsoft 365 的多数服务已经支持 IPv6，但仍建议在 RCA 中显式跑一次 IPv6 测试。

6. Conditional Access 把旧版 Outlook 客户端拦了：默认 CA 策略里"Require approved client app or app protection policy"会让老 Outlook（未启用 ADAL / Modern Auth）失去访问。解决方案：

   • 优先推动客户端升级到 Modern Auth 兼容版本（Outlook 2013+ 默认开启 Modern Auth）；
   • 推广Intune App Protection（WIP 策略）而非依赖"approved client apps"白名单——后者已被微软逐步弃用；
   • 对确需保留的旧客户端，使用Outlook Mobile Only / Exchange ActiveSync 专项 CA 策略作为兜底，并辅以"不可升级设备"的合规例外流程。

十、收尾：客户端连接只是表象，治理才是长期战

DNS 记录配齐 ≠ 客户端连通性无忧。本质上你需要持续监控：

• DMARC 报告聚合：用第三方工具（如 Valimail、Postmark DMARC、MXToolbox）解析 rua 报告，识别"未授权发件 IP"；
• Autodiscover 健康度：通过 Microsoft 365 Admin Center 内置诊断（已逐步取代独立 RCA）每月一次批量测试；
• 客户端版本分布：通过 Intune / Configuration Manager 报表，强制升级到新版 Outlook / Teams 2.x；
• BitLocker + Intune 合规：确保所有 M365 客户端满足 Conditional Access 的设备合规要求；
• Modern Authentication 强制：Microsoft 已自 2022 年 10 月起在 Exchange Online 全租户禁用 Basic Auth，但仍需要持续监控是否还有 Legacy 客户端（未启用 ADAL）在用；
• DNS 记录漂移检测：域名 TTL 变化、SPF include 增减、TXT 验证过期都要自动化监控。

💡Backup 与 SAM 现状补充：从 2024 年起，Microsoft 365 Backup已从 SharePoint Advanced Management 中独立出来，成为独立的 SKU 与产品线（提供 Exchange / OneDrive / SharePoint 的企业级备份恢复）。SAM 与 Backup 是并列产品，SAM 侧重"治理与访问控制"，Backup 侧重"数据保护与恢复"，采购与计费独立。

十一、与 Operational Excellence 的连接

把自定义域与客户端连接纳入Operational Excellence：

• Daily：Service Health 中 Exchange / Teams / SharePoint / OneDrive 的服务事件订阅到 Teams 频道；
• Weekly：DMARC rua 报告聚合 → 识别"未授权发件 IP"；
• Monthly：Autodiscover 健康度测试（RCA / Admin Center 内置诊断）；
• Quarterly：DNS 记录全量审计（SPF include 数量、TXT 验证、DMARC 策略升级）；
• Yearly：备份恢复演练（Microsoft 365 Backup）。

十二、给实施工程师的最终总结

自定义域 + DNS + 客户端连接，是 M365 的"最后一公里"，但不是"最后一件事"。

真正决定稳定性的，是把以下三件事持续做下去：

1. DMARC 闭环：从p=none观察到p=quarantine再到p=reject，大约需要 4–8 周；
2. 客户端版本治理：经典 Outlook / 新版 Outlook / Outlook Mobile / OWA 四态并存是常态，Intune + Conditional Access 才是治理主战场；
3. DNS 漂移监控：DNS 是 M365 最容易"默默坏掉"的一环，必须有自动化巡检。

详细 Tenant Health Automation 节奏见系列博文 1 第十一节。

系列小结

本系列按 MS-102 Learning Path 1 展开的四篇博文覆盖了 Tenant 配置的全貌：

1. 租户初始化——把地基打好（Tenant Landing Zone + ADR）；
2. 用户与来宾——把人和身份管理好（Identity 治理架构 + Cross-Tenant Access）；
3. 组与动态成员——把权限和协作落到组（M365 Groups + 动态组 + 命名策略）；
4. 自定义域与客户端连接——把 M365 与世界连起来（DNS + Autodiscover + MAPI over HTTP）。

后续本系列会先写Microsoft 365 Tenant Day-0 安全基线设计（Tenant Foundation 之后的第一根承重柱），再进入：

• Exchange Online 邮件流与 Defender for Office 365；
• Microsoft Teams 治理与通话；
• SharePoint 高级管理（SAM）；
• Microsoft Purview 合规与 DLP。

真正把 M365 用好，靠的不是任何一个单一开关，而是这几层的协同：身份 + 策略 + 治理 + 自动化。把这四件事坚持半年以上，你会发现：

• 安全事件响应时间从"几小时"降到"几分钟"；
• 用户对 M365 的抱怨下降 80%；
• 跨部门协作、跨地域、跨组织的扩展不再痛苦；
• 合规审计从"临阵磨枪"变成"日常运转"。

工具与脚本建议：

• 每周一次Invoke-MgGraphRequest拉一次 DMARC + SPF + DKIM + Autodiscover 健康度；
• 把 RCA 测试写成 CI 流水线作业，部署或 DNS 变更后自动跑；
• 用Power BI + Microsoft Entra Workload Identities把所有健康度指标做成仪表板，挂在 IT 战情室大屏。

📌DNSSEC 边界说明：Microsoft 365 自有域（onmicrosoft.com）由微软负责 DNSSEC，但企业自定义域的 DNSSEC 是否启用取决于域名注册商与权威 DNS 服务商——这不是租户管理员能配置的项。因此未列入 Tenant Health Automation 巡检节奏，而是域名治理的独立线。