[ 寄送服务指南 ]
验证通过 Acquia Cloud 发送的电子邮件：配置和验证
为实际的 Drupal 应用程序配置 Acquia Platform Email，然后验证其发送身份，而不是重复使用旧版DNS 。
由EmailAuth研究团队提供 · 3 分钟阅读
[ 要点 ]
- 将电子邮件域与网站域分开验证。
- 将经过验证的域与实际的 Drupal 应用程序相关联。
- 停用旧版SPF依赖项，而不删除其他授权。
[ 外卖 ]
停用旧版SPF依赖项，而不删除其他授权。
[ 按角色 ]
这对您意味着什么
选择您的角色以执行后续实际步骤。
IT/邮件管理员
验证实际路线
将文档域验证、应用程序关联和 Drupal 传输作为三个独立的检查点。
后续步骤
- 将文档域验证、应用程序关联和 Drupal 传输作为三个独立的检查点。
- 保留准确生成的记录集和权威DNS前后对比。
- 捕获来源、 SPF身份、 DKIM d=/s=和可信接收者结果来自真实路由。
CISO / SecOps
控制剩余的暴露
在停用前检查共享域依赖关系，并保留每个应用程序使用的经过身份验证的身份的证据。
后续步骤
- 在停用前检查共享域依赖关系，并保留每个应用程序使用的经过身份验证的身份的证据。
- 对于任何未解决的身份验证或供应商能力异常，需要记录决定。
- 当此服务停用时，请检查过时的DNS授权和委派。
创始人/非技术人员
拥有发送结果
将发布批准与经过测试的业务通知（例如表单确认）联系起来，而不是绿色DNS徽章。
后续步骤
- 将发布批准与经过测试的业务通知（例如表单确认）联系起来，而不是绿色DNS徽章。
- 在批准更改之前分配业务工作流程和发送域所有者。
- 让受影响的活动暂停，直到获得接受证据为止。
[ 常见问题解答 ]
常见问题
我可以继续使用旧的 Acquia SPF防晒霜吗？
不要将其添加到当前平台电子邮件中。 Acquia 表示不再需要其遗留依赖；在删除该术语之前先检查现有的使用情况。
我应该测试什么消息？
通过真正的 Drupal 应用程序传输发送到您控制的邮箱的代表性通知。
为什么验证可以通过，邮件却错误？
应用程序可以使用另一种传输、另一个发件人域或与您验证的不同的关联。
[ 来源 ]
来源
- Acquia：配置平台电子邮件
部分 前提条件 · 配置域 · 将域与应用程序关联 · 配置用于发送电子邮件的电子邮件地址 · 删除域
- Acquia：平台电子邮件的SPF记录错误
部分 问题·解决方案·原因
- RFC 9989: DMARC
部分 §4.4.1 DKIM 身份验证的标识符 · §4.4.2 SPF 身份验证的标识符 · §4.10 DNS树遍历和重复策略记录 · §5.3.5 确定DMARC通过或失败
- RFC 7208: SPF
部分 §3.2 多个DNS记录 · §4.5 选择记录 · §4.6.4 DNS查找限制
- RFC 6376: DKIM
部分 §3.3 签名和验证算法 · §3.6.2 DNS绑定 · §6 验证者操作
[ 词汇表 ]
词汇表
- 可见自
- 消息 From 标头中显示的作者地址，其域用于DMARC对齐。
- 信封标识
- 由SPF评估的SMTP发送身份，与可见的 From 和 Reply-To 不同。
- DKIM选择器
- s= 标识符与签名 d= 域一起使用来定位验证密钥。
- 结盟
- 经过身份验证的SPF或DKIM身份与可见的发件人域之间所需的域关系。
企业出处
为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。
传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中，手动监督意味着延迟执行、配置漂移和不受监控的影子域。
EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject，保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准，以及人机交互审核能力。
SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密