[ 平台指南 ]
Exchange Server DKIM ：识别执行出站签名的组件
查找 Exchange Server 的实际出站签名者，而不是将Exchange Online命令应用到错误的系统。
由EmailAuth研究团队提供 · 3 分钟阅读
[ 要点 ]
- 找到消息转换后的实际签名组件。
- 云 cmdlet 文档未建立本地功能。
- 在采用运输代理之前需要当前的兼容性证据。
[ 外卖 ]
在采用运输代理之前需要当前的兼容性证据。
[ 按角色 ]
这对您意味着什么
选择您的角色以执行后续实际步骤。
IT/邮件管理员
保留操作证据
追踪每个连接器和转换。在最终出口后验证接收者的签名，包括中继和故障转移路径。
后续步骤
- 追踪每个连接器和转换。
- 在最终出口后验证接收者的签名，包括中继和故障转移路径。
- 将故障转移连接器纳入验收测试中。
CISO / SecOps
检查信任边界
在安装传输组件之前需要支持和回滚证据。保护签名密钥并保留域授权记录。
后续步骤
- 在安装传输组件之前需要支持和回滚证据。
- 保护签名密钥并保留域授权记录。
- 检查运输代理升级风险。
创始人/非技术人员
拥有业务决策权
资助受支持的签名边界及其维护，而不仅仅是DNS任务。在 Exchange 和网关团队中明确所有权。
后续步骤
- 资助受支持的签名边界及其维护，而不仅仅是DNS任务。
- 在 Exchange 和网关团队中明确所有权。
- 需要受支持的 Exchange 构建计划。
[ 常见问题解答 ]
常见问题
New-DkimSigningConfig 可以配置我的本地服务器吗？
微软将其记录为仅云服务。确定实际的签名组件，而不是假设 cmdlet 适用于 Exchange Server。
DKIM DNS记录是否会导致 Exchange 签名？
否。已配置的签名者必须创建签名； DNS提供相应的公开验证材料。
我应该安装社区签名代理吗？
仅在评估您的确切版本的当前兼容性、维护和恢复之后。已检查的 README 保留了 2023 年 5 月要求某人继续开发的请求；其历史兼容性列表不是当前的支持承诺。
免责声明应该在哪里添加？
首选这样的设计：在最终对齐的签名之前进行所需的转换。用收到的样本证明实际行为。
为什么要单独测试应用程序中继？
它可以使用不同的连接器或出口并绕过普通邮箱消息使用的签名者。
什么是安全轮换顺序？
发布新的公共材料，激活并验证新的签名者，然后在检查活动和正在进行的依赖关系后停用旧材料。
回滚必须保留什么？
交付可用性、连接器限制和已知的签名路径。在引入代理或路由更改之前保存配置并测试恢复。
[ 来源 ]
来源
- 微软新-DkimSigningConfig
部分 描述和仅限云服务的适用性
- Microsoft：为自定义域配置DKIM
部分 配置出站消息的DKIM签名 · 验证DKIM签名
- Exchange DKIM Signer 项目文档
部分 自述文件：安装、配置和支持的版本
- RFC 6376: DKIM
部分 §3.5 DKIM-Signature标头字段 · §3.6 密钥管理
- RFC 9989: DMARC
部分 §4.4 标识符对齐说明 · §5 DMARC政策
[ 词汇表 ]
词汇表
- 一致的身份验证
- 满足与可见发件人域的适用关系的传递SPF或DKIM身份。
- 权威DNS
- DNS服务负责发布区域记录。
- 签约边界
- 出站路由中在预期消息转换后应用签名的组件和点。
企业出处
为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。
传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中，手动监督意味着延迟执行、配置漂移和不受监控的影子域。
EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject，保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准，以及人机交互审核能力。
SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密