🌐 DNS 域名配置 FAQ — 邮件域名与发信策略

按优先级分为三层：第一层（必做—不发信则被拦截）、第二层（强推荐—显著改善到达率）、第三层（进阶—品牌保护与安全加固）。以下是完整 9 项清单：

第一层：必做基础
① MX 记录：指定邮件接收服务器，优先级数字越小越优先（RFC 5321 Section 5.1）；
② SPF TXT 记录：声明哪些 IP/主机有权代表本域发信（RFC 7208）；
③ PTR 反向 DNS（rDNS）：发信 IP 的反向解析需指向一个有正向 A 记录的主机名（RFC 5321 Section 3.6），多数大型邮件系统（Gmail、Outlook 等）要求发信 IP 有 PTR 否则拒收或加分到垃圾邮件；
④ A / AAAA 记录：邮件服务器主机名必须能正向解析到发信 IP。

第二层：强推荐
⑤ DKIM TXT 记录：公钥发布在 <selector>._domainkey.<domain>，用于接收方验证邮件签名（RFC 6376）；
⑥ DMARC TXT 记录：发布在 _dmarc.<domain>，至少设置 p=none; rua=mailto:dmarc@example.com 以开始接收聚合报告（RFC 7489）；
⑦ MTA-STS 记录（_mta-sts.<domain>. IN TXT "v=STSv1; id=..."）+ HTTPS 策略文件：强制收件服务器用 TLS 连接本域（RFC 8461）。

第三层：进阶
⑧ BIMI TXT 记录（default._bimi.<domain>）：品牌标识显示支持（RFC 8617 草案系列）；
⑨ TLS-RPT 记录（_smtp._tls.<domain>. IN TXT "v=TLSRPTv1; rua=..."）：接收 TLS 投递失败报告（RFC 8460），尽早发现证书和加密配置问题。

Step 1 — TTL 预降（切换前 ≥24 小时）：将当前 MX 记录的 TTL 从默认（3600 秒或更高）降至 300 秒（5 分钟）。这一步确保切换时所有递归 DNS 缓存快速过期，发件方 MTA 能尽快获取新 MX 记录。验证命令：dig MX example.com +noall +answer 确认 TTL 已变化。

Step 2 — 添加新 MX（更高优先级）：在原 MX 记录基础上，新增目标邮件系统的 MX 记录，并设为更低优先级值（更高优先级）。例如：原有 MX 10 mail.old.com，新增 MX 5 mail.new.com。此时发件方 MTA 会优先往新系统投递，新系统不可达时才回退到旧系统。

Step 3 — 队列缓存期（24-48 小时）：DNS 传播 + 旧系统队列排空。在这期间：(1) 新系统正常接收新邮件；(2) 旧系统继续将已在队列中的邮件投递到用户邮箱；(3) 监控两套系统的 SMTP 连接日志，确保新系统正在接收 >90% 的新入站邮件。

Step 4 — 双跑确认后下掉旧 MX：确认旧系统队列为空且新系统稳定运行 ≥24 小时后，从 DNS 中删除旧 MX 记录，只保留新系统 MX。建议保留旧系统的 IMAP 服务在线 7-14 天，供用户通过客户端手动迁移历史邮件。

Step 5 — TTL 恢复：将新 MX 记录的 TTL 恢复为正常值（建议 3600 秒），记录迁移时间戳。

核心原则：信誉隔离。邮件发送信誉（Sender Reputation）是以域为粒度的。如果你用一个主域同时发送企业邮件、营销促销邮件和系统通知，一旦营销邮件被大量举报为垃圾邮件，企业邮件也会受到影响。

推荐策略——按功能划分子域：
@example.com — 企业员工日常邮件（最高优先级，严格管控）
@newsletter.example.com — 营销/促销邮件（允许适量退订和投诉）
@transactional.example.com — 系统通知/密码重置/订单确认（事务邮件，打开率和信誉通常最高）
@bounces.example.com — 退信处理专用域

子域部署细节：每个子域需要有独立的 SPF、DKIM、DMARC 记录（DMARC 可通过主域的 sp= 标签统一定义子域策略）。子域的 SPF 记录应极简——通常只包含该功能对应发信服务的 include，DNS 查询不超过 3 次。

方法一：include 串联——最常用。将每个邮件服务商的 SPF 记录域通过 include: 串联起来。例如：同时使用自建 MTA、系统通知服务、营销邮件平台的场景：

example.com.  IN  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.notify-provider.com include:_spf.marketing-platform.com -all"

致命陷阱：10 次 DNS 查询限制。RFC 7208 Section 4.6.4 规定 SPF 评估过程中的 DNS 查询总数不得超过 10 次——include 链的所有 DNS 查询全部计入。如果 include:_spf.notify-provider.com 内部又引用了 3 个 include，那就已经消耗了至少 4 次查询。建议每次新增服务商前，先用在线 SPF 检查工具展开并审计当前 DNS 查询次数。

方法二（DNS 查询超限时）：扁平化。如果 include 过多导致超限，解决方法是将所有服务商的授权 IP 列表手动展开为 ip4:/ip6: CIDR 直接写入 SPF 记录。这需要定期人工或脚本同步服务商的 IP 变更，但彻底消除了 DNS 查询压力。

方法三（推荐）：子域隔离——将不同发信功能分配到不同子域，每个子域独立维护短 SPF 记录。主域设置 v=spf1 -all，杜绝主域直发。详见 FAQ-13。

阶段一 — p=none（监控期，≥2 周）： _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-f@example.com; fo=1"
不拒绝任何邮件，只收集报告。用 DMARC 报告分析工具（如 parsedmarc 开源工具）分析 RUA 聚合报告，确认：(1) 所有合法发信源都能通过 DMARC 对齐；(2) 找出所有未授权但仍在发信的第三方；(3) 排除误伤。

阶段二 — p=quarantine（隔离期，≥2 周）： _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-f@example.com; fo=1"
先设置 pct=25（仅 25% 的失败邮件进入隔离），逐步调至 50 → 75 → 100。监控用户投诉量——如果投诉无明显上升，方可进入下一阶段。RFC 7489 定义 pct 为百分比标签，接收方对指定比例的失败邮件执行策略。

阶段三 — p=reject（最终态）： _dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; fo=1"
所有 DMARC 失败的邮件被接收方拒绝（不投递）。同时设置子域策略 sp=reject 保护子域。保持 rua 报告接收，持续监控是否有异常。

关键提醒：从 none 到 reject 不要跳跃式执行。每次策略变更后至少观察 2 周并分析报告，确认无误再推进。如果过程中发现大量合法邮件失败——说明 SPF/DKIM 配置仍有遗漏，回退到上一阶段继续修复，而非强行推进。