[ DNS 提供商指南 ]
在123 Reg：配置和验证中发布电子邮件身份验证记录
在 123 Reg 中发布正确的TXT或选择器记录，然后区分权威DNS成功与实际的发件人身份验证。
由EmailAuth研究团队提供 · 4 分钟阅读
[ 要点 ]
- 仅在权威DNS服务处发布。
- 保留发件人的确切记录类型和选择器所有者。
- DNS发布和发送者激活需要单独的证明。
[ 外卖 ]
DNS发布和发送者激活需要单独的证明。
[ 按角色 ]
这对您意味着什么
选择您的角色以执行后续实际步骤。
IT/邮件管理员
验证实际路线
保留前后记录集并从每个受影响的发送应用程序捕获一条消息。
后续步骤
- 将生成的所有者与每个权威服务器进行比较。
- 发布后测试来自每个受影响应用程序的一条消息。
- 发送域或 DNS 提供商更改后重新测试。
CISO / SecOps
控制授权边界
批准添加的精确信任并保留针对选择器或策略冲突的恢复计划。
后续步骤
- 拒绝计划外的名称服务器迁移。
- 记录必须保留哪些活动选择器和报告目标。
- 保留批准的恢复和供应商退役决定。
创始人/非技术人员
拥有发送决定权
为所有发件人分配一个DNS更改所有者，以便营销请求无法默默地替换员工邮件授权。
后续步骤
- 命名共享SPF策略的每个服务的所有者。
- 批准特定的DNS编辑和后备窗口。
- 启动前需要受控消息接受记录。
[ 常见问题解答 ]
常见问题
我可以添加第二条SPF TXT记录吗？
不是同一个SPF所有者。将合法授权合并到一项经过评估的策略中。
为什么公共DNS中没有保存的记录？
在指责缓存之前检查权限、最终所有者名称、委托以及记录是否实际保存。
dig 输出中的引号是否有多余字符？
未必。 DNS工具显示带引号的TXT字符串；检查重建的值而不是复制表示标点符号。
发布DKIM是否会开启签名？
不可以。发送应用程序必须使用匹配的私钥和选择器进行签名。
变更什么时候完成？
当权威发布、发送者激活和受控接收消息对齐检查都满足变更计划时。
[ 来源 ]
来源
- 123 Reg TXT出版
部分 TXT设置和权威名称服务器先决条件
- 123 注册DKIM出版
部分 TXT DKIM发布工作流程
- RFC 7208 SPF
部分 §3.2 多个DNS记录 · §4.6.4 DNS查找限制
- RFC 6376 DKIM
部分 §3.5 DKIM-Signature头字段 · §3.6 密钥管理和表示 · §6 验证者操作
- RFC 9989 DMARC
部分 §4.4 标识符对齐解释 · §5.3 邮件接收器操作
- RFC 1034 DNS概念
部分 §3.6.2 别名和规范名称 · §4.2 数据库如何划分区域
- RFC 2308 DNS负缓存
部分 §5 缓存否定答案
[ 词汇表 ]
词汇表
- 结盟
- 传递身份验证域与DMARC的可见发件人域之间所需的关系。
- 选择器
- 与签名域一起使用的DKIM标签在DNS中查找其公钥。
- 权威DNS
- 负责发布相关区域记录的名称服务器服务。
- Return-Path
- SMTP反向路径的接收消息跟踪在调查信封身份时很有用。
企业出处
为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。
传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中，手动监督意味着延迟执行、配置漂移和不受监控的影子域。
EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject，保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准，以及人机交互审核能力。
SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密