在DNS之前解决帐户所有权
本指南涉及 Elastic Email Marketing 和电子邮件 API 中的发件人域，而不是通过其 Inbox 产品接收邮件。从预期帐户、发送域、应用程序所有者和权威DNS管理员开始。在生成新的部署计划之前，请确认哪个帐户当前拥有该域。
弹性电子邮件 域名验证指南 表示发件人域一次只能与一个电子邮件营销或电子邮件 API 帐户关联。如果另一个帐户持有该帐户，请首先解决该所有权问题。管理员不应在未识别仍通过该帐户发送的应用程序的情况下从旧帐户中删除生产域。如果无法访问或帐户无法删除它，请遵循提供商的支持和所有权验证流程。
使用帐户的验证工作流程
记录的路径为“设置”>“域”>“管理域”>“开始验证”。选择域名验证，输入您拥有的域名，发布显示的记录并使用验证记录。在域详细信息中，检查各个记录状态，而不是将整个列表条目视为每个可选功能有效的证据。
为了 SPF，提供者识别 include:_spf.elasticemail.com。将必要的授权集成到现有的适用SPF TXT策略中，而不是创建第二个策略。查看整个策略，包括其他授权服务和DNS查找成本。不要从示例中复制广泛的 a 或 mx 机制，除非它们与域的预期授权相匹配。
为了 DKIM，使用帐户当前DKIM部分中显示的名称和值。 Elastic Email 生成密钥对并通过您的DNS发布公共组件 TXT记录。一个老教程 选择器 或公钥不能替代。如果服务报告未找到有效的DKIM ，请在更改不相关记录之前将权威答案与当前帐户值进行比较。
将默认发件人行为视为策略选择
该提供商根据是否存在默认发件人域来描述后备品牌，并指出子帐户可以继承对主帐户的默认已验证发件人域的使用。记录选择的默认值以及该继承是否适合使用该帐户的应用程序。域名验证和应用程序授权不是同一个行政决策。
不要依赖后备行为来使未经批准的发件人域变得可接受。要求每个生产应用程序使用其批准的身份并测试实际交付的内容。平台可以使用意外的域成功发送消息，这在操作上与完成预期的自定义域设置不同。
将跟踪和邮件路由与签名分开
域名详细信息还公开了跟踪、 MX和 DMARC 地位。发布前查看每条记录的用途。一个跟踪 CNAME 关注链接行为；发件人域MX指令不是替换组织收件箱路由的全面权限。保留当前域范围的DMARC策略，除非其所有者批准基于所有合法发件人的故意更改。
原始测试设计：使用无害的应用程序消息以及相关的子帐户测试。记录请求的From身份、选择的账户/默认、实际收到的From、 信封发件人、 DKIM域和选择器以及接收者身份验证结果。 DMARC要求通过SPF或DKIM结果与可见发件人一致。在决定回退是否可接受之前，将预期身份与接收到的身份进行比较。
在故障层进行诊断和恢复
说明性场景： DNS与新帐户的密钥完全匹配，但旧应用程序仍然通过不同的帐户提交。重复替换相同的公钥并不能修复路由不匹配的问题。确认应用程序的帐户和域关联，然后选择批准的迁移或恢复路径。
保存之前的设置和记录。在未解决的所有权或身份问题期间暂停受影响的应用程序，并在可行的情况下恢复最后批准的配置。帐户迁移、默认域更改或密钥更换后重新检查。文件于 2026 年 11 月 8 日审核；此处未测试任何帐户、 DNS记录或收到的消息。
在重新生成密钥之前决定帐户移动
书面案例 EE-01 假设receipts@example.com属于旧帐户中的活动收据应用程序，而新团队尝试验证新帐户中的example.com 。新帐户报告所有权冲突；当前DNS和消息结果未知。应用程序所有者必须在批准协调转移之前清点旧的。仅为了清除 New 的警告而删除域会给现有路由带来风险。运营商应解决访问问题或遵循提供商的所有权验证支持流程，保留准确的当前配置和恢复决策。此处未发生帐户删除、支持联系或DNS更改。转移获得批准后，需要包含预期发件人和实际签名身份的受控收据，而不仅仅是经过验证的域徽章。
保留执行边界
RFC 9989 第 7.4 节要求有效的DKIM ，而不仅仅是SPF来进行域发布 p=reject，并对间接邮件和邮件列表互操作性发出警告。一次成功的直接消息测试并不能证明每条合法路线都已准备好采取更强有力的政策。保留现有批准的保护，同时诊断实际差距；任何政策变化都需要自己的决定。