MailPlus 里禁用了 DANE，来信还是被拒收？根子在 DNS 服务商那边的 DNSSEC 与 TLSA 记录

套件里关了开关，拒收却没停

DANE 是一套「用 DNS 证明邮件服务器证书可信」的机制。MailPlus Server 支持它，也允许在套件里禁用它。于是有管理员做了禁用操作之后纳闷：日志里怎么还在刷 DANE 失败，合作方的来信怎么还是进不来？

官方知识库把这层窗户纸点破了：问题多半不在 MailPlus，而在 DNS 侧的 DNSSEC 与 TLSA 记录上。

机制：对方看的是 DNS，不是你的开关

链条是这样的：

1. 发送服务器准备投递邮件给你的域，先做一次检查；
2. 只要检测到你的域存在 DNSSEC 记录，它就按规矩严格要求找到有效的 TLSA 记录，用后者验证你的邮件服务器证书；
3. 你在 MailPlus Server 里禁用了 DANE，但 DNS 托管商那里的 DNSSEC 与 TLSA 记录原样保留——声明还在，凭证对不上；
4. 发送服务器于是把这次连接标记为安全风险，甚至当作「伪服务器」处理，结果就是拒收。

一句话：DNS 里的记录是给全世界看的声明，套件里的开关只管自己。声明不撤，对方的严格检查就不会停。

解法：去 DNS 控制台移除两类记录

要真正禁用 DANE、止住这类拒收，必须到 DNS 托管服务商的管理控制台，把：

• DNSSEC 记录，与
• TLSA 记录

两类一并移除。只在 MailPlus 里点禁用是不够的——这正是本例症状的来源。

验证：一条命令看 DNSSEC 是否还在

改完后别凭感觉收工。在终端里执行：

dig 你的域名 +dnssec +short

输出为空或不再携带 DNSSEC 标记，说明记录已撤干净；还能看到记录残影，就回 DNS 控制台再查一遍，别只删了一半。

小结

• 症状：MailPlus 已禁用 DANE，来信仍因 DANE 失败被拒收；
• 根因：DNS 侧残留的 DNSSEC 让发送服务器强制要求有效 TLSA，缺位即被判为安全风险；
• 解法：DNS 托管商控制台移除 DNSSEC 与 TLSA 记录；
• 验证：dig 加 +dnssec 参数确认撤除生效。

诚鑫致达科技处理这类拒收问题的收尾动作是隔天回看：改完记录的次日在邮件日志里翻一遍外部来信道，DANE 相关的拒收条目清零了，这单才算闭环。