将邮箱迁移与身份验证分开
Proton Mail （以前通常称为 ProtonMail）支持付费计划的自定义域地址。它是 自定义域指南 将域验证、地址创建、 MX更改和身份验证分开。将这些计划为不同的验收项目。在新邮箱收到邮件并不能证明外发邮件具有预期的签名，并且 DKIM 检查并不能证明迁移后每个企业地址都存在。
从地址清单开始：个人用户、别名、共享业务目的地、自动发件人和回复地址。识别使用同一域而不通过 Proton 发送的任何服务。指派一名人员负责邮箱切换，另一名人员负责在可行的情况下检查DNS 。记录现有的MX和身份验证记录、批准的更改窗口以及可以停止割接的决策者。
Proton 特别建议在搬家之前创建相应的地址 MX记录。这很重要，因为一旦入站路由发生更改，丢失地址的邮件将不会继续到达先前的服务。使用 迁移顺序 对于帐户，并在宣布接收方完成之前使用受控消息验证关键目的地。
记录确切的域名和发布的值
在 Proton 的域名设置中打开所需的域名，并保留为其显示的身份验证说明。区分域名所有权验证记录 SPF、 DKIM和 DMARC。他们回答不同的问题，并且应该有不同的证据字段。切勿用其他组织发布的记录替换帐户中的值。
DNS管理员应记录每个条目的完整所有者名称、记录类型和预期值。将这些与DNS编辑器的后缀处理进行比较，然后检查已发布的答案。标签在控制面板中可能在视觉上是正确的，但显示在错误的完全限定名称中。保持不相关 TXT记录 并在进行更改之前记录建议的DKIM所有者的任何现有使用情况。
如果该域已被 CRM、网站或计费系统使用，请立即列出这些发件人。将员工邮件转移到 Proton 并不能验证单独应用程序的直接投递。该应用程序的批准路径必须有自己的有效身份验证，或者必须实施和测试明确设计的提交路径。将不确定的发件人视为库存缺口，而不是立即削弱域策略的理由。
保留一项连贯的SPF政策
质子的 反欺骗文档 将include:_spf.protonmail.ch标识为其SPF授权，并解释将其合并到现有策略中。使用帐户的推荐记录和域的完整发件人库存来准备最终值。请勿在迁移过程中为同一所有者发布第二个策略或放弃对其他合法路由的授权。
评估完整的政策 SPF的 DNS 查找规则。慎重地选择最终限定符，而不是将复制的示例视为组织范围内的策略决策。 SPF结果是认证证据；接收系统做出自己的处理决定。保留先前的策略可用于已批准的恢复更改，并注意缓存版本何时可能仍在使用中。
保留完整的DKIM轮换设置
质子使用三个 CNAME 自动DKIM轮换的记录。它是 域认证指南 指示客户保留所有三个，与向导完全匹配，并在传出自定义域签名开始之前等待检测。一个明显闲置的 选择器 稍后轮换可能需要。不要删除它，因为单个测试消息仅使用一个签名选择器。
如果验证失败，则将每个所有者和目标角色进行比较。质子的 CNAME故障排除指南 将不正确的值、注册商对尾随期间的处理以及旧的手动管理的TXT记录识别为可能的问题。在删除任何内容之前调查实际冲突。不同选择器处的TXT记录可能属于另一个合法发件人，并且不会自动过时。
如果帐户要从 Proton 旧的手动密钥安排转移，请仔细计划记录的过渡。当旧的TXT记录被删除时，Proton 会警告签名中断。提前准备所有替换值和受控测试，协调更改窗口，并及时发布所需的替换值。这并不建议删除区域中的每个DKIM TXT记录。
测试人员邮件和申请提交分开
通过组织使用的路由从代表性自定义域地址发送新邮件。记录客户端或应用程序、发件人地址、时间和消息 ID。在受控的外部接收器处，捕获受信任的SPF 、 DKIM和DMARC结果、 SMTP 返回路径 以及DKIM d= 和 s= 值。签名的域和选择器标识由以下描述的公钥查找 RFC 6376.
对于设备或业务应用程序，Proton 为具有自定义域地址的付费计划提供了单独的 SMTP 提交功能。它是 SMTP指南 使用特定于地址的SMTP令牌，而不是普通邮箱密码，并解释 SMTP 提交的邮件未进行端到端加密。在配置应用程序之前，请确认功能资格和授权地址。凭证创建和持久访问需要自己的安全批准；证据工作簿中不应出现任何标记。
即使员工网络邮件测试通过，也为每个申请记录单独的结果。成功登录提交服务器既不能证明最终可见的发送者，也不能证明接收者的身份验证结果。如果打印机或 CRM 在提交之前出现故障，请在诊断DKIM之前解决该连接问题。如果提交成功，则按照结果消息发送给受控接收者。
根据观察到的路由设置DMARC策略
与其所有者一起查看域的现有DMARC策略和报告目标。保留既定政策，除非需要单独批准的变更。对齐的通过SPF或DKIM结果可以满足DMARC ，如中定义 RFC 9989。检查实际情况 结盟 模式而不是假设每个相关子域都符合条件。
在加强执法之前，请考虑企业所依赖的直接申请、转发安排和邮件列表的使用。监测期应该有一个所有者和一个审查结果，而不是成为调查的无限期替代品。 汇总报告 可以指导发现，但它们不会替换特定于路由的标头或证明每个收件人的收件箱位置。
Proton Mail接受工作表
为每个员工邮件或申请路径创建一行：
- 域名、租户所有者和地址清单修订：____。
- 域验证、地址创建和MX切换证据：____。
- 在SPF审核中保留的现有发件人：____。
- 已颁发DKIM CNAME集和所有三个已发布所有者检查：____。
- 旧版手动密钥冲突和批准的过渡计划（如果有）：____。
- 路线、客户端或设备和授权发件人地址：____。
- 应用程序SMTP访问批准参考，不包括机密：____。
- 消息 ID、UTC 时间、 Return-Path和DKIM d=/s=: ____。
- 可信的身份验证结果、一致性和业务收据检查：____。
- 恢复所有者、未解决的异常和审核决定：____。
DNS清理后的虚构诊断
仅虚构示例：Juniper Accounts 删除了两个 Proton CNAME，因为其最新消息使用了第三个选择器。后来，身份验证变得不一致。邮件管理员将该区域与完整的已发布集进行比较，而不是添加新的根域SPF策略。通过批准的更改流程恢复丢失的 CNAME，重新检查 Proton 的状态，并通过新消息确定签名是否已恢复。
此示例说明了为什么旋转依赖项属于清单。这不是观察到的 Proton 事件，也没有访问任何瞻博网络邮箱或DNS区域。
保留下一次更改的证据
将发布的记录、公共DNS检查和经过编辑的收到标头保存在一起。 DNS 主机更改、地址迁移、密钥转换工作或新应用程序路由后重新验证。本文尚未完成真实账户检查、记录发布、受控发送、渲染视觉审核、人工 SME 审批和发布。即使文件程序已完成，这些大门仍然悬而未决。
将发送访问权限与收件箱访问权限分开
Proton 将SMTP提交描述为仅发送；通过第三方桌面客户端接收是一个单独的 Bridge 工作流程。成功的应用程序提交测试不会建立收件箱同步。为每个应用程序保留一个独特的批准令牌，以便撤销的设备不会不必要地中断其他客户端。这是一个访问设计建议；未创建或配置任何凭据。
将消息接受与策略推出分开
通过对齐的SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989 第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。