[ 寄送服务指南 ]
验证通过 AuthSMTP 发送的电子邮件：配置和验证
验证实际的 AuthSMTP 发送域，包括到达时已经过 DKIM 签名的邮件的重要例外。
由EmailAuth研究团队提供 · 3 分钟阅读
[ 要点 ]
- 确定应用程序或中继是否提供签名。
- 使用域生成的DKIM值和一项完整的SPF策略。
- 测试预签名和未签名的路径，而无需发明测试结果。
[ 外卖 ]
测试预签名和未签名的路径，而无需发明测试结果。
[ 按角色 ]
这对您意味着什么
选择您的角色以执行后续实际步骤。
IT/邮件管理员
追踪每个签名
已发布的中继密钥无法修复应用程序端签名。
后续步骤
- 记录应用程序签名者。
- 检查权威选择者的答案。
- 将交付的签名域与发件人进行比较。
CISO / SecOps
避免授权不明确
保持域权限和签名责任可审核。
后续步骤
- 查看所有活动的SPF发件人。
- 保护私人签名材料。
- 仅在依赖性检查后才停用旧选择器。
创始人/非技术人员
指定签名者
明确中继和应用程序所有权。
后续步骤
- 批准每个应用程序的无害测试。
- 指定谁可以暂停中断的路线。
- 扩展之前需要收到消息证据。
[ 常见问题解答 ]
常见问题
AuthSMTP 是否会将签名添加到我的应用程序已签名的消息中？
其记录的行为是保留现有签名而不添加 AuthSMTP 签名。检查应用程序签名者。
应用程序所有者应该提供什么？
预期的发件人身份、实际中继帐户、签名责任以及执行正常发送路径的安全方法。
SMTP成功是否证明身份验证？
不。它证明SMTP步骤已被接受；单独保留最终接收者的认证结果。
此更改何时完成？
当每个预期的应用程序路由具有匹配的DNS和观察到的一致身份验证时，以及可恢复的先前配置。
[ 来源 ]
来源
- 使用 AuthSMTP 进行DKIM签名 |验证SMTP
部分 AuthSMTP 域授权所需 · 使用CNAME方法进行新配置 · 发布并验证记录 · 如果您的应用程序已经对消息进行签名
- AuthSMTP 入门指南
部分 第 3 步 - 设置您的帐户 · 第 4 步 - 重要提示
- AuthSMTP 的SPF设置 |验证SMTP
部分 将 AuthSMTP 包含在您现有的记录中 · 检查整个发送区域
- RFC 7208
部分 §2.4 检查授权 · §3.2 多个DNS记录 · §4.6.4 DNS查找限制
- RFC 6376
部分 §3.5 DKIM-Signature标头 · §3.6.2 DNS绑定 · §6 验证者操作
- RFC 9989
部分 §4.4 标识符对齐 · §4.10 DNS树遍历 · §5.3.5 确定DMARC通过或失败
[ 词汇表 ]
词汇表
- SPF
- SMTP信封发件人域的DNS授权，受协议限制。
- DKIM
- 在签名域下的选择器处使用公钥验证签名。
- DMARC对齐
- 可见的发件人域与传递的SPF或DKIM身份验证域之间所需的关系。
- 权威DNS
- 负责发布区域答案的委托DNS服务。
- 选择器
- 与签名域一起使用的DKIM标识符来查找公钥。
企业出处
为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。
传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中，手动监督意味着延迟执行、配置漂移和不受监控的影子域。
EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject，保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准，以及人机交互审核能力。
SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密