即使没有为该名称显式创建记录，通配符DNS也可以做出名称应答。当你诊断时这很重要 DMARC： TXT答案可能是从通配符合成的，并且另一个附近的名称可能会表现不同，因为部分DNS树已经存在。
正确的测试从真实邮件的发件人地址中的域开始。跟踪每个相关查询及其返回的记录集。不要根据区域导出中星号的存在或根据虚构主机名响应的网站来推断DMARC覆盖范围。
将DNS合成与DMARC发现分开
DNS通配符处理确定特定查询是否可以接收合成数据。 DMARC发现确定哪个策略适用于邮件。这些是不同的步骤。第一个DMARC查询将_dmarc添加到作者域；后续发现遵循适用的协议规则。 RFC 9989 ，第 4.10 节.
通配符，例如 *。 example.com并不是将每条记录复制到每个子域的通用指令。 DNS考虑现有名称、最接近的封闭名称和请求的记录类型。仅包含地址记录的通配符不提供DMARC TXT策略。 RFC 4592 §3.3.1 和 RFC 4592 §3.3.3.
还要避免处理_dmarc .*。 example.com作为DMARC接收器扩展到所有子域的模式。在下面 RFC 4592 §2.1.1，通配符域名的最左边标签为星号； DMARC不会搜索文本模式目录来查找每条消息的策略。
使用现有名称作为有意的测试用例
考虑一个合成区域 TXT记录 在 *。 example.com包含其他有效的DMARC值。如果branch.example.com不存在，并且_dmarc.branch.example.com查询的最接近的封闭者是example.com ，则该通配符可以是合成TXT答案的来源。
现在假设branch.example.com作为DNS节点存在。 _dmarc.branch.example.com最近的包围体发生了变化。紧邻该较近节点下方的通配符将是 *。 branch.example.com 。查找不会简单地返回到 *。 example.com当该来源不存在时。这种区别就是广泛通配符假设失败的原因。 RFC 4592 ，第 3.3.1 节.
在下面 RFC 4592 §2.2.2，空的非终结符也可以算作现有名称。名称可以存在，因为即使它没有自己的记录集，记录也存在于其下方。因此，在树的更深处添加明显不相关的记录可能会更改提供答案的通配符（如果有）。将场景视为算法的解释，而不是作为提供商当前区域如何配置的证明。
构建一个小型发现工作表
选择实际的发送域、显式配置的子域、委托子域（如果相关）以及真正不存在的测试名称。避免仅仅为了测试DNS而从发明的域发送邮件。对于每个案例记录：
- 正在建模的确切作者域。
- 初始以_dmarc为前缀的TXT查找名称。
- 权威的解答状态和完整的TXT记录集。
- 根据区域证据，匹配的所有者是明确的还是潜在的综合。
- 任何后备策略发现以及生成的策略域。
- 用于解释结果的实现或规范。
肯定的DNS答案本身可能不会透露它是合成的。授权区域检查与权威响应结合使用。查询字面星号名称并不等同于测试接收邮件系统将查询的具体名称。
不要将存在与授权混淆
域的存在影响的不仅仅是显式TXT行的存在。 RFC 9989 通过其策略发现规则和 sp/np 处理来区分现有子域和不存在子域的策略。通配符答案可能会影响该区别背后的DNS观察。在依赖 np 获取特定名称之前验证实际存在和策略路径。 RFC 9989 §3.2.13 和 RFC 9989 §4.10.1.
即使策略是可发现的，它也不会授权应用程序发送或创建对齐的签名。在下面 RFC 9989 §5.3.5，消息仍然需要经过身份验证的一致身份才能通过DMARC 。使用 对齐指南 对于那个单独的任务。
更喜欢可解释的政策布局
作为操作建议，在需要精确控制的情况下使用显式记录并记录预期的后备行为。在更改通配符之前，请清点其其他用途：相同的DNS配置可能支持不相关的服务。在不检查这些依赖项的情况下，请勿将其作为仅邮件清理来删除。
添加DNS节点、委派子域或更改DMARC布局后重新测试工作表。保存以前的和新的观察结果。完成标准是对每个重要发件人域的解释策略路径，而不是通配符涵盖所有内容的笼统声明。
保留有界结论
在合成区，不存在的分支允许*。 example.com仅在规定的最接近封闭体和TXT假设下提供具体查询。一旦分支存在，候选者就变成*。 branch.example.com ;不存在不会触发通配符回退到父级。 DMARC仍可能执行其自己单独的策略发现。未执行任何权威查找或区域更改。