MX 记录是什么？企业邮箱 DNS 配置、优先级设置与故障排查指南

公司邮箱收不到外部来信时，多数人的第一反应是邮箱服务商出故障了。真去查，问题往往卡在 DNS 里那两行不起眼的记录上——MX 记录。它决定「发给 @你域名 的邮件该投到哪台服务器」。主机名写错、优先级数字理解反了，邮件会悄悄绕路，严重时直接退信，而网站照常打开，前台看不出任何异常。

下面把 MX 的查询链路、优先级规则、企业邮箱配置步骤、命令行验证和排障顺序走一遍，最后给出明确的编辑判断：什么规模的团队该直接买第三方企业邮箱，什么情况下自建邮件服务器才值得投入，以及哪些时机根本不该碰自建。

MX 记录是什么：从收件人域名到 25 端口的两段查询

MX（Mail Exchanger，邮件交换记录）存放在域名的 DNS 里，回答两个问题：谁来接收这个域名的邮件，接收的先后顺序是什么。外部发信服务器（MTA）向 [email protected] 投递时，一次查询拿不到 IP，中间隔着两步。

第一步，MTA 从收件人地址里取出域名 example.com，向权威 DNS 查询 MX 记录，拿到一组「主机名 + 优先级」。第二步，对选中的主机名再发起 A（IPv4）或 AAAA（IPv6）查询，得到公网 IP，然后向该 IP 的 25 端口建立 TCP 连接，开始 SMTP 协商。记录格式由 RFC 1035 定义，路由与优先级处理规则在 RFC 5321 里进一步细化。

这个先后关系带来一条硬约束：MX 的指向字段只能写主机名（FQDN），不能写 IP。填裸 IP 违反 RFC 1035 与 RFC 5321 对数据结构的规定，合规 MTA 会当成语法错误处理并退信。邮箱服务商后台给出的记录通常就是一串域名，直接复制不会错；自己拼配置的人最容易在这里翻车。

MX 的另一层价值是把网站流量和邮件流量在 DNS 层拆开。A 记录指向前端 Web 服务器，MX 指向第三方云邮箱或自建邮件服务器，两边互不干扰。换 Web 主机不用动邮箱，迁邮箱也不用碰网站。

没有 MX 会怎样？RFC 5321 保留了历史兼容机制，少数 MTA 会退回去直连域名的 A 记录地址。但在当前严格的垃圾邮件防御环境下，无 MX 的域名在主流邮箱服务商那里基本会被直接拒收。「网站能打开、域名能解析」和「邮件能收」是两套独立路由，不能用前者推断后者。

优先级数字怎么读：数字越小越优先

MX 的 Preference 是 16 位整数，范围 0 到 65535，数字越小越先被尝试。优先级 10 排在 20 前面，这跟「数字大代表权重高」的直觉相反，也是实际配置里出错最多的一处。

主备冗余是它最典型的用法。主邮件服务器给 10，备用给 20。发信方先连主节点，只有主节点不可达或超时才回退到备用节点。备用节点收到信一般先排队暂存，等主节点恢复后中继回去，所以切换瞬间用户感觉收信慢半拍属于正常现象，不是丢件。

两条记录填相同优先级时，比如都写 10，发信 MTA 会在这组服务器之间随机或轮询选择，形成粗粒度负载分摊。边界要划清：MX 没有权重字段，做不到「70% 走 A、30% 走 B」。带 Weight 和 Port 的是 DNS SRV 记录，语义不同，别混用。要做精细分流，把负载均衡器放到邮件服务器前面。

规划数值时留出步长。用 10、20、30，而不是 5、6、7。以后要在主备之间插一台机器，直接拿 15 就行，不用重排整组记录。

企业邮箱 MX 配置：前置条件、步骤与回滚

配置动作本身不难，难的是把周边依赖照顾到。

前置条件：

• 域名的 DNS 管理权限（注册商面板或自建权威 DNS）
• 邮箱服务商给出的收信主机名，通常长成 mail.你的域名 这类 FQDN
• 该主机名已经能解析出公网 IP
• 服务商要求的优先级数值；部分云邮箱只允许单条 MX，别自作主张加备用
• 迁移场景下，提前把相关记录的 TTL 调低

操作步骤：

1. 先建 A 或 AAAA 记录，把 MX 要指向的主机名（例如 mail.example.com）解析到实际 IP。这步没做，后面填 MX 也是空谈。
2. 在 DNS 控制台新增 MX 记录。主机名字段通常填 @ 表示根域；只给某个子域收信就填对应子域前缀。
3. 指向字段只写 FQDN。部分面板会自动补末尾点号，手工编辑时留意别写成 mail.example.com.example.com 这种重复后缀。
4. 填优先级。单服务器给 10；主备结构按 10 / 20 规划。
5. 保存后等 TTL 到期。TTL 是 3600 秒的话，最长一小时内全网才一致，期间出现「有人能发、有人发不进」是缓存差异，不是配置写错。
6. 用命令行工具验证，再从外部邮箱发一封测试信确认闭环。

回滚方案：

动手前把原来的记录截图或复制成文本存档，这是最快也最省事的回滚。出问题就把旧值改回去，等 TTL 生效。从旧邮箱迁到新邮箱时，不要在新服务确认正常之前删掉旧记录；双写期间要确认两套系统的信件在用户端能合并，否则用户会在不同设备上看到两套收件箱。提前调低 TTL 的意义也在这里——回滚几分钟生效，而不是几小时。

一张表看清 MX 与 A / PTR / SPF / DKIM / DMARC 的分工

邮件能不能正常收发，从来不只靠一条 MX。下表把常见记录的分工和配错后的症状摆在一起，排障时可以直接对号入座。

一句话概括：MX 管收信，SPF、DKIM、DMARC 管发信可信度，PTR 是自建邮件服务器的必修课。只配 MX 就对外发信，等于把邮件交给对方的垃圾过滤规则去判断。

顺带说个常见的坑：DNS 规范不允许域名 Apex（@ 根域）同时存在 CNAME 和其他记录。有人在根域配了 CNAME，MX 会被解析器直接忽略，表现是「记录明明在那儿，邮件就是不进来」。排查先看根域有没有 CNAME，能省掉大量弯路。

用 dig、host、nslookup 验证：附输出示例与判读方法

命令行是最快的判断手段。dig 输出信息最全，host 和 nslookup 更直观，选一个顺手的。

## 查 MX 记录，只输出结果行
dig MX example.com +short

## 指定公共解析器，绕过本地缓存
dig MX example.com @8.8.8.8 +short

## 验证 MX 指向的主机名能否解析出 IP
dig +short mail.example.com

## 备选工具
host -t MX example.com
nslookup -type=mx example.com

一组正常的 MX 返回长这样，左边的数字就是优先级：

10 mail.example.com.
20 mail2.example.com.

判读时抓两点。一是优先级数值和主机名的对应关系，主备写反是最容易犯的错——上面这组说明 mail.example.com 是主力，mail2 是备用。二是主机名末尾的点号，dig 输出 mail.example.com. 带一个根域点号是正常 FQDN 写法，不用手动删。以上输出只是格式示例，实际主机名和优先级以你自己域名的查询结果为准。

如果 MX 正常但邮件还是不动，把注意力转到端口：

nc -vz mail.example.com 25

端口通的情况下会看到类似 Connection to mail.example.com 25 port [tcp/smtp] succeeded! 的回显；如果返回 Connection refused 或长时间无响应，方向就明确了：要么服务器上的邮件服务没起来，要么防火墙没放行，要么服务商在出口层做了限制。

25 端口这一环对自建邮件服务器尤其关键。很多云厂商默认限制 25 端口，需要单独申请或工单开通，政策各家不同，下单前最好直接确认，别等机器装好了才发现发不出去。

外部邮件收不到：按这个顺序排查

邮件不通时不要东一榔头西一棒子，按下面顺序走，通常前三步就能定位。

1. 确认 MX 记录存在。 用 dig 查目标域名，看 ANSWER 段有没有返回。控制台误删、保存没生效、改到了错误子域，都会在这一步暴露。
2. 确认主机名能解析。 对 MX 指向的 FQDN 查 A / AAAA，没有结果说明前置地址记录漏了或填错了。
3. 确认 25 端口通。 服务停摆、防火墙拦截、云平台出口限制都会卡在这里。
4. 检查根域 CNAME 冲突。 根域有 CNAME 时 MX 会被忽略，这是最隐蔽的一类故障。
5. 考虑 TTL 与缓存。 刚改完记录别急着下结论，换公共解析器再查一次，用不同解析器对比结果。
6. 检查发信侧配置。 收信正常但发出的信进垃圾箱，问题在 PTR、SPF、DKIM、DMARC，回到上一节那张表逐项核对。

排查时随手记录查询时间、使用的解析器和返回结果。多次修改之后，这份记录能帮你判断到底是配置变了，还是缓存没过。

四个高频误区

误区一：MX 可以直接填 IP。 规范不允许，合规 MTA 会退信。先把 IP 落到 A 记录，再把 MX 指向那个主机名。

误区二：数值越大优先级越高。 正好相反，0 最高，65535 最低。把主力服务器设成大数字，流量会全跑到你以为是备用的那台。

误区三：靠 MX 做比例负载均衡。 MX 只有先后次序，没有权重。同优先级只能对等轮询，做不到按百分比分配。

误区四：有了 MX 就不用管 SPF。 MX 只管入站，不负责发信鉴权。只配 MX 的域名对外发信，很容易被判定为伪造。

编辑判断：什么时候用第三方企业邮箱，什么时候才自建

这一节是本文最想给出的结论，因为它直接决定你把钱花在哪。

这些情况，直接买第三方企业邮箱，不要自建。 团队规模在几十人到几百人，需求就是正常收发、日历通讯录同步、偶尔有存档合规要求；公司没有专职运维，出故障时希望有人接工单；平时不做大规模对外群发。这类场景下，第三方企业邮箱按账号订阅，MX、SPF、DKIM 记录照抄服务商给的模板即可，出问题让服务商查，投入产出比明显更高。为了省订阅费去自建，通常会在第一次退信潮里把省下的运维成本赔回去。

这些情况，自建才花得值。 有明确的数据主权或合规要求，邮件内容和元数据不能落在第三方；需要深度定制过滤、网关、路由策略；已经有运维能力，能处理 25 端口、PTR、IP 信誉和退信日志；或者要把邮件系统和工单、CRM 打通，让内部系统直接发信。满足其中两三条再考虑自建，只满足「想省钱」这一条，不算理由。

什么时候不要买自建用的 VPS。 三个信号：团队没人管运维；主要目的是对外群发营销邮件（普通 VPS 的 IP 信誉撑不住这种量级，容易被整体拉黑）；以及短期内必须立刻稳定送达——新 IP 段没有历史发信记录，冷启动阶段进垃圾箱是常态，需要时间养。这三条任意命中一条，自建都不是合适选择。

什么时候可以买，怎么买。 如果只是想在测试环境验证 MX 配置和投递流程，挑一台按小时计费、门槛低的机器就够了，用完即删。如果要上生产自建邮件服务器，下单前必须确认三件事：服务商是否允许 25 端口通信、IP 能否设置 PTR 反向解析、IP 段有没有被主流邮箱列入黑名单。这三项的答案比套餐参数重要得多。圈子里的 VPS 选项里，搬瓦工 和 RackNerd 被讨论得比较多，但 25 端口政策、PTR 支持情况和套餐价格都会随时间调整，请以服务商官网当前说明为准，必要时直接开工单问清楚。

机器到手之后，服务器本身的加固不能省。防火墙策略、SSH 端口、Fail2ban 这些基础项没做好，邮件系统暴露在公网上很容易被当成跳板，可以对照 Ubuntu 24.04 VPS 安全加固清单：SSH、UFW、Fail2ban、自动更新与 AI 辅助运维 逐项过一遍。至于邮件系统和网站该用共享主机、VPS 还是独立服务器承载，思路不完全一样，先用 共享主机、VPS、云服务器和独立服务器怎么选 理清托管方式的边界，再决定投入多少运维精力。另外，自建发信对 IP 的「干净」程度很敏感，选机器前可以先看看 美国原生 IP VPS 怎么选 这类讨论，理解原生 IP 与广播 IP 在信誉上的差别。

结论与行动清单

MX 记录这件事，抓住两点就够了：指向的是主机名而不是 IP，查询要走 MX → A/AAAA 两段。它不负责发信可信度，只负责把外部来信引导到正确的服务器，所以配置完成后必须做端到端验证，而不是看到记录写进去就收工。

按顺序动手，可以直接照这份清单执行：

1. 备份现有 MX 和 A 记录（截图或导出文本）。
2. 检查根域有没有 CNAME 冲突。
3. 确认目标主机名的 A / AAAA 记录已生效。
4. 新增或修改 MX，主备按 10 / 20 规划。
5. 用 dig 在不同解析器上交叉验证，确认优先级与主机名对应无误。
6. 用 nc 确认 25 端口可达。
7. 从 Gmail、Outlook 这类规则严格的平台发一封实测信，确认进收件箱而不是垃圾箱。
8. 确认无误后再逐步淘汰旧记录，双写期间观察两套系统能否正常合并。

需要提醒的是，本文涉及的 VPS 服务商 25 端口政策、PTR 设置支持、套餐配置与价格，以及第三方企业邮箱的额度、容量和功能限制，都属于会变动的信息，文中没有引用具体数值，实际以各服务商官网当前说明为准。文中给出的 dig 与 nc 输出是格式示例，用于帮助判读，不代表任何真实域名的查询结果。