[ DNS 提供商指南 ]
在Azure DNS中发布SPF DKIM和DMARC记录
使用权威的公共Azure DNS区域，将完整所有者名称映射到相关记录集名称，保留TXT边界并验证生成的消息身份验证。
由EmailAuth研究团队提供 · 6 分钟阅读
[ 要点 ]
- 编辑前请验证活动服务和权威DNS 。
- 保留记录类型、所有者名称和现有授权服务。
- 分别验证公开答案和实际对齐的邮件。
[ 外卖 ]
分别验证公开答案和实际对齐的邮件。
[ 按角色 ]
这对您意味着什么
选择您的角色以执行后续实际步骤。
IT/邮件管理员
保留名称和记录边界
相对名称、记录集和TXT字符串是不同的概念。
后续步骤
- 将完整所有者映射到选定的公共区域。
- 保留每组中不相关的记录。
- 将权威答案与发布的值进行比较。
CISO / SecOps
保持政策决定的明确性
发布记录并不授权削弱域名保护。
后续步骤
- 查看DMARC更改并报告目标。
- 检查委托的命名空间所有权。
- 在关闭之前需要实际的消息对齐。
创始人/非技术人员
托管与发送分开
即使一项活动促使DNS更改，也可能会影响多项服务。
后续步骤
- 识别真正的发送提供商。
- 批准范围狭窄的记录。
- 在推出之前需要恢复所有者。
[ 常见问题解答 ]
常见问题
Azure DNS是否发送我的电子邮件或对我的电子邮件进行 DKIM 签名？
不会。它会公布接收者使用的记录。实际的发送服务提供身份验证配置并执行签名。
DNS区域和记录概述 |微软学习 使用Azure DNS管理DNS记录集和记录 |微软学习 教程：在Azure DNS中托管域 |微软学习 快速入门：创建公共DNS区域并记录 - Azure 门户 - Azure DNS |微软学习 https://www.rfc-editor.org/rfc/rfc7208.html https://www.rfc-editor.org/rfc/rfc6376.html RFC 9989 ：基于域的消息身份验证、报告和一致性 ( DMARC )
为什么我的 Azure 区域中的记录没有公开显示？
检查公共委托是否指向该区域分配的名称服务器。区域可以在不具有公共领域权威的情况下存在。
DNS区域和记录概述 |微软学习 使用Azure DNS管理DNS记录集和记录 |微软学习 教程：在Azure DNS中托管域 |微软学习 快速入门：创建公共DNS区域并记录 - Azure 门户 - Azure DNS |微软学习 https://www.rfc-editor.org/rfc/rfc7208.html https://www.rfc-editor.org/rfc/rfc6376.html RFC 9989 ：基于域的消息身份验证、报告和一致性 ( DMARC )
我应该为根域DMARC记录输入什么名称？
在example.com的公共区域中，相对所有者是_dmarc 。先确认选择的区域；子区域会更改生成的全名。
DNS区域和记录概述 |微软学习 使用Azure DNS管理DNS记录集和记录 |微软学习 教程：在Azure DNS中托管域 |微软学习 快速入门：创建公共DNS区域并记录 - Azure 门户 - Azure DNS |微软学习 https://www.rfc-editor.org/rfc/rfc7208.html https://www.rfc-editor.org/rfc/rfc6376.html RFC 9989 ：基于域的消息身份验证、报告和一致性 ( DMARC )
我应该使用SPF记录类型吗？
否。将SPF发布为TXT ，在评估的所有者处保留一项适用的SPF策略并保留不相关的TXT记录。
DNS区域和记录概述 |微软学习 使用Azure DNS管理DNS记录集和记录 |微软学习 教程：在Azure DNS中托管域 |微软学习 快速入门：创建公共DNS区域并记录 - Azure 门户 - Azure DNS |微软学习 https://www.rfc-editor.org/rfc/rfc7208.html https://www.rfc-editor.org/rfc/rfc6376.html RFC 9989 ：基于域的消息身份验证、报告和一致性 ( DMARC )
我应该如何输入长DKIM TXT值？
输入提供商的完整值作为一项逻辑记录。 Azure的门户可以对长字符串进行分段；不要将这些段变成单独的TXT记录。
DNS区域和记录概述 |微软学习 使用Azure DNS管理DNS记录集和记录 |微软学习 教程：在Azure DNS中托管域 |微软学习 快速入门：创建公共DNS区域并记录 - Azure 门户 - Azure DNS |微软学习 https://www.rfc-editor.org/rfc/rfc7208.html https://www.rfc-editor.org/rfc/rfc6376.html RFC 9989 ：基于域的消息身份验证、报告和一致性 ( DMARC )
DKIM CNAME是否可以与现有TXT记录共享所有者？
CNAME不能与该所有者的其他普通记录集共存。解决与服务和DNS所有者的冲突，而不是默默删除现有数据。
DNS区域和记录概述 |微软学习 使用Azure DNS管理DNS记录集和记录 |微软学习 教程：在Azure DNS中托管域 |微软学习 快速入门：创建公共DNS区域并记录 - Azure 门户 - Azure DNS |微软学习 https://www.rfc-editor.org/rfc/rfc7208.html https://www.rfc-editor.org/rfc/rfc6376.html RFC 9989 ：基于域的消息身份验证、报告和一致性 ( DMARC )
保存的记录集是否足以结束更改？
否。验证权威的公开答案并测试来自实际发件人的消息以进行身份验证和对齐。
DNS区域和记录概述 |微软学习 使用Azure DNS管理DNS记录集和记录 |微软学习 教程：在Azure DNS中托管域 |微软学习 快速入门：创建公共DNS区域并记录 - Azure 门户 - Azure DNS |微软学习 https://www.rfc-editor.org/rfc/rfc7208.html https://www.rfc-editor.org/rfc/rfc6376.html RFC 9989 ：基于域的消息身份验证、报告和一致性 ( DMARC )
这位候选人还缺少什么证据？
仍然需要实际的 Azure 演练、权威的前后查询、独立检查的收到消息以及 SME 人工批准。
DNS区域和记录概述 |微软学习 使用Azure DNS管理DNS记录集和记录 |微软学习 教程：在Azure DNS中托管域 |微软学习 快速入门：创建公共DNS区域并记录 - Azure 门户 - Azure DNS |微软学习 https://www.rfc-editor.org/rfc/rfc7208.html https://www.rfc-editor.org/rfc/rfc6376.html RFC 9989 ：基于域的消息身份验证、报告和一致性 ( DMARC )
[ 来源 ]
来源
- DNS区域和记录概述 |微软学习
部分 记录姓名 55–58； CNAME97–103； TXT129–135；埃塔格
- 使用Azure DNS管理DNS记录集和记录 |微软学习
部分 记录集40–42；编辑/应用47–59
- 教程：在Azure DNS中托管域 |微软学习
部分 检索名称服务器89–95；代表96–100
- 快速入门：创建公共DNS区域并记录 - Azure 门户 - Azure DNS |微软学习
部分 公共区域示例31-36；创建DNS记录
- https://www.rfc-editor.org/rfc/rfc7208.html
部分 §3.2; 3.3; 4.6.4
- https://www.rfc-editor.org/rfc/rfc6376.html
部分 §3.5; 3.6.2; 6.1
- RFC 9989 ：基于域的消息身份验证、报告和一致性 ( DMARC )
部分 §4.4; 4.7; 4.10; 5
[ 词汇表 ]
词汇表
- 相对记录名称
- 在Azure DNS区域中输入的名称，不重复区域后缀。
- 记录集
- 一个所有者名称的一种类型的记录，在Azure DNS中一起管理。
- TXT字符串
- 逻辑TXT记录内的一个段，与单独的记录不同。
- 权威域名服务器
- 负责提供DNS区域权威答案的服务器。
- TTL
- 与DNS记录集关联的缓存生命周期。
企业出处
为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。
传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中，手动监督意味着延迟执行、配置漂移和不受监控的影子域。
EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject，保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准，以及人机交互审核能力。
SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密