邮件域名解析与网站解析最大的不同，在于邮件系统不是靠 A 记录直接找到收件服务器，而是先通过 MX 记录查询负责该域名邮件接收的服务器列表。主域名配置 MX 记录相对简单，但换成二级域名时，很多人会沿用网站解析的思路，只加一条 A 记录，或者把 MX 记录错误地指向一个 CNAME 别名，最终导致邮件延迟、退信甚至静默丢失。本文围绕二级域名独立收发邮件的需求，把 MX 记录的优先级、主机记录写法、A 记录配合以及配置后的验证方法完整梳理一遍，兼顾常见 DNS 面板和命令行环境。
一、MX 记录在二级域名中的作用
MX 记录全称 Mail Exchanger，也就是邮件交换记录。当外部邮件服务器要给某个地址发信时，它会先查询收件地址中域名部分对应的 MX 记录，获得一个或多个负责接收邮件的服务器名称，然后按照优先级数值从小到大的顺序依次尝试连接。例如 MX 优先级为 10 的服务器比优先级为 20 的服务器更先被使用，只有当低优先级服务器连接失败时，发件方才会尝试优先级更高的备用服务器。优先级数字本质上表示选择顺序，而不是负载权重，这一点在配置多条 MX 记录时很容易混淆。
二级域名与主域名在 DNS 解析中属于不同的名称空间。假设你已经在 ippipp.com 主域下配置了 MX 记录，这并不会自动让 sub.ippipp.com 继承相同的邮件解析能力。如果希望 user@sub.ippipp.com 这个地址正常收信，就必须为 sub.ippipp.com 这个二级域名单独设置 MX 记录。很多配置失败的情况，正是因为只给 mail.sub.ippipp.com 添加了 A 记录，却没有为 sub.ippipp.com 本身添加 MX 记录，导致外部邮件服务器在查询时根本不知道该把邮件投递到哪台主机。
这里还要特别注意 CNAME 与 MX 的关系。DNS 协议要求 MX 记录的目标不能是一个 CNAME 别名。也就是说，不能把 sub.ippipp.com 的 MX 记录指向某个名称，而这个名称同时又是一条 CNAME 记录。如果目标名称被解析为 CNAME，邮件投递可能出现循环、延迟或直接失败。正确做法是让 MX 记录的目标最终指向一个可以通过 A 或 AAAA 记录解析到固定 IP 的主机名，例如 mail.sub.ippipp.com。如果使用第三方邮件托管服务，MX 记录值通常由服务商提供，这个值本身应该是一个可正常解析的 MX 域名，而不应再去绕一层 CNAME。
二、配置二级域名 MX 记录的完整步骤
配置之前需要先准备一台已经开放 25 端口并且具有固定公网 IP 的邮件服务器，或者准备一个第三方邮件服务提供的 MX 目标地址。接下来在 DNS 管理后台或者 zone 文件中操作。以主域 ippipp.com 为例，要配置 sub.ippipp.com 的邮件接收，通常需要新增两条记录：一条是 mail.sub.ippipp.com 的 A 记录，另一条是 sub.ippipp.com 的 MX 记录。A 记录负责把邮件服务器主机名解析到 IP，MX 记录则负责告诉外部服务器这个二级域名的邮件由哪台主机接收。
在常见的 DNS 面板中，添加 A 记录时，主机记录可以填写 mail.sub，表示完整名称为 mail.sub.ippipp.com，记录类型选择 A，记录值填写邮件服务器的公网 IPv4 地址，例如 192.0.2.10。添加 MX 记录时，主机记录填写 sub，记录类型选择 MX，记录值填写 mail.sub.ippipp.com，优先级一般填 10，TTL 可以暂时设置为 600 秒，方便测试阶段快速生效。这样配置后，DNS 中会形成 sub.ippipp.com 指向 mail.sub.ippipp.com 的 MX 记录，而 mail.sub.ippipp.com 又通过 A 记录解析到真实服务器。
如果你使用 zone 文件管理 DNS，可以参照下面的示例。示例中包含了主 MX 记录和一条备用 MX 记录，同时给出对应主机的 A 记录：
sub.ippipp.com. 600 IN MX 10 mail.sub.ippipp.com. sub.ippipp.com. 600 IN MX 20 backup.mail.ippipp.com. mail.sub.ippipp.com. 600 IN A 192.0.2.10 backup.mail.ippipp.com. 600 IN A 192.0.2.20
有些 DNS 服务商允许把二级域名单独委派为一个独立区域，这时候 sub.ippipp.com 就作为区域的顶点存在，MX 记录中的主机记录可以留空或填写 @，含义与主域配置类似。例如在该独立区域中直接写入 mail.sub.ippipp.com 为目标，MX 记录会在 sub.ippipp.com 这个域上生效。不同面板的字段名称略有差异，但主机记录留空和填写 @ 通常都表示当前区域顶点，需要根据服务商说明确认。
TTL 是一个很容易被忽略的字段。它决定了解析结果在其他 DNS 服务器上的缓存时间。测试阶段建议把 TTL 调低，例如 300 到 600 秒，这样修改后可以快速观察效果。确认配置正确后，再把 TTL 调整为 3600 秒或更长，以减少公共 DNS 服务器的查询压力。需要注意的是，修改前的旧解析结果可能已经被各级缓存保存，即使你在面板中更新了 MX 记录，也要等待旧 TTL 到期后才会完全生效。
三、验证解析结果与邮件链路
配置完成后，不要只靠面板显示的状态判断生效情况，最好通过命令行工具进行独立验证。dig 是 Linux 和 macOS 下常用的 DNS 查询工具，执行以下命令可以直接查看 sub.ippipp.com 的 MX 记录：
dig sub.ippipp.com MX +short
如果配置生效，返回结果会类似下面这样，第一列是优先级，第二列是 MX 目标主机名：
10 mail.sub.ippipp.com. 20 backup.mail.ippipp.com.
还需要继续确认 mail.sub.ippipp.com 的 A 记录是否能够正常解析。可以执行 dig mail.sub.ippipp.com A +short 查看返回的 IPv4 地址。如果 A 记录查询为空，说明 MX 指向了一个不存在的主机名，外部邮件服务器将无法建立连接。Windows 用户可以使用 nslookup 完成类似检查，命令如下：
nslookup -type=MX sub.ippipp.com
通过 nslookup 的输出可以看到首选和备用 MX 记录及其优先级。若记录值与面板配置不一致，通常说明本地 DNS 缓存或运营商 DNS 尚未更新，可以尝试更换公共 DNS 服务器，例如使用 8.8.8.8 或 1.1.1.1 进行查询。若要进一步验证邮件服务器是否能建立 SMTP 连接，可以在 Linux 或 macOS 下使用 nc 命令检查 25 端口连通性：
nc -vz mail.sub.ippipp.com 25
如果返回 connection succeeded，说明目标主机的 25 端口可以从当前网络访问。否则需要检查服务器防火墙、安全组规则以及邮件服务是否真正监听在 25 端口。Windows 系统可以在 PowerShell 中执行 Test-NetConnection mail.sub.ippipp.com -Port 25 查看连接结果。只有 MX 解析和端口连接都正常，二级域名的收信链路才算基本打通。
四、常见问题与注意事项
多个 MX 记录同时存在时，优先级数值越小，表示优先级越高。很多人会把优先级理解成权重，错误地认为数值大一点可以分担更多流量。实际上，发件方通常会优先连接数值最小的服务器，只有连接失败时才会尝试下一条。因此如果需要主备架构，应该把主服务器的 MX 优先级设置为 10，备用服务器设置为 20 或更高。不要把两个优先级设置成相同数值，否则发件方会随机选择，可能导致邮件分散到未完全配置好的节点上。
CNAME 与 MX 的冲突是二级域名场景下的高发问题。部分服务商允许在界面上同时保存 CNAME 和 MX 记录，但实际解析时 CNAME 会优先于 MX 返回，导致 MX 查询结果异常。如果你之前曾为 sub.ippipp.com 配置过 CNAME 用于网站跳转，现在又希望它独立接收邮件，需要先删除该 CNAME 记录，再添加 MX 记录。因为根据 DNS 规范，一个名称不能同时存在 CNAME 记录和其他类型的记录。正确做法是让 sub.ippipp.com 直接作为邮件域，而网站访问可以通过其他方式实现，或者改用 A 记录指向网站服务器。
如果二级域名还承担发信功能，不仅要配置 MX 接收记录，还要同步配置 SPF、DKIM 和 DMARC 等邮件身份验证记录。发件方 MTA 在收到来自 user@sub.ippipp.com 的邮件时，会检查该二级域名是否发布了 SPF 策略。如果缺少 SPF，邮件更容易被判定为垃圾邮件。SPF 的 TXT 记录可以配置在 sub.ippipp.com 上，例如允许主域邮件服务为二级域名发信时，可以写入如下内容：
sub.ippipp.com. 600 IN TXT "v=spf1 include:_spf.ippipp.com ~all"
此外，如果邮件服务器使用独立公网 IP 发送邮件，还应该为这个 IP 配置反向解析 PTR 记录，使其反向解析结果指向 mail.sub.ippipp.com。很多大型邮箱服务商会对 PTR 与 HELO 名称不一致的服务器进行降权或拒收。二级域名的邮件系统如果不处理 PTR，很容易出现邮件被对方服务器拒绝的情况。反解记录通常由 IP 所属的运营商或机房管理员配置，需要提前提交工单处理。
泛解析和裸二级域名也需要谨慎处理。不要轻易为整个域配置类似 *.ippipp.com 的 MX 泛解析，因为这样会让任意不存在的二级域名都指向邮件服务器，增加垃圾邮件和滥用风险。对于内部运营需求，建议按需为每个二级域名单独创建 MX 记录，并定期检查不再使用的二级域名是否还保留着旧记录。配置完成后，保留至少 24 到 48 小时的观察期，确认外部主要邮箱服务商都能正常投递，再逐步调整 TTL 和删除测试记录。