DNS记录类型参考指南
汇总运行邮件和网站所需的DNS记录类型——A、MX、TXT、SPF、DKIM、DMARC等——并说明每种记录的用途、格式示例与注意事项。
| 类型 | 用途 | 格式示例 | 注意事项 |
|---|---|---|---|
| A记录 | 最基本的记录类型，将域名映射到IPv4地址，指出Web服务器或邮件服务器的实际所在位置。 | example.com. 3600 IN A 192.0.2.1 |
TTL（此例中为3600秒，即1小时）设置过短会增加对权威DNS服务器的查询次数、加重负载；设置过长则会延迟IP地址变更后的生效时间。 |
| AAAA记录 | 将域名映射到IPv6地址，相当于A记录的IPv6版本。 | example.com. 3600 IN AAAA 2001:db8::1 |
同时保留A记录可以让不支持IPv6的网络回退到IPv4连接（双栈运行）。 |
| CNAME记录 | 将一个主机名指向另一个规范主机名作为别名，例如将 www.example.com 指向 example.com。 | www.example.com. 3600 IN CNAME example.com. |
设置了CNAME的主机名不能再共存其他记录（如MX、TXT，这是RFC 1034的限制）。域名根（@）也不能设置CNAME。 |
| MX记录 | 指定该域名的邮件应由哪台邮件服务器接收，可通过优先级（preference值）指定多台服务器。 | example.com. 3600 IN MX 10 mail.example.com. |
数值越小优先级越高。为实现冗余，通常会设置多个不同优先级的服务器。MX指向的必须是拥有A记录的主机名，而不能是CNAME。 |
| TXT记录 | 为域名附加任意文本信息的通用记录，常用于SPF、DKIM、DMARC，以及域名所有权验证等多种用途。 | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
一个域名可以设置多条TXT记录，但同一用途（如SPF）的记录若重复设置会导致解析错误，需要合并为一条。 |
| SPF记录（TXT记录的一种） | 列出被允许代表该域名发送邮件的服务器（IP地址），是一种防止邮件伪造的发件人认证机制，以TXT记录的形式配置。 | example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all" |
每个域名只能有一条有效的SPF记录。DNS查询次数上限为10次，超过会导致永久性错误，需注意include的嵌套层数。专用的记录类型（RRTYPE 99）已于2014年废弃，如今统一使用TXT记录表示SPF。 |
| DKIM记录（TXT记录的一种） | 为邮件附加数字签名，用以验证邮件在传输过程中未被篡改、且确实来自合法发件人。公钥以TXT记录形式公开。 | selector._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..." |
主机名前缀（选择器selector）因发件服务商而异。私钥保存在发送服务器一侧，DNS中只公开公钥。 |
| DMARC记录（TXT记录的一种） | 基于SPF和DKIM的验证结果，声明对认证失败的邮件应如何处理（放行、隔离或拒收），并提供接收汇总报告的渠道。 | _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]" |
建议先以 p=none 仅进行监控，确认没有问题后再逐步提升到 quarantine、reject，这是较为安全的部署方式。 |
| NS记录 | 标明该域名（区域）的权威DNS服务器是哪些，是整个域名解析的起点。 | example.com. 86400 IN NS ns1.example-dns.com. |
如果在注册商处登记的域名服务器与区域内的NS记录不一致，会导致名称解析不稳定（称为“跛脚委派”，lame delegation）。 |
| SOA记录 | 保存区域的管理信息（主服务器、管理员邮箱、序列号、重试间隔等），每个区域必须且只能有一条。 | example.com. 86400 IN SOA ns1.example-dns.com. admin.example.com. (2026071200 3600 900 604800 86400) |
更新区域文件后必须递增序列号，否则从服务器不会通过区域传送获取到变更内容。 |
| CAA记录 | 限制哪些证书颁发机构（CA）可以为该域名签发证书，防止非预期的CA签发出恶意证书。 | example.com. 3600 IN CAA 0 issue "letsencrypt.org" |
如果域名没有任何CAA记录，则视为任何CA都可以签发证书。通配符证书需要另外指定 issuewild 标签。 |
| PTR记录 | 通过IP地址反查主机名（与A记录方向相反），配置在反向解析区域（in-addr.arpa / ip6.arpa）中。 | 1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com. |
许多邮件服务器会将反向PTR未设置或与A记录不一致的来源邮件标记为垃圾邮件或直接拒收，因此这几乎是发件服务器的必备配置。 |
DNS 记录的种类与各自的用处一览
这是一份参考清单，把网站运营与邮件投递所需的 DNS 记录——A、AAAA、CNAME、MX、TXT、SPF、DKIM、DMARC——连同各自的用处、格式示例与当心之处一并罗列。拿不准该写哪条记录、写在何处时，来此一查便是。
**此处最不为人知的陷阱，是 CNAME 不能置于区域的顶点，也就是 `example.com` 本身。** CNAME 宣告某个名称是别名，故同一名称之下再容不下别的记录。可顶点又非有 NS 与 SOA 不可，**于是想用 CNAME 把 `example.com` 指向 CDN，按规格便是办不到的。** 许多服务商以 ALIAS 或 ANAME 这类自有记录绕开此事。**另一件要弄明白的是 TTL，它言明各解析器可将一个答案缓存多少秒。** 若有迁移在即，通行的做法是**在动手数日之前先把 TTL 调短。**
使用方法
- 找到您所需的记录种类 各条按类型归拢：A、MX、TXT 等等。
- 查看格式的示例 **最容易写错之处——主机名怎么写、末尾该不该带点——都可在此核对。**
- 阅读当心之处 **其中列出了实务中真正会绊人的地方：CNAME 的限制、TTL 的处置等等。**
- 用相关工具去验证 设好之后，便可去查传播情况，或诊断认证类记录。
用好本工具的小技巧
- 如果对SPF、DKIM、DMARC的配置感到困惑，建议先用“SPF/DKIM/DMARC记录检测”工具诊断当前记录，再与本页的格式示例对照，效率更高。
- 普通记录的TTL设为1小时（3600秒）左右较为稳妥；仅在DNS迁移前夕临时缩短到300秒左右，切换后再恢复，可以让生效更快。
- TXT记录的值超过255个字符时可能会被自动拆分为多个字符串，复制粘贴时请确认引号数量是否正确。
- 如果还想检查邮箱地址本身的格式是否正确，可以配合使用“邮箱地址格式验证”工具，避免遗漏。
- 引入新的邮件发送服务时，建议先以 p=none 运行DMARC并观察1〜2周的报告，确认无异常后再切换到正式的执行策略，更为稳妥。
这些场景会用到
新设一个域名
**可弄清最起码需要哪几条记录。**
添一处发信来源
需要补写 SPF 或 DKIM 时，可在此核对格式。
迁移服务器
**可以明白为何应在迁移之前先把 TTL 调低。**
查一个术语的意思
设置界面上那些字段名的含义，当场便查得到。
DNS 记录的术语
- A 记录
- 把主机名对应到 IPv4 地址。AAAA 记录则是它的 IPv6 对应物。
- CNAME 记录
- 使某个名称成为另一名称的别名。**因同名之下不容别的记录，故不可用于区域的顶点。**
- MX 记录
- 指明由哪台服务器接收该域名的邮件。优先级的数字越小，越先被尝试。
- TXT 记录
- 可容纳任意文本的记录。**SPF、DKIM 与 DMARC 皆以此形写就。**
- TTL
- 各解析器可将一个答案缓存的秒数。**迁移之前把它调短，变更便能迅速散开。**
- 区域的顶点
- 不带 `www` 之类前缀的域名本身，即 `example.com`。**此处放不得 CNAME。**
常见问题
闲话 ― DNS记录与邮件认证的历史
DNS通常被理解为将域名映射到IP地址的机制，但实际上除了A、AAAA记录之外还定义了许多其他类型，各自承担不同的角色。尤其在邮件传输领域，MX、TXT（承载SPF/DKIM/DMARC）、PTR等多条记录必须协同工作，才能判定一封邮件是“未被伪造的合法邮件”，只要缺少其中一项，被归入垃圾邮件文件夹或被拒收的风险就会显著上升。
回顾发件人认证的历史，SPF在21世纪初作为反垃圾邮件的对策被提出，随后以检测邮件内容是否被篡改为目的的DKIM于2007年前后被标准化。然而两者各自都没有规定“认证失败后应如何处理”，为了填补这一空白，DMARC于2012年诞生。DMARC综合评估SPF与DKIM的结果，提供失败时的处理策略以及结果报告机制，可以说是认证体系的“指挥中枢”。
部分DNS记录因历史原因经历过规格变化。例如专用于SPF的记录类型（RRTYPE 99）曾在2006年的RFC中被定义过一次，但因引发实现上的混乱，已于2014年由RFC 7208正式废弃，如今统一只用TXT记录来表示SPF。同样，DKIM和DMARC也没有专属的记录类型，全部以特定格式（以 v=DKIM1、v=DMARC1 开头的字符串）嵌入TXT记录之中，这也体现了DNS极高的可扩展性。