DNS查询怎么查？A、CNAME、MX、TXT记录怎么看

DNS 查询是排查域名解析、网站访问和企业邮箱问题最常用的方法之一。本文将介绍 DNS 查询的基本操作，并重点讲解 A、CNAME、MX、TXT 四类常见记录的作用、查询方法和结果判断，帮助站长快速确认域名是否正确解析到服务器、CDN 是否生效，以及邮箱和域名验证配置是否正常。

Chahu 团队2026-08-245 分钟阅读

网站突然打不开、域名刚改完解析却一直不生效、CDN 已经接入但不知道有没有真正切过去，或者企业邮箱配置完成后还是收不到邮件，这些问题看起来各不相同，实际排查时往往都绕不开同一个环节：DNS 查询。通过DNS 查询能够确认一个域名当前到底返回了什么解析结果。网站常见的 A、CNAME 记录，企业邮箱常用的 MX、TXT 记录，都可以通过 DNS 查询看到。

对站长来说，真正重要的并不是记住所有 DNS 术语，而是弄清楚一件事：查到这些记录之后，该怎么看结果是否正常。本文就从实际排查角度出发，讲清楚 DNS 怎么查，以及 A、CNAME、MX、TXT 这几种常见记录分别应该怎么看。

一、DNS查询到底是在查什么？

平时我们访问一个网站时，浏览器并不是直接通过example.com这样的域名找到服务器。在真正发起连接之前，需要先经过 DNS，把域名转换成服务器能够识别的地址，或者找到下一步应该访问的服务目标。一个最简单的过程大致是：

输入域名
↓
DNS查询
↓
获取解析记录
↓
找到对应服务器或服务地址
↓
建立连接

所以，当网站访问异常时，DNS 是一个非常适合优先检查的位置。比如你刚把网站从旧服务器迁移到了新服务器，如果 DNS 仍然返回旧 IP，那么不管新服务器配置得多完善，用户还是会继续访问旧环境。

类似的问题还包括：

CDN 已经配置，但域名仍然没有指向 CDN CNAME
企业邮箱的 MX 记录写错，外部邮件无法投递
TXT 验证记录没有正确发布，第三方平台一直提示验证失败
DNS 修改后部分地区仍然返回旧记录

这些情况，都可以先通过 DNS 查询确认当前对外生效的记录。

二、DNS查询怎么查？

想查某个域名的解析对不对，最省事的方法就是通过chahu DNS 查询工具。直接把域名扔进去，分分钟就能出结果。

整个过程其实就几步：

输入域名 ➔ 选择记录类型（比如 A、CNAME） ➔ 提交查询 ➔ 盯着返回的 IP、邮局解析（MX）或者 TXT 记录看看对不对。

不过新手最容易在两个小细节上踩坑：

第一，别把一整串网址直接粘贴进去。 DNS 查的是域名本身，比如 [www.example.com](https://www.example.com) 就够了。千万别带上前面的 https:// 或者后面的路径 /product/123，那些是网页地址，DNS 可不管这些。

第二，带 www 和不带 www 是两码事。 example.com（根域名）和 [www.example.com](https://www.example.com) 在 DNS 里很可能是分开配置的。比如根域名直接绑了服务器 IP，而带有 www 的那个反而加了 CDN 或是挂了 CNAME。你的网站平时是用哪个地址访问的，就查哪个，别只查个根域名就以为万事大吉了。

三、A记录怎么看？

A 记录是网站 DNS 配置中最常见的一种记录。它的作用是把域名解析到一个 IPv4 地址。比如：

www.example.com
↓
203.0.113.20

当用户访问www.example.com时，DNS 返回203.0.113.20，浏览器随后再去连接这个 IP 对应的服务器。

查询A记录时，最重要的是看IP是否正确

假设网站刚换了一台服务器，新服务器 IP 是：203.0.113.20。但 DNS 查询结果仍然显示：198.51.100.15。这说明当前对外解析仍然指向旧服务器。这时应该继续检查：

DNS 记录是否真的修改成功
是否修改到了正确的 DNS 服务商
TTL 缓存是否还未过期
查询的主机名是否正确

如果查询结果已经变成了新 IP，那么 DNS 层面基本已经切换完成，后续可以继续排查服务器、网站程序或者缓存。

一个域名出现多个A记录正常吗？

正常。有些网站为了做负载均衡、容灾或者 DNS 轮询，会同时返回多个 IP。例如：

203.0.113.20
203.0.113.21
203.0.113.22

看到多个 A 记录并不代表解析错误。真正需要确认的是：这些 IP 是否都属于你的业务架构，是否存在已经停用却仍然保留的旧地址。

四、CNAME记录怎么看？

CNAME 和 A 记录最大的不同，在于它通常不是直接指向 IP，而是指向另一个域名。

例如：

www.example.com
↓
abc123.cdn.example.net
↓
CDN节点IP

这类配置在 CDN、SaaS 平台、云服务和第三方托管服务里非常常见。

为什么CDN经常使用CNAME？

因为 CDN 节点 IP 并不是固定不变的。服务商可以根据用户位置、网络状态和节点负载，把同一个 CNAME 动态调度到不同的边缘节点。如果用户直接写死一个 A 记录，就很难实现这种灵活调度。所以接入 CDN 时，经常会看到服务商要求添加类似：

www.example.com
CNAME
abc123.provider.net

怎么判断CNAME是否已经生效？

最直接的方法，就是查询实际业务域名。假设 CDN 后台要求配置：

www.example.com
CNAME
abc123.provider.net

那么 DNS 查询结果中应该能够看到对应的 CNAME 目标。如果仍然显示旧记录，或者完全查询不到 CNAME，就说明 DNS 切换可能还没有真正完成。

常见原因包括：

DNS 修改后缓存还没有更新
CNAME 主机记录填写错误
域名实际使用的是另一家 DNS 托管服务
原有解析规则存在冲突
修改了根域名，但实际访问的是www

接入 CDN 后，不建议只看控制台里显示“配置成功”。

更稳妥的做法，是直接查询实际业务域名，确认公开 DNS 返回结果是否已经指向 CDN 提供的 CNAME。

五、MX记录怎么看？

如果说 A、CNAME 主要跟网站访问有关，那么 MX 记录主要负责邮件。MX 是 Mail Exchange 的缩写，它告诉互联网：发往这个域名的邮件，应该交给哪台邮件服务器处理。

例如：

example.com

MX 10 mail1.example.com
MX 20 mail2.example.com

这里的mail1.example.com和mail2.example.com就是邮件服务器。

MX前面的数字是什么意思？

前面的数字表示优先级。

一般来说：

数字越小，优先级越高。

例如：

MX 10 mail1.example.com
MX 20 mail2.example.com

通常会优先尝试mail1.example.com，如果第一台服务器不可用，再根据配置尝试其他 MX 服务器。

不过实际配置还是应该以邮箱服务商提供的记录要求为准，不要自行修改优先级。

企业邮箱收不到邮件时，MX重点看什么？

如果企业邮箱突然收不到外部邮件，可以先检查：

MX 记录是否存在
邮件服务器地址是否正确
是否仍然残留旧邮箱服务商的记录
MX 优先级是否符合服务商要求
最近是否更换过 DNS 或邮箱平台

比如原来使用 A 邮箱服务，后来切换到 B 服务，但旧 MX 没有删干净，就可能造成部分邮件投递异常。这种问题只看邮箱后台不一定马上能发现，通过 DNS 查询反而更直观。

六、TXT记录怎么看？

TXT 记录经常是新手最不容易看懂的一类。

因为查询结果通常不像 A 记录那样简洁，而是一长串文本。

例如：

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

这通常是一条 SPF 相关的邮件验证记录。

TXT 的用途非常多，常见的包括：

SPF
DKIM
DMARC
Google Search Console 验证
Microsoft 365 域名验证
第三方 SaaS 平台验证
SSL 或域名所有权验证

所以查询 TXT 时，不需要看到一串字符就急着理解每一个参数。

大多数场景下，更重要的是：

查询出来的值，是否和平台要求你添加的值完全一致。

比如某个平台要求添加：

google-site-verification=abc123xyz

如果 DNS 查询结果里完全找不到这条内容，说明记录可能没有正确发布。

如果已经能查询到，但平台仍然验证失败，就继续检查：

TXT 内容是否缺少字符
是否多了空格或引号
主机记录是否填写错误
是否添加到了错误的域名
DNS 是否还处在传播过程中

七、A、CNAME、MX、TXT有什么区别？

如果把这几种常见记录放在一起看，会更直观。

DNS记录	主要作用	常见场景	查询时重点看什么
A	域名指向IPv4地址	网站、服务器	IP是否正确
CNAME	域名指向另一个域名	CDN、SaaS、云服务	CNAME目标是否正确
MX	指定邮件服务器	企业邮箱	邮件服务器和优先级
TXT	保存验证或策略文本	SPF、DKIM、域名验证	文本内容是否完整

简单记的话，可以理解成：

网站IP问题，先看A
CDN或别名解析，先看CNAME
收发邮件异常，先看MX
邮箱认证或域名验证，先看TXT

这样实际排查时，就不会面对一堆 DNS 记录不知道先看哪个。

八、DNS记录已经修改，为什么查询结果还是旧的？

这是域名解析里非常常见的问题。

后台明明已经点了保存，但外部查询仍然显示旧记录，并不一定说明操作失败。

1. DNS缓存还没有过期

DNS 记录通常带有 TTL，也就是缓存时间。

例如：

TTL = 3600

表示相关 DNS 缓存可能会保存一段时间。

修改解析后，不同地区、不同递归 DNS 的缓存更新时间并不会完全同步，所以短时间内可能出现：

有些地方已经返回新记录
有些地方仍然返回旧记录

这种情况在 DNS 切换过程中并不少见。

2. 修改错了DNS服务商

域名在哪里买，和 DNS 实际托管在哪里，是两回事。

例如域名是在注册商 A 购买的，但 NS 已经改到了 DNS 服务商 B。

这时如果你还在注册商 A 的解析面板里修改记录，很可能不会真正对外生效。

遇到这种情况，可以查询域名的 NS 记录，确认当前权威 DNS 到底由谁托管。

3. 查错了主机名

比如你修改的是：

www.example.com

但查询的是：

example.com

两者对应的是不同 DNS 记录。

类似地，api.example.com、mail.example.com、shop.example.com也都应该分别查询。

4. 本地缓存还没有更新

如果在线 DNS 查询已经显示新记录，但自己电脑仍然访问旧服务器，那么问题可能已经不在权威 DNS，而是在本地缓存。

常见缓存位置包括：

操作系统 DNS 缓存
浏览器缓存
路由器缓存
本地网络使用的递归 DNS

这种情况下，可以换一个网络环境或 DNS 服务器再次测试，看结果是否一致。

九、网站和邮箱问题，可以按这个顺序查DNS

如果是网站打不开、CDN 不生效，可以按照下面的顺序排查：

网站访问异常
↓
查询A / CNAME
↓
确认解析目标是否正确
↓
检查NS是否属于当前DNS服务商
↓
查看TTL和解析传播情况
↓
DNS正常后继续检查服务器或CDN

如果是企业邮箱收发异常，则更适合：

邮件异常
↓
查询MX
↓
确认邮件服务器
↓
查询TXT
↓
核对SPF / DKIM / DMARC
↓
再检查邮箱平台配置

这种排查方式的好处是，先把最基础的解析层确认清楚，再继续看服务器、CDN、邮箱系统或者网站程序，不容易在错误的方向上浪费时间。

DNS 查询本身并不复杂，难点在于查到结果之后，知道哪条记录和当前问题有关。网站解析到错误服务器，重点看 A；接入 CDN 后想确认是否生效，重点看 CNAME；企业邮箱收不到邮件，先查 MX；做 SPF、DKIM 或第三方域名验证，则重点核对 TXT。

如果刚修改过解析，也不要只看后台是否“保存成功”。通过实际 DNS 查询确认公开网络已经返回正确记录，才算真正完成了这一步。对站长和运维人员来说，养成先查 DNS 再排查其他环节的习惯，很多网站访问、CDN 接入和企业邮箱问题都会更容易定位。