更改DNS之前命名 Retarus 服务
本指南涵盖 Retarus 交易电子邮件。它不会将相同的记录集应用于安全电子邮件网关、不相关的 Retarus 服务或通过 Retarus 门户管理的每个产品。在准备身份验证更改之前，记录签约服务、应用程序、技术帐户、发送域、接口和数据中心。类似的品牌并不能建立相同的交付路线。
Retarus 的入职指南建议考虑为多个应用程序使用单独的技术帐户，并在交易和营销内容不同时考虑单独的发送域。它还将额外的数据中心使用视为必须报告和订购的服务安排。使用这些维度来组织库存；不要推断DNS编辑会提供新的区域或帐户。 Retarus 入职注意事项
对于每个应用程序，确定生成邮件的业务事件以及负责错过或延迟投递的团队。即使密码重置、发票通知和营销活动共享基础设施，它们也可能有不同的操作恢复需求。选择测试实际提交路径的无害测试内容。将客户文档、访问令牌和生产消息正文排除在共享身份验证证据之外。
获取并发布注册域名记录
Transactional Email 基本配置文件include:_spf.general.transactional-mail-a.com并需要相关 邮件来自 拥有的域名 SPF 授权。这也使得 DKIM 对于每个注册的发件人域都是强制的，使用 Retarus 生成和提供的密钥。获取服务当前发布的值，而不是构建一个 选择器 从公司名称来看。 Retarus基本配置
要求实施所有者提供注册域列表、预期的信封标识、签名域以及所有必需的公共DNS值。将它们与应用程序清单相匹配。如果应用程序使用多个发件人域，请确定哪些已实际注册。不要假设一个域的成功测试会将授权扩展到应用程序可以放入消息中的每个地址。
在发布之前捕获当前的DNS记录。将任何所需的SPF授权与正确所有者的现有策略合并，保留其他合法路由。检查完整的查找评估，而不是仅计算可见的包含术语。 SPF评估SMTP发件人身份，并且在所有者处发布多个适用的SPF策略并不是组合服务的有效方法。 SPF RFC 7208
准确使用颁发的DKIM记录名称、类型和值。确认任何 DNS 区域后缀扩展后的最终所有者并独立查询权威服务。将DNS证据连接到实施票证，并记录 Retarus 何时认为域设置处于活动状态。公共DNS可用性和提供商激活是单独的检查点；两者都不应从拟议更改的屏幕截图中推断出来。
基本配置页面描述了当未在规定的窗口内完成所需条目时重复验证可能产生的费用。服务所有者应确认适用的协议和加入截止日期，而不是将本指南视为定价建议或接受条款。 Retarus基本配置
查看谁可以使用经过身份验证的域
域身份验证授予有意义的发送能力。默认情况下，注册域内的地址的 Retarus 文档可用，并提供在实施期间或通过服务请求请求的“允许的发件人地址”选项。记录的功能适用于SMTP和 REST。在设计受限发件人列表之前，请与实施所有者确认其当前的限制。 Retarus 允许的发件人地址
将目标发送者映射到需要它们的应用程序。检查共享技术帐户是否允许不相关的工作负载使用相同的身份。除了DNS问题之外，这是一个访问设计问题。完美对齐的签名并不能证明使用该帐户的每个应用程序都应有权作为组织的财务或安全团队发送。
将凭证保存在批准的秘密管理系统中。在工作表中记录帐户标识符和负责团队，无需复制密码或 API 密钥。任何创建新凭证、扩展访问权限或更改帐户限制的提案都属于其自己批准的变更。不要将这些操作隐藏在身份验证故障排除任务中。
将信封重写视为未解决的配置分支
Retarus 有一个单独的 EnvelopeFrom 地址重写服务，并表示要联系它以获取详细信息和激活。审阅的页面包含不一致的措辞：其标题和示例讨论了 EnvelopeFrom 和 rewriteFrom，而描述性句子则引用了 EnvelopeTo。这种不一致使得本文无法将该页面视为明确的实现方案。 Retarus 信封重写
如果需要重写，请询问 Retarus 此接口和帐户的身份发生了哪些变化、如何应用映射以及如何影响退回处理。使用非敏感测试地址获得清晰的前后示例。确认可见的From是否保持不变。当这些问题没有得到解答时，请勿将请求正文示例复制到生产中。
报告成功传送的提供商事件是有用的操作证据，但它不能取代目的地的身份验证评估。收集双方：作业或消息引用标识尝试的传递，而接收到的标头标识到达的信封和签名。应根据收到的证据而不是仅根据其请求的输入来评估重写的信封。
证明每个已发布路线的对齐情况
通过实际发布的SMTP或 REST 集成发送受控消息。保留受信任的接收者结果、可见的发件人、信封域以及每个DKIM签名域和选择器。 DKIM 'sd= 和 s= 值标识签名的域和密钥查找。没有相应传递消息签名的已发布密钥是不完整的证据。 DKIM RFC 6376
将传递的身份与配置下的可见From进行比较 结盟 模式。 DMARC 允许通过对齐的SPF或DKIM路径；要求并不是每个签名都必须通过，或者不相关的通过身份必须保持一致。使用 RFC 9989 对于简化的供应商措辞不太精确的协议解释。 DMARC RFC 9989
测试每个注册域以及更改发件人或信封的任何应用程序分支。在证据中包括预期区域和技术说明。如果身份验证失败，请保留准确的结果，并将DNS发布、激活、域选择、消息修改和重写作为单独的假设进行隔离。一次进行一项合理的修正，然后重复相同的测试。
虚构诊断：第二个应用程序使用未经审查的身份
一家虚构的公司通过其发票集成来验证emma@billing.example 。第二个应用程序共享该帐户，但提交alex@ops.example 。其团队假设早期的测试涵盖了两者。在本发明的情况下，第二域尚未完成商定的签名设置，因此其接收到的消息缺乏对齐的传递路径。这是一个假设的教学示例，不是观察到的 Retarus 行为。
审阅者检查注册域范围和应用程序所有权，而不是添加任意SPF权限。服务团队完成支持的域配置，确认允许的发件人，并独立测试第二个应用程序。如果还涉及信封重写，则该分支将保持打开状态，直到 Retarus 解决文档歧义并且接收方显示实际结果。
路线工作表和验收门
- 服务：交易电子邮件、应用程序、界面、技术帐户、区域和企业主。
- 域：注册发件人身份、批准的发件人地址、信封身份和提供商确认。
- DNS ：发布的公共值、历史记录、合并的SPF 、权威观察结果和激活时间。
- 测试：事件、时间戳、工作参考、收到的身份、可信结果和一致性决策。
- 重写：请求的行为、提供者澄清、退回影响和未解决的范围。
- 恢复：以前支持的路由、回滚所有者、重新测试条件和退役依赖项。
该候选人有文件支持，但没有客户验证。实时租户、 DNS 、标头、视觉、人类 SME 和发布门仍然悬而未决。安全电子邮件网关和不明确的信封重写实施细节仍在验证范围之外。
将所需的SPF结尾作为单独的政策决定进行审查
Retarus 基本配置需要发送者域 SPF记录 以-all或~all结尾。合并所需机制时保留现有的授权发送服务，但不要将保留解释为允许保留不兼容的结局。在批准任何更改之前，请域名所有者检查现有的结尾以及对其他合法发件人的影响。此提供程序先决条件不会授权从softfail自动转移到硬故障，并且不会取代对齐或DKIM检查。
在帐户扩展之前确认允许的发件人限制
当前的“允许发件人地址”页面规定每个注册发件人域最多有 50 个地址，并且不包括基于角色的地址，请参阅其禁止名称策略。在设计限制之前，请与提供商确认确切的名称和当前的适用性。不要推断域名注册会超越这些限制。虚构地址是教学标签，而不是提供商批准的发件人；未执行任何限制或消息测试。
将消息接受与策略推出分开
通过的对齐SPF结果可以满足邮件评估的要求，但并不能单独证明将整个域移至拒绝。 RFC 9989第 7.4 节要求有效的DKIM进行域发布 p=reject 并警告间接邮件互操作性。在策略所有者批准执行之前，清点所有合法发件人和间接路由。本文未执行任何DNS更改、租户操作或接收消息测试。