我的 DNS 状态始终不变绿

DNS 验证会检查所选配置需要的记录。通过 TrekMail 接收邮件的域名通常需要 MX、SPF、DKIM 和 DMARC。MTA-STS 与 TLS-RPT 等推荐记录可能单独显示。本指南帮助您准确比较控制面板和 DNS 提供商。

从控制面板记录表开始

打开域名，选择受影响的域名并查看 DNS 状态。从表中复制类型、主机、值以及 MX 的优先级。该表是可靠依据，因为 DKIM 值和某些政策记录是域名专属的。

更改记录前，请确认其他服务是否仍需要现有值。尤其要只保留一条 SPF 记录，同时保留其他有效发件服务使用的 include。

传播需要多久？

DNS 更新出现的时间取决于提供商、原记录的 TTL 和解析器缓存。待处理不证明值错误，经过很长时间也不证明值正确。

请按此顺序操作：

1. 在托管权威 DNS 区域的提供商处保存记录。
2. 将记录与控制面板表比较，包括 MX 优先级和完整 DKIM 值。
3. 使用一次验证 DNS，请求 TrekMail 重新检查。
4. 如果仍待处理，请查看冲突详情并用独立查询确认当前公共值。

必需记录

以下是普通邮件托管的主要记录。请从自己的控制面板复制值，不要替换成其他域名的值：

推荐记录可以提升送达安全性，但不能代替主要记录：

可选的客户端自动配置 CNAME（autoconfig、autodiscover）可加快邮件应用设置，但不影响邮件送达。

检查 1：合并重复的 SPF 记录

域名根部只能有一条以 v=spf1 开头的 TXT 记录。如果有两条，接收服务器无法可靠确定发件政策，TrekMail 也无法正确验证。

**症状：**两条记录均显示在 DNS 中，但 TrekMail 仍标记 SPF 未配置。

**解决方法：**将发件规则合并为一条记录。如果现有内容为：

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.trekmail.net -all

请替换为：

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

使用哪个结尾：-all 或 ~all

只能使用一个。只要 include:spf.trekmail.net 位于结尾前，-all 和 ~all 均可通过检查。选择会影响其他服务发送的邮件。

关于结尾的建议提示不表示验证失败。两种结尾均可验证域名。

不要使用：

• ?all，因为它不提供有效的授权政策。
• +all，因为它授权互联网上所有发件人。

一条 SPF 记录最多可使用十次 DNS 查询。如果有许多第三方发件服务，请减少 include 数量，或向相应提供商咨询受支持的合并方案。

检查 2：Cloudflare 邮件 CNAME 使用了代理

Cloudflare 可以代理网站流量，但邮件 CNAME 必须设为仅 DNS。这包括 mta-sts、autoconfig、autodiscover 或控制面板要求的其他主机。

**症状：**记录在 Cloudflare DNS 列表中，却显示为受阻或无法验证。

解决方法：在 Cloudflare 中打开 DNS，找到主机，将橙色云改为灰色仅 DNS，然后在 TrekMail 中运行验证 DNS。

网站的 A 记录或主要 Web CNAME 可以继续使用代理。只更改控制面板指出的邮件主机。

检查 3：DMARC 位于错误主机

DMARC 应位于 _dmarc.yourdomain.com，而不是域名根部。某些 DNS 表单预填 @，因此容易保存到错误位置。

**症状：**DNS 中存在 DMARC，但 TrekMail 报告未找到。

**解决方法：**在 _dmarc 添加记录。有些界面要求 _dmarc，另一些要求 _dmarc.yourdomain.com。保存前查看表单提示。仅在确认错误的 @ 记录没有其他用途后再删除。

检查 4：DKIM 粘贴或分段错误

DKIM 值很长。DNS 提供商可以将长 TXT 值存为多个相连文本段，但公共结果仍必须与控制面板中的完整值一致。

"p=MIIBIjANBgkqhki..." "...continues here" "...and ends here"

大多数提供商会自动处理。错误粘贴可能增加或删除字符、空格或引号。

**症状：**DNS 中可见 DKIM，但 TrekMail 显示 "DKIM key invalid" 或 "p= does not match"。

解决方法：

• 完全按照控制面板显示的内容粘贴。
• 如果提供商自动拆分长 TXT，请粘贴完整值并让其处理。
• 如果要求分段，请遵循提供商说明并保留控制面板值中的每个字符。
• 使用独立 DNS 查询确认公共 TXT 包含完整密钥。

检查 5：MTA-STS 需要处理

MTA-STS 是通过 TrekMail 收件的域名推荐使用的送达安全功能。如果控制面板显示它，就需要页面所示 TXT 和 mta-sts CNAME。除非控制面板明确要求，否则不要为仅发件域名添加这些记录。

被 DNS 阻止。 mta-sts CNAME 缺失或指向其他位置。请使用控制面板当前目标添加或修正。

被 Cloudflare 阻止。 CNAME 存在但使用了代理。按照检查 2，将该主机设为仅 DNS。

原先正常，后来降级。 将 TXT 和 CNAME 与控制面板比较。通常是记录被更改或删除。恢复所需值，运行验证 DNS并查看新状态。

检查 6：比较公共查询和控制面板

更改仍在传播时，本地网络和 TrekMail 可能看到不同的 DNS 结果。公共查询可显示其他网络所见内容。

比较步骤：

1. 打开 dnschecker.org 或 whatsmydns.net。
2. 输入完整主机名和记录类型。例如，查询 DMARC 时使用 _dmarc.yourdomain.com 和 TXT。
3. 将返回的主机、值和 MX 优先级与控制面板表比较。
4. 如果公共查询显示正确值，但 TrekMail 仍报告不匹配，请在支持工单中提供结果。

检查 7：旧 DNS 值仍在缓存中

更改 DNS 记录后，旧值可能在中间解析器中保留至 TTL（Time To Live，以秒计）到期。旧记录常用 24 小时（86400 秒）的 TTL。

**症状：**一小时前已更改记录，但全球检查工具仍看到旧值。

**解决方法：**同一次更改仍在各解析器传播时，不要反复编辑。如计划迁移，可在提供商支持时提前降低 TTL。迁移稳定后，选择适合日常 DNS 管理的 TTL。

分步调试

1. 打开域名页面，单击您的域名。
2. 如果有查看冲突，请打开。它将必须修正的记录与推荐和信息项分开。
3. 将每个预期主机、值和 MX 优先级与 DNS 提供商保存的记录比较。
4. 在提供商处进行最小的必要更改，保留其他服务需要的记录。
5. 在 TrekMail 中单击验证 DNS。
6. 阅读更新状态。所选配置要求的记录有效后域名即为活动状态；推荐记录可单独显示。

对于可自行检查的记录，请在终端（Mac/Linux/WSL）使用：

dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short TXT dkim._domainkey.yourdomain.com
dig +short CNAME mta-sts.yourdomain.com

将输出与控制面板中自己域名的值比较。不要从示例复制 DKIM 密钥、MTA-STS 政策 ID 或其他域名专属值。

DNS 提供商的常见问题

• Cloudflare：邮件 CNAME 必须为仅 DNS。提供商可能隐藏 CNAME 目标末尾的点；请比较解析后的目标，不要添加重复的点。
• **GoDaddy：**域名根部使用 @，DMARC 主机使用 _dmarc。GoDaddy 会自动附加域名。
• **Namecheap：**仅当 Namecheap 是权威 DNS 提供商时，才在 Advanced DNS 中添加记录。根部使用 @。
• **Route 53：**选择实际连接域名的托管区域，然后粘贴控制面板的完整值。
• **网站构建服务和注册商：**域名购买处不一定控制 DNS。检查名称服务器，并在真正负责 DNS 的提供商处编辑。

全部正确但仍显示红色

如果控制面板和独立公共查询显示相同的必需记录，但 TrekMail 仍报告不匹配，请提交支持工单并提供：

• 您的域名。
• 受影响记录的公共查询结果。
• 查看冲突面板的屏幕截图（如果有）。

不要提供帐户密码、邮箱密码、恢复代码或访问令牌。