[ DMARC和政策 ]

按域名或子域名区分电子邮件用途,并具有明确的所有权

围绕所有权、通信目的和实际发送路由选择身份结构,然后验证每个名称的策略和接收要求。

由EmailAuth研究团队提供 · 6 分钟阅读

[ 要点 ]

  • 选择用于具体职责和可维护控件的命名空间。
  • 单独的子域命名并不能隔离身份验证信任。
  • 将发送、接收和生命周期决策分开。
在此页面上

当邮件资产与真正的业务职责相对应时,单独的域或子域可以使邮件资产更易于操作。当它创建另一个非托管名称而相同的未知应用程序继续发送时,它的用处不大。

从组织需要分离的内容开始:员工信件、交易通知、活动、列表管理或不应发送的域。然后选择使这些边界可维护的名称、权限和证据。

在选择名称之前写入目的寄存器

对于每个提议的身份,记录业务目的、所有者、批准的服务帐户、预期发件人地址、身份验证路径以及接收邮件的需要。包括谁控制DNS以及谁可以撤销身份。

以下寄存器是合成的。域名和运营决策是说明性的。

  • 名称: example.com ;预期目的和所有者:员工信件;工作场所团队;发送决策:批准的员工路线和名单使用;接收决定核实:工作人员邮箱及操作回复
  • 名称: receipts.example.com ;预期目的和所有者:交易收据;应用程序所有者;发送决策:命名生产应用程序和帐户;接收决定验证:回复和操作邮件是否必须到达
  • 名称: updates.example.com ;预期目的和所有者:客户活动;营销负责人;发送决定:批准的活动帐户;接收决定进行验证:回复、选择退出工作流程和支持路由
  • 名称: retired.example.net ;预期用途及业主:保留老品牌;品牌和 IT 所有者;发送决定:隐流审核后才不发送;接收决策验证:接收保留和恢复依赖性单独评估

“无回复”本地部分并不表明域没有接收目的。同样,没有网站并不意味着域从不发送。在分配限制性记录之前清点实际的依赖关系。

当管理可以保持连接时选择子域

特定用途的子域可以使可见身份、服务所有权和配置在已建立的命名空间下更容易跟踪。例如,可以为收据应用程序分配自己的发件人域和支持的签名设置。

该结构仍然需要检查父子策略关系。在下面 RFC 9989 §4.10.1,作者域的直接策略与策略选择相关;否则发现和适用的父设置可能很重要。使用 子域策略验证 而不是假设空子记录意味着没有策略适用。

在下面 RFC 9989 §3.2.10.1 和 RFC 9989 §4.10.2, 放松 结盟 可以连接不同的名称共享 组织域 由适用的发现算法建立。因此,子域不会自动成为严格的身份验证边界。检查委托控制、选择的对齐设置以及服务实际可以使用的身份。 严格与宽松的对齐方式 解释了其中的区别。

为合理的独立命名空间选择单独的域

单独的注册域名可以支持独立所有权、品牌或生命周期需求。它还创建自己的续订、 DNS 、帐户、报告和恢复职责。将这些责任纳入运营决策,而不是纳入未来的清理清单。

将应用程序移动到另一个域可能会影响收件人识别的内容、回复路由和服务配置。不要承诺新名称会自动提高声誉、防止所有冒充或得到每个提供商的支持。测试实际的预期发件人地址和送货路线。

单独的域并不能消除识别批准帐户或保护管理访问的需要。即使命名空间看起来整齐地分段,具有正确身份验证的废弃发送帐户仍然是一个所有权问题。

配置服务实际发送的身份

对于每个选定的目的,请使用提供商生成的设置来设置正确的帐户和路线。使用 RFC 9989 §4.4.1 和 RFC 9989 §4.4.2, 确认激活 DKIM 签名、SPF 评估的身份及其与可见域的关系。发布新的子策略不会导致应用程序仍使用父发件人地址来切换身份。

发送有代表性的授权测试并保留可信接收器结果。验证回复和失败行为以及正常消息。来自默认提供商地址的营销样本并不表明生产品牌标识已准备就绪。

在业务需要需要时,在批准的过渡期间保留旧身份以供调查。记录哪些服务已移动以及哪些服务仍依赖于以前的名称,而不是在DNS编辑后声明迁移完成。

分别决定发送和接收

不应发出邮件的域可能仍需要接收回复、报告、法律通知或帐户恢复邮件。将这些目的视为单独的决定。

SPF、 DKIM和 DMARC 关注发送身份验证和策略。在下面 RFC 7505 §3, null MX声明域不接受邮件,并且不应仅因为出站邮件已停用而应用。 RFC 7505 §4.2 还警告不要在域中使用 null MX 邮件来自 或发件人地址。在将其用于活动身份之前,请先检查这些限制。

对于认为不发送的域,请使用 非发送域评估 并在缩小权限之前测试隐藏的应用程序。禁用未知恢复路径的限制性配置可能会导致下一次中断。

部署后保持分离有用

按业务身份和所有者对报告和事件进行分组,同时保留实际的消息域。活动身份的不明来源应该成为为此目的的调查,而不是自动成为批准的员工发件人。

当供应商、品牌或应用程序所有权发生变化时,请查看登记册。保持独立域的续订和恢复访问最新,并保持子域的委派和父策略证据最新。

有用的分离使得责任和身份验证更容易验证。选择适合业务目的的命名空间,然后维护批准的路由,发送策略并接收每个名称背后的决策。

记录决定及其限制

对于receipts.example.com ,保留实际的生产发件人、签名域、评估SPF身份和发现的策略,然后分别测试回复和失败处理。将retired.example.net保留在寄存器中,直到发送依赖项和接收要求都得到解决。该登记册是虚构的;未执行任何身份迁移、帐户配置或域名购买。

[ 外卖 ]

选择用于具体职责和可维护控件的命名空间。单独的子域命名并不能隔离身份验证信任。将发送、接收和生命周期决策分开。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

IT/邮件管理员

验证孩子和父母的实际关系。

名称、策略和服务身份必须在DNS和收到的消息中一致。

后续步骤

  1. 记录适用的策略和对齐设置。
  2. 测试生产 From 身份。
  3. 继续将接收决定与外出退休分开。

CISO / SecOps

将命名空间设计视为所有权决策。

当权限和责任遵循预期边界时,分离就提供了价值。

后续步骤

  1. 查看委派的DNS和服务帐户。
  2. 为每个目的保留证据。
  3. 在生命周期审查中包括已收购和已退役的域名。

创始人/非技术人员

将每个身份与商业目的联系起来。

当每个名称都有公认的所有者和存在的理由时,域名选择就变得更容易管理。

后续步骤

  1. 在购买另一个名称之前先批准其用途。
  2. 包括收件人识别和回复体验。
  3. 分配更新和退休责任。

[ 常见问题解答 ]

常见问题

新的子域是否会自动隔离身份验证信任?

不会。策略发现、组织边界、对齐设置和委派权限仍然很重要。单独的子域名并不能建立严格的分离。

RFC 9989 §4.10.2

什么时候值得考虑单独的域?

当品牌、独立所有权或生命周期需要证明单独的命名空间合理且组织可以维护更新、 DNS 、帐户和恢复时,请考虑它。

我可以为不同的子域提供不同的策略吗?

是的,但请验证直接作者域记录以及适用的发现和后备规则。不要仅根据标签假设父子关系。

RFC 9989 §4.10.1

发布子DMARC记录是否会移动应用程序的发件人地址?

不可以。发送应用程序必须使用其预期身份和支持的身份验证配置。验证实际消息。

RFC 9989 §3.2.2 RFC 9989 §5.3.5

仅出站身份是否应该自动获取 null MX ?

否。在声明该域不接受邮件之前,请查看回复、操作要求以及RFC 7505对 MAIL FROM 或 From 中使用的名称的注意事项。

RFC 7505 §4.2

已退役的品牌是否仍具有隐藏的邮件依赖性?

是的。恢复消息、休眠应用程序和旧的供应商工作流程可能会保留。在限制性停用之前确认发送和接收依赖项。

域分离能否保证更好的收件箱放置?

不会。它创建了操作身份选择,而实际的接收者处理还取决于其他证据和策略。

RFC 9989 §5.4

目的登记册应保留什么?

保留名称、用途、所有者、 DNS权限、服务帐户、批准的路由、身份验证证据、接收需求以及退役或审查条件。

[ 来源 ]

来源

  1. RFC 9989

    部分 §3.2.10.1 · §3.2.2 · §4.10.1 · §4.10.2 · §4.4.1 · §4.4.2 · §5.3.5 · §5.4

  2. RFC 7505

    部分 §3 · §4.2

[ 词汇表 ]

词汇表

授权
子域及其服务身份的操作控制;命名边界本身并不是严格的DMARC对齐边界。

RFC 9989 §3.2.10.1 RFC 9989 §4.10.2

目的登记
身份、业务用途、所有者、批准帐户、接收需求和生命周期条件的编辑操作记录。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库