什么是 CNAME 记录？
CNAME（Canonical Name，规范名称）是一种 DNS 记录，将别名主机名映射到规范主机名。解析器查找别名时，会沿着记录链条一直追到规范目标上的 A 或 AAAA 记录，然后返回背后的 IP 地址。这使 CNAME 成为将子域名委托给第三方服务时的标准方式，无需暴露或硬编码对方 IP。
CNAME 在现代邮件和 Web 运维中至关重要：CDN 发布不断变化的 IP，只有 CNAME 才能干净地跟随；DKIM-as-a-Service 厂商需要通过 CNAME 委托选择器密钥；SaaS 平台用它来品牌化面向客户的端点。该标准在 RFC 1034 和 RFC 2181 中定义。
为什么要检查 CNAME 记录？
1尽早发现失效别名
服务商重命名或下线主机时，您的 CNAME 会静默失效，只有检查器才能发现
2确认 DKIM 与 BIMI 委托
两者都依赖指向服务商记录的 CNAME——确认整条链路能完整解析
3避免记录冲突
CNAME 不能与其他记录共用同一名称。检查器会立即指出冲突
4审查迁移切换
将自定义域名重新指向新的 SaaS 后，先核实规范目标再对外通告变更
CNAME 解析流程——逐步说明
您的 DNS 服务商发布一条 CNAME，将别名（如 `www.example.com`）指向规范目标（`example.com` 或服务商主机）。
客户端查询别名，解析器返回该 CNAME 并继续查询规范目标。
若目标本身仍是 CNAME，解析器会继续跟随链路——多数实现允许最多约 8 跳后放弃。
解析器找到 A 或 AAAA 记录后，将该 IP 返回给原始客户端。
完整链路（别名 → 中间别名 → A 记录）在每一跳按照 TTL 进行缓存。
CNAME 记录语法
www.example.com. 300 IN CNAME example.com.字段说明
别名— 进行委托的主机名TTL— 缓存生存时间（秒），300 = 5 分钟IN— Internet 记录类别CNAME— 记录类型目标— 规范主机名（必须以点结尾）常见 CNAME 故障与修复
在根域 (apex) 上使用 CNAME
根域不能承载 CNAME——请使用 DNS 服务商提供的 ALIAS 或 ANAME 记录
CNAME 与其他记录并存
RFC 1034 禁止同名记录上同时存在 CNAME 与 MX/TXT/A——请把记录拆分到不同名称
悬空目标
若规范目标已不存在，解析器会返回 NXDOMAIN——请改指向有效目标
链路过长
超过 8 跳会被部分解析器放弃——直接指向最终目标，拉平链路
常见问题解答
CNAME（Canonical Name，规范名称）是一种 DNS 记录，将一个主机名映射到另一个主机名。它并不直接指向 IP 地址，而是让该主机名成为规范目标的别名，因此规范目标的 A 或 AAAA 记录一旦更新，所有别名将自动同步。CNAME 常用于 www 子域名、CDN 端点、SaaS 自定义域名以及 DKIM 与 DMARC 报告等邮件认证委托。
现代邮件认证依赖通过 CNAME 委托的 DKIM 密钥与 BIMI（Branded Indicators for Message Identification）。若 DKIM 选择器或 BIMI 标识 URL 对应的 CNAME 失效，接收方可能下调信任分数并将邮件投入垃圾箱。CNAME 检查器可确认别名能干净地解析至预期目标，使签名与品牌指示器从头到尾保持有效。
当一个别名指向另一个别名再到达 A 记录时，就会形成 CNAME 链路。多数解析器能透明地跟随链路，但每多一跳都会增加延迟、放大配置错误的风险，并可能让仅跟随一层的校验器失效。检查器会显示每一跳，便于您拉平多余的链路。
严格意义上不行——RFC 1034 禁止 CNAME 与其他记录并存，且根域必须保留 SOA 与 NS 记录。一些 DNS 服务商提供 ALIAS、ANAME 或扁平化的 CNAME-at-apex 能力，会基于目标合成一条 A 记录。即便您使用这些方案，本检查器仍可验证解析所得的 IP 是否按预期工作。
结果为空通常表示 CNAME 尚未发布、被添加到了错误的子域名，或目标拼写有误。DNS 传播可能需要长达 48 小时，但多数现代服务商在几分钟内即可生效。请先在 DNS 面板中确认记录存在，然后重新查询。
请检查 CNAME 是否指向您服务商指定的确切目标，没有拼写错误或多余的结尾点，并且您没有在已有其他条目的记录上设置 CNAME，这是 DNS 所禁止的。在您的 DNS 设置中更正目标，留出传播时间，然后重新检查。