自动配置邮件DNS：单域名一键授权，多域名使用令牌

邮件的DNS配置通常涉及六七条记录，其中几条包含很长的字符串。一个字符写错，就可能导致看起来与拼写无关的故障。DKIM密钥的base64内容长达数百个字符。SPF记录由一组机制组成，顺序有影响，末尾的机制也会改变策略含义。DMARC使用特定的子域名，第一次配置时很容易填错。

只配置一个域名，大概不会出问题。管理四十个客户域名时，漏掉错误的可能性就高了。也许过了一个月，客户的账单落入垃圾邮件，你才发现配置有误。

自动配置省去了手动复制这些值的步骤。可以选择两种方式：针对单个域名，在DNS服务商处授权修改后返回TrekMail，无须提供令牌；或者使用权限受限的API令牌，分批配置上百个域名。两种方式都允许你在应用前检查拟议变更。

邮件需要哪些DNS记录

“许多发送场景需要”不代表RFC要求所有域名都必须公布DKIM和DMARC。Google和Yahoo在2024年引入了针对大批量发件人的要求，具体适用哪些规则，取决于发件人类别和现行规定。企业收件系统也可能有自己的要求。缺少这些记录并不意味着完全无法发送邮件，但可能影响身份验证和邮件接收。

手动配置DNS的四种常见错误

公布两条SPF记录。这是常见且影响较大的错误。被检查的名称下只能有一条SPF记录。为了新发送服务再加一条，并不会扩展原策略；符合协议的验证会返回permerror。应把机制合并到一条记录中。参见SPF记录示例。

粘贴时损坏DKIM密钥。2048位密钥的文本表示超过了每个TXT字符串255字符的限制，因此一条记录需要包含多个字符串，读取时再将它们连接起来。有些DNS控制面板会自动处理，有些要求用户准备好分段，还有些可能截断内容。密钥不完整会导致签名验证失败，而原因不一定明显。

DMARC名称填错。记录应放在_dmarc.example.com。如果放在域名根部，收件服务器查询该域名的DMARC策略时就找不到它。

超过SPF查询上限。SPF在一次验证中允许使用的、需要DNS查询的项最多为十个。每个被求值的include:都计入其中，嵌套包含的项也要计算。邮件服务商、CRM、营销工具和客服系统可能合计超限，具体取决于各自的策略。超限时结果为permerror。这种问题可能在首次配置数月后、又加入一个工具时出现。参见SPF的DNS查询上限。

自动化可以减少复制错误并发现冲突，但不能代替检查。合并SPF避免了新增第二条记录，却不能证明最终策略符合验证上限。

方式1：一键配置DNS，无须令牌

如果域名的DNS由Cloudflare托管，这是直接的配置方式。你无须向TrekMail提供API令牌或账户登录凭据。

1. 打开域名的DNS与状态标签页。
2. 点击自动配置DNS。
3. Cloudflare会在授权前显示拟议的记录变更。
4. 点击授权。
5. 返回TrekMail后，系统会请求验证。仅仅返回页面，并不能证明记录已经正确公布。

这个流程使用Domain Connect开放协议：服务描述所需记录，DNS服务商向域名所有者展示变更，再由所有者批准。流程不会创建或保存可重复使用的API令牌。授权针对的是该域名上提出的这次操作。

域名的名称服务器必须指向Cloudflare。如果域名只是注册在Cloudflare，而DNS由其他服务商托管，这种方式就不可用。记录必须在实际托管DNS区域的服务商处修改。

方式2：通过权限受限的API令牌配置DNS

需要配置多个域名，或无法使用Domain Connect时，可以通过令牌配置账户中获授权的DNS区域。

在Cloudflare中使用Edit zone DNS模板创建令牌，权限为Zone → DNS → Edit。在区域资源中，选择All zones开放所有区域，或选择Specific zone限制范围。检查IP限制和有效期是否允许预期用途，没有必要无故修改这些设置。令牌显示时将其复制，再粘贴到TrekMail中。

关键在于了解这些权限允许做什么，以及不允许做什么：

TrekMail以加密形式保存令牌，并避免将令牌值写入日志。你可以在TrekMail中断开某个域名的令牌连接，或在Cloudflare中撤销令牌，阻止之后使用它发起请求。断开一个域名，并不一定会撤销其他域名共同使用的令牌。撤销也不会恢复已经修改的记录。

连接后，系统会列出可用的Cloudflare区域及预期操作：对于已加入TrekMail账户的域名，显示配置DNS；需要在同一流程中添加并配置的域名，显示添加 + DNS。DNS托管在Cloudflare之外的域名，不会作为该集成可配置的区域显示。

变更预览与五种状态

应用配置之前，你可以逐条检查记录。预览使用五种状态：

每条记录都有复选框。可以先应用MX和SPF，之后再配置DKIM，也可以排除由其他方式管理的记录。未勾选的记录不会在这次操作中应用。

遇到冲突时应认真阅读，不要直接确认。DMARC策略p=none并没有错，它可能是有意设置的观察阶段。在查看报告之前将其替换为p=quarantine，可能影响尚未正确通过身份验证的合法邮件。必要时保留原策略，完成部署后再收紧。具体思路见如何选择DMARC策略。

为什么要合并现有SPF记录

SPF需要特别注意，因为同一条策略可以授权多个发送服务。未检查这些服务就替换记录，可能会删除仍然需要的授权。

假设域名已经公布：

v=spf1 include:_spf.google.com ~all

这条策略授权Google的基础设施，例如Workspace或通过它发送邮件的工具。改成只包含TrekMail的记录，不只是增加发件服务，也会移除之前的授权。依赖该授权的邮件随后可能无法通过SPF。

因此，有效的现有SPF记录通常会进行合并：

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

两个服务仍在同一条记录中获授权，末尾的限定符也得到保留。这样可以添加TrekMail而不移除原授权。但不能据此说“永远不会替换”：重复或格式错误的SPF记录可能需要解决冲突，最终策略也必须检查。

之后要检查两件事。新增的include:计入十个需要DNS查询的项的上限，也可能触发嵌套查询，因此应评估整条策略。如果旧服务商确实不再为域名发送邮件，确认后再手动移除它的授权。一段时间没有活动，并不能证明该服务已经停用。

批量配置DNS

令牌获授权访问所有区域时，向导可以处理兼容的域名，添加新域名、配置记录，并逐域名显示结果。每批最多50个域名。新加入的域名计入套餐上限：Nano为10，Starter为50，Pro为100，Agency为1,000。这些是原文描述的配置，开始前应确认账户当前的实际限制。

代理商接入拥有一打域名的客户时，批量操作可以节省不少手动工作，也让预览更重要。设想十二个域名中，两个存在DMARC策略冲突，一个的autodiscover CNAME仍指向2023年已离开的服务商。这只是说明该查找哪些遗留配置，并非保证会以这种频率出现。

变更的影响范围

在赋予应用DNS写入权限之前，询问影响范围很合理。

该集成设计上管理的是邮件记录：MX、SPF、DKIM、DMARC、MTA-STS、TLS-RPT及邮件自动配置所需的CNAME。它不应修改A记录、网站CNAME或其他服务的TXT。但令牌的DNS编辑权限覆盖获授权区域内的记录，不仅限于邮件记录。其他记录能否保持不变，还取决于应用的行为。这里描述的权限不允许修改名称服务器。

替换冲突记录可能移除旧配置，因此需要确认。还应检查其他变更，以及某次操作中可能执行的重复记录清理，不能认为其余操作都没有影响。如果需要恢复能力，应保存原来的记录值。

待验证状态可能来自DNS缓存，也可能是记录错误或操作未完成。原文提到最长48小时，但这不是通用期限，TTL和服务商的实际情况都会影响可见时间。系统会自动重复验证，点击验证DNS也可以请求再次检查。如果第二天仍失败，应检查实际公布的记录；若涉及签名，再参考DKIM故障排查。

常见问题

一键配置需要Cloudflare账户吗？

域名DNS必须由Cloudflare托管，你也需要有权访问相应账户来授权变更。无须把API令牌交给TrekMail：在Cloudflare界面批准操作即可，流程不会保存可重复使用的令牌。

如果DNS不在Cloudflare呢？

这项自动集成不会配置其他服务商，需要手动创建记录。域名DNS页面会列出值并提供复制按钮；各服务商的操作步骤见常见服务商的DNS配置指南。

自动配置DNS会影响网站吗？

该集成设计上只修改邮件记录，保留A记录、网站CNAME和与邮件无关的TXT。这并不意味着令牌技术上无法编辑它们：令牌权限覆盖获授权区域内的DNS记录。应检查拟议变更。这里描述的权限不允许更改名称服务器。

现有SPF记录会怎样处理？

通常会合并，加入TrekMail的include并保留限定符，避免误删其他发送服务的授权。重复或格式错误的SPF可能需要确认替换，也应检查最终策略的查询上限。

可以只应用部分记录吗？

可以。预览中每条记录都有复选框。由其他方式管理的记录可以取消勾选，从此次操作中排除。

一次可以配置多少个域名？

每批最多50个，同时受套餐的域名总数限制。向导新增的域名也计入该上限。

API令牌有保护吗？

TrekMail加密保存令牌，并避免记录其值。按本文描述的权限，令牌可以编辑所选区域的DNS，但不能管理账单、WAF、名称服务器或域名转移。可在Cloudflare撤销令牌以阻止后续请求；这不会恢复此前的变更。只授权实际需要的区域。

为什么从未创建过的记录显示“已配置”？

可能是以前的服务商创建的，也可能已经执行过一次获授权的配置。将当前值与拟议值比较。如果相同，就不必替换，但仍应确认它符合当前配置。