DNS 记录类型速查（解析与邮箱配置）

1常见记录类型对照

同一个域名下可以并存多种类型的记录，各自回答不同的问题，互不干扰（CNAME 是例外，见下一节）。

2TTL：缓存多久才合适

TTL（Time To Live）是「这条记录允许被各级 DNS 缓存多少秒」。它是可用性与变更速度之间的取舍，没有唯一正确答案。

TTL 越长

解析查询越少、响应越快、更省服务商的查询额度；但记录变更后，全球生效要等旧缓存过期

TTL 越短

变更传播快，适合迁移期；但查询次数上升，解析服务商的免费额度消耗更快

常见取值

稳定性优先用 3600 到 86400 秒（1 小时到 1 天）；发布迁移前提前把 TTL 降到 300 秒，迁移完成后再调回去

本地缓存干扰排查

改了记录但自己看还是旧的，先清本地 DNS 缓存（Windows 用 ipconfig /flushdns，macOS 重启 mDNSResponder），或直接用运营商之外的公共 DNS 复查

生效时间的上限

理论上是「旧 TTL 剩余时间」，实际操作中还会受各级缓存与客户端缓存影响，所以迁移务必预留至少一整个旧 TTL 的窗口

3CNAME 的两条硬限制

CNAME 是最容易用错的一类记录，限制来自规范本身：一个名字如果被声明成别名，就不能再有自己的其它记录。

限制一：不能与其它记录共存

如果 www 设了 CNAME，就不能再给 www 配 A、MX、TXT 等任何记录。因为「别名」的语义是「我的一切都跟另一个名字走」，再挂别的记录就自相矛盾了

限制二：根域名（裸域）不能设 CNAME

example.com 本身必须要有 SOA 和 NS 记录，而 CNAME 不允许与它们共存。所以「把裸域指向 CDN / 托管平台」这件事，标准 CNAME 做不到

替代方案

部分云解析商提供 ALIAS / ANAME 这类非标准记录，作用类似 CNAME 但只在解析时展开，能在根域名上使用；否则只能让平台给出固定 A 记录

邮件与 CNAME 的冲突

若在根域名上误设 CNAME，会导致所有邮件记录失效——这是「网站正常但收不到邮件」的典型原因之一

4邮箱配置：SPF / DKIM / DMARC 三条记录

这三条都是 TXT 记录（DKIM 有时使用专门的子域名），分别解决「谁可以替我发信」「这封信有没有被篡改」「收信方该怎么处理可疑邮件」。三条配合，邮件才不容易进垃圾箱。

SPF 的结尾 `-all` 表示「未列出的服务器一律拒绝」，比 `~all`（软失败，仅标记）更严格。新上线建议先用 `~all` 观察一段时间，确认没有遗漏的发信源，再收紧成 `-all`。

5常用的公共 DNS 服务

排查解析问题时，换一个公共 DNS 往往能快速区分「是本地网络的问题」还是「记录本身填错了」。

DNS 缓存与 DNS 劫持是两个不同的问题：前者改记录后短暂不生效，后者是解析结果被篡改。启用 DNSSEC 或改用可信的加密 DNS（DoH / DoT）能缓解劫持问题，但不改变缓存行为。