先区分邮箱地址格式与邮件可信度
企业邮箱命名解决“员工身份是否易识别”，SPF、DKIM、DMARC 解决“收件方如何判别发信来源”。两者应并行治理。建议为员工制定 [email protected] 或 [email protected] 规则，并为同名员工、部门共享账号和离职账号准备例外流程。邮箱地址格式本身不提供反钓鱼保证。
地址命名与账号生命周期
- 个人邮箱尽量唯一、稳定，避免将身份证号、生日等个人敏感信息直接编入用户名。
- 销售、支持等公共收件箱使用部门别名与受控访问，记录责任人与转发权限。
- 员工离职时依权限模型撤销会话、回收转发、设置合法的交接期，避免一律永久自动转发私人邮件。
SPF、DKIM 与 DMARC 的设置顺序
先盘点所有实际发信系统，再按邮件服务商提供的值创建 SPF TXT 记录，避免同时发布多个相互冲突的 SPF 记录。由提供商生成 DKIM 密钥和选择器并部署对应 DNS 记录。初期 DMARC 可按组织风险使用监测策略，例如 v=DMARC1; p=none; rua=mailto:[email protected]（邮箱应是已建立且有权接收报告的地址），分析合法流量的对齐结果后再逐步评估 quarantine/reject；不要未经清点就直接拒收全部邮件。
上线验收清单
分别向外部主流邮箱发测试邮件，检查邮件原始标头中的 SPF/DKIM/DMARC 结果，确认域名对齐；同时测试自动回复、别名、共享账号、移动客户端与邮箱恢复。只修改 DNS 而不核对实际发信平台，无法保证邮件投递成功。
DNS 记录与验收示例
以下仅为占位模板，provider.example 和收件邮箱须替换为实际供应商认可的配置；不要直接复制到生产 DNS。
example.com. TXT "v=spf1 include:_spf.provider.example ~all"
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY"
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"SPF 每个域名只能有一条有效 SPF TXT 政策，多个发信系统需要合并机制并注意 DNS 查询次数限制。DMARC 除 SPF/DKIM 通过外，还关注与 From 域名的对齐；某一系统邮件能发出并不意味着它通过 DMARC。持续收集报告、识别外包发信服务后，再决定是否逐步提高政策强度。
相关教程与进一步检查
若需要继续处理实际环境中的关联问题，可阅读HTTPS 证书验证与续期；SAN/通配符证书覆盖范围可帮助补充不同的选型或验收视角。两者属于独立问题，按当前环境自行核对适用版本。
