目前，DMARC 仅需要对齐的 DKIM 或 SPF。
然而，对于经验丰富的黑客来说，欺骗 SPF 相对简单：
- 您应该只控制电子邮件服务提供商（Microsoft、Google、Mailchimp 等）通常较大的 SPF 范围内的单个 IP 地址。如果列表包含过期的 IP 地址，那么这样做甚至可能是合法的。
- 或者您可以尝试利用这些服务提供商执行的发件人验证中的错误/漏洞。至少有些提供商没有执行非常安全的发件人域验证。
SPF 的本质问题在于它将此类服务提供商的许多客户共享的 IP 列入白名单。
另一方面，这些服务提供商可能对 DKIM 密钥的保护措施更好，并且（通常）只与单个客户相关联。或者至少，保护 DKIM 密钥应该比确保黑客无法从允许的 SPF IP 地址之一发送电子邮件（发件人地址由黑客选择）要容易得多。
那么，扩展 DMARC 以允许指定 DKIM 应对齐，这不是很有好处吗？或者是否存在 DMARC 的后继者来强制执行 DKIM 对齐？
部分相关问题：
- DMARC 对齐：强制邮件通过 SPF 和 DKIM（这不是重复，因为我的问题是这是否是一个好的 DMARC 设计，我们无法强制执行 DKIM）。
- DMARC 的 SPF 对齐可以被欺骗吗？（关于欺骗对齐 SPF 的可能性：欺骗 SPF 比欺骗 DKIM 更容易）。
答案1
接受任何一种身份验证机制都植根于 DMARC 规范的关键概念（RFC 7489, 4.2）。此时进行更改将需要对每个实现进行重大修改。
但是，可以采用一种保护域名的方式，只有通过和对齐的 DKIM 才会让 DMARC 通过。此外，还可以采用一种不允许任何人使用该域名作为信封发件人，与建议的不同来自@anx 的回答。
通过严格对齐，这是可能的可供两者使用DKIM-和SPF 认证身份标识。
在放松模式下，[防晒指数] 认证域名和RFC5322.发件人域必须具有相同的组织域。在严格模式下，只有精确的 DNS 域匹配才会被考虑产生标识符对齐。
知道这一点，
禁止使用域名的顶点作为信封发件人。
example.com TXT "v=spf1 -all"选择用于信封地址的子域，并根据需要允许 SPF，例如，
mailer.example.com TXT "v=spf1 +ip4:192.0.2.100 -all"要求使用严格的 SPF 对齐模式
aspf=s，例如_dmarc.example.com. IN TXT "v=DMARC1; p=reject; aspf=s; adkim=r;"设置与
From地址一致的传递 DKIM 签名，可以采用严格模式或宽松模式。
答案2
允许指定 DKIM 应该对齐，这不是很有好处吗？
这已经是默认行为，如果有无法实现一致的 SPF匹配。DMARC 替代方案剩下的就是需要获得一致且有效的 DKIM 签名。
最简单的是 -虽然不是最理想的，请参见此处表格 - 您可以不选择加入 SPF，或明确选择退出（v=spf1 ?all）。您不需要有使用 SPF。
请注意，这将对您授权第三方以您的名义发送的方式施加一些限制。部分（但并非所有）发送者将能够签名或转发到您持有已发布密钥的机器进行签名。