[ 寄送服务指南 ]
验证通过 34SP 发送的电子邮件：配置和验证
在支持的托管上激活 34SP DKIM ，验证任何自动DNS更改，并保护现有SPF授权。
由EmailAuth研究团队提供 · 4 分钟阅读
[ 要点 ]
- 将记录的托管范围与 Private SMTP分开。
- 检查自动DNS更改而不是假设安全合并。
- 面板状态不会建立传递对齐消息。
[ 外卖 ]
面板状态不会建立传递对齐消息。
[ 按角色 ]
这对您意味着什么
选择您的角色以执行后续实际步骤。
IT/邮件管理员
验证实际路线
检查自动DNS写入并将真实的出站标头与启用的站点进行比较。
后续步骤
- 使用添加SPF记录之前捕获DNS 。
- 将启用DKIM输出与从支持的路由接收到的签名进行比较。
- 发送域或 DNS 提供商更改后重新测试。
CISO / SecOps
控制授权边界
需要对任何域范围内的策略更改进行范围内的回滚和单独批准。
后续步骤
- 将专用SMTP保留在此过程之外。
- 批准回滚仅限于实际更改的记录和设置。
- 保留批准的恢复和供应商退役决定。
创始人/非技术人员
拥有发送决定权
在接受更改之前，请确认哪个托管产品拥有关键电子邮件。
后续步骤
- 确认托管计划而不是仅仅依赖34SP品牌。
- 安排更改远离发送关键通知。
- 启动前需要受控消息接受记录。
[ 常见问题解答 ]
常见问题
额外的验证TXT是否会破坏SPF ？
不仅仅是因为它是TXT 。问题是同一所有者选择了多个v=spf1策略。
为什么启用的DKIM仍然失败？
可能的原因包括缺少公共DNS 、选择器错误、密钥不匹配或出站路由不同。使用收到的消息来区分它们。
我应该将密钥复制到每个域中吗？
否。使用每个域生成的配置并验证签名身份。
SPF更改后必须重新测试哪些内容？
使用该SPF所有者的所有合法服务，而不仅仅是 34SP 消息。
[ 来源 ]
来源
- 34SP DKIM签名
部分 适用于 · 启用DKIM签名
- 34SP SPF出版
部分 如何创建SPF记录
- 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 2308 DNS负缓存
部分 §5 缓存否定答案
[ 词汇表 ]
词汇表
- 结盟
- 传递身份验证域与DMARC的可见发件人域之间所需的关系。
- 选择器
- 与签名域一起使用的DKIM标签在DNS中查找其公钥。
- 权威DNS
- 负责发布相关区域记录的名称服务器服务。
- Return-Path
- SMTP反向路径的接收消息跟踪在调查信封身份时很有用。
企业出处
为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。
传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中，手动监督意味着延迟执行、配置漂移和不受监控的影子域。
EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject，保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准，以及人机交互审核能力。
SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密