用 dig mx 域名 即可快速查询域名的 MX 记录，这是 Linux 和 macOS 系统下最直接、信息最完整的命令。它不仅能显示邮件服务器的地址，还能告诉你优先级和 TTL，排错时比 nslookup 更清晰。
dig 查询 MX 记录的基础用法
标准命令格式与输出解读
在终端中输入 dig mx 加上你的目标域名，比如查 qq.com,命令就是：
dig mx qq.com
输出结果看起来很长，但核心内容只有几行，重点关注 ANSWER SECTION（答案部分），它会列出该域名所有的 MX 记录，每条记录由三部分组成：优先级（Preference）、邮件服务器主机名（Exchange）、TTL 缓存时间。
举个例子，如果看到 10 mx1.example.com.，意思是优先级为 10，邮件服务器是 mx1.example.com。优先级数字越小，代表服务器级别越高，邮件会优先投递到那里。
加上 +short 参数，只输出纯净结果
很多运维工程师习惯加一个 +short 参数,让输出简洁到只显示服务器地址和优先级：
dig mx example.com +short
输出结果就两列：第一列是优先级，第二列是邮件服务器域名，这个参数特别适合写脚本或者在服务器上快速手动检查时使用,不容易看花眼。
进阶操作：dig 命令查看 MX 记录怎么处理缓存与指定服务器
查询权威 DNS 而不是本地缓存
刚才的查询走的是系统默认配置的 DNS 服务器，可能是你路由器的，也可能是运营商默认的，为了拿到最准确、最新的数据，建议直接查域名的权威 DNS 服务器。
先拿一个 NS 类型的查询命令看看,本质是第一步：
dig ns example.com +short
拿到 NS 服务器地址后，再指定这个 NS 服务器做 MX 查询，这保证你能看到域名原始配置的真实状态，绕过了中间各级缓存，排查”为什么改了记录却没生效”时非常有用。
用 @ 符号指定公共 DNS 服务器
如果不清楚权威 DNS，用 符号直接指定一个知名的公共 DNS 服务器也可以。
dig mx example.com @8.8.8.8
这条命令强制向 Google 的公共 DNS 发起查询，这种做法的好处是验证你的域名解析在全国或者全球网络里是否已经同步，如果你发现用 @8.8.8.8 查到的新记录，但本地 dig mx 还是旧记录，那说明是本地缓存的问题，等 TTL 过期后会自动刷新。
深入理解 MX 记录的 TTL 缓存机制
TTL（Time To Live） 是 DNS 记录的生命周期，在 dig mx 输出的 ANSWER SECTION 上面一行，你会看到文件头里有一个 ttl 数字,单位是秒。
行业共识认为，绝大多数邮件服务商默认将 MX 记录 TTL 设置在 300 到 3600 秒之间，如果你刚修改了 MX 记录，且旧记录的 TTL 是 86400（24小时），那么全球网络需要最多一天时间才能完全刷新到新记录，此时用 dig mx 查看到旧值是正常的,并不是你的操作没生效。
域名邮箱 MX 记录查询方法与批量操作技巧
批量检查多个域名的配置状态
如果你管理着多套企业邮箱系统或代运维客户网站，一个一个敲 dig 命令太低效，可以把所有域名写进一个文本文件,然后用循环命令批量查询。
for domain in $(cat domains.txt); do echo "=== $domain ==="; dig mx $domain +short; done
这个脚本会读取 domains.txt 文件里的每一个域名，依次打印出每个域名的 MX 记录，输出结果一目了然，谁家邮件服务器配错了，谁家没解析,对比非常直观。
查询结果的优先级排序到底怎么看
服务器投递邮件的时候，会永远先尝试优先级数字最小（即最优先）的那个邮件服务器，如果它连接不上，才会尝试次级，所以当你的 MX 记录有多条时,要检查一下优先级里是否有空缺。
比说 A 记录服务器优先级是 5，B 记录优先级是 10，正常情况下，邮件只会发往 A 服务器，A 服务器宕机或者网络不通，发送方的服务器才会轮到用 B。
不要将主服务器的优先级设成 10，备份设成 5，那样主服务器就永远不会被优先使用。
与 nslookup 命令的结果对比
很多老运维习惯用 nslookup -type=mx example.com，虽然也能查到记录，但它的输出信息不如 dig 完整，尤其在查看 TTL 和权限 NS 服务器信息时比较弱。dig 命令的查询过程更透明，它会把”从哪个服务器获取到答案”这一步骤也显示出来。如果要严格排查邮件收发不稳定的问题，用 dig 获取一手信息会让你少走很多弯路。
实战排查邮件收发故障与长期监控方案
配置 GCC 邮箱或酷番云邮箱时如何验证
假设你在酷番云上购买企业邮箱服务，后台提示你添加一条 MX 记录，主机记录是 ，记录值是 mxbiz1.qq.com,配好后你可以在本地服务器执行：
dig mx 你的域名.com +short
检查输出结果是否与你刚填写的记录值完全一致，包括末尾的句点（一般显示时会自动省略），这条操作其实就是一次域名邮箱MX记录查询方法的完整演练，如果不匹配,多半是你在域名注册商那里填错了主机记录或者记录值带了不必要的空格。
利用 +trace 参数排查递归链路故障
为了搞清楚具体是哪一步 DNS 解析出了问题,可以这样操作：
dig mx example.com +trace
这能看到从根域名服务器到顶级域名服务器，再到最终权威服务器的完整请求路径，如果输出在某一环报错，就说明问题出在这个 Node 上，这种参数比较适合处理棘手的解析错误,每次排查完都能让分析更有底。
搭建一个简易的邮件服务器状态巡检表
采用脚本结合日志的方式来持续追踪，核心思路是记录每次查询的邮件服务器 IP 与 TTL 数值，然后比对变化，长期数据积累下，可以发现因为 TCP 连接数量的微小变化而预期之外的风险，理论上讲，MX 记录变更的频率极低，所以一旦发现 TTL 数值异常变大或变小,标志着记录源可能被人动过手脚。
MX 查询在其他工具里怎么看最直观
虽然命令行工具功能强大，但网页版工具在直观体验上仍需人工对照检查，很多开发者会利用 Python 脚本调用第三方库快速扫描多个域名，如果你想要一个快速的可视化界面，在浏览器访问某些 DNS 查询网站也能达到类似效果，但要注意，这些网站查询的往往是它自己的节点而不是你的本机,结果不一样时先别急着抓狂。
常见问题快速排查
为什么 dig mx 返回空结果但邮件却还能收发？
如果返回空，但网页邮箱或客户端还能正常收件，检查两个方向：一种情况是你查的域名写错了，可能多加或漏加了 www；另一种情况是发送方可能也存在缓存，或者你的邮箱服务商并不依赖域名 MX 记录来接收邮件（比如用了 CNAME 指向）。
dig 直查邮箱服务器地址的成功率更高吗
这不叫成功率，叫解析效果，用 dig a mail.example.com 可以拿到邮件服务器具体的 IP 地址用于组网测试，如果想测试邮件服务器是否联通，直接 Ping 这个 IP 更有指导意义。
修改了简米云 DNS 解析，多久能全球生效
如果你用简米云解析，修改完 MX 记录后，简米云的生效时间在秒级，但世界上其他运营商的 DNS 服务器缓存你要等它自然过期才行，去 What’s My DNS 类的网站查一下就知道了，这类网站可以直接确认国内外解析是否同归一处，要是那边显示新记录，但你的邮件客户端连不通，去服务器上多执行几遍 dig mx 域名 @8.8.8.8 验证一下出口线路的 UDP 包是否被干扰。
MX 记录是邮件系统正常运转的根目录，每次排查都记得以 dig mx 的真实输出为准，别猜,它返回的每一行信息都替你验证了当前的网络环境。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/615677.html
