如果我使用在 DNS 中没有对应公钥的私钥签署邮件，这是否比根本不签署邮件更糟糕（就可传递性而言）？
我知道这将取决于接收邮件服务器，它可以实施任何它喜欢的规则，但我希望对此有一般指导。
我之所以问这个问题，是因为我会控制某些邮件的签名，但我不确定负责更新 DNS 记录的人是否/何时会完成他们的工作。如果我只是设置了我的端，签名，如果他们很长时间没有添加 DNS 记录，那会是个大问题吗？
答案1
根据 RFC 6376：
6.3. 解释结果/应用本地政策
描述身份评估员可以采取哪些行动超出了本规范的范围，但带有经过验证的 SDID 的邮件为身份评估员提供了机会，而未经身份验证的电子邮件则没有。具体来说，经过身份验证的电子邮件会创建一个可预测的标识符，通过该标识符可以可靠地管理其他决策，例如信任和声誉。相反，未经身份验证的电子邮件缺乏可用于分配信任和声誉的可靠标识符。将未经身份验证的电子邮件视为缺乏任何信任并且没有积极声誉是合理的。
一般而言，使用 DKIM 验证输出的模块不应仅根据缺少任何签名或无法验证的签名来确定邮件的可接受性；这种拒绝会导致严重的互操作性问题。如果 MTA 确实希望在 SMTP 会话期间拒绝此类邮件（例如，在与事先达成协议同意仅发送签名邮件的对等方通信时），并且签名缺失或无法验证，则处理 MTA 应使用 550/5.7.x 回复代码。
当验证器集成在 MTA 中，并且无法获取公钥（可能是因为密钥服务器不可用）时，可以使用 451/4.7.5 回复代码生成临时失败消息，例如：
451 4.7.5 无法验证签名 - 密钥服务器不可用
暂时故障（例如无法访问密钥服务器或其他外部服务）是唯一应使用 4xx SMTP 回复代码的情况。特别是，加密签名验证失败绝不能引发 4xx SMTP 回复。
一旦签名被验证，该信息必须传达给身份评估者（例如明确的允许/白名单和信誉系统）和/或最终用户。如果 SDID 与 From: 标头字段中的地址不同，则邮件系统应尽力确保读者清楚了解实际的 SDID。
虽然验证失败的症状很明显——签名无法验证——但确定确切原因可能更加困难。如果找不到选择器，是因为选择器已被删除，还是值在传输过程中以某种方式被更改了？如果签名行丢失，是因为它从未存在过，还是被过于热心的过滤器删除了？出于诊断目的，验证失败的确切原因应该可用，并可能记录在系统日志中。
因此，它可能因接收服务器配置而异，但大多数可能不会标记为垃圾邮件，特别是如果有有效的 SPF 和 DMARC 记录以及有效发件人的其他指标（IP 地址信誉、域信誉等）。