想要使用 [email protected] 格式的电邮，而不是个人 Gmail 或 Hotmail？第一步是在您的域名 DNS 中正确设置 MX 记录。本文解释了什么是 MX 记录、如何在 DirectAdmin 中设置以及如何添加 SPF、DKIM 和 DMARC，以便您的电邮到达收件箱而不是进入垃圾箱。
什么是 MX 记录？
MX 记录（邮件交换记录）是一种 DNS 记录，告诉互联网哪个邮件服务器负责处理某个域名的电邮。当有人向 [email protected] 发送电邮时，发件人的邮件服务器查询 example.com 的 DNS 以找到 MX 记录，然后将电邮投递到那里列出的服务器。
MX 记录必须指向 主机名（A 记录） — 而不是直接指向 IP 地址。每个 MX 记录也有一个 优先级值 — 数字越低，优先级越高。
| 示例 MX 记录 | 优先级 | 含义 |
|---|---|---|
| mail.example.com | 10 | 主服务器（首先尝试） |
| mail2.example.com | 20 | 备份服务器（主服务器失败时使用） |
为什么您需要 MX 记录？
如果您的域名没有 MX 记录，或记录配置错误，传入电邮将无处可去。发件人会收到 550 No such user here 或 MX lookup failed 这样的错误，这意味着您的域名电邮根本无法接收消息。
为电邮协同工作的 DNS 记录
多种 DNS 记录类型协同工作才能使域名的电邮系统正常运行。MX 记录处理邮件投递的位置，而身份验证记录处理谁被允许发送以及邮件是否真实。
| 记录类型 | 类别 | 功能 | 必需？ |
|---|---|---|---|
| MX 记录 | MX | 指向接收电邮的邮件服务器 | 必需 |
| 邮件服务器 A 记录 | A | 将邮件服务器主机名解析为 IP | 必需 |
| SPF | TXT | 授权允许代表您发送的 IP | 强烈推荐 |
| DKIM | TXT | 出站邮件的数字签名验证 | 强烈推荐 |
| DMARC | TXT | 处理 SPF/DKIM 失败的策略 | 强烈推荐 |
| PTR / 反向 DNS | PTR | 验证发送方 IP 的主机名 | 可选但有帮助 |
了解 MX 记录优先级值
每条 MX 记录都有一个优先级（也称偏好度）值。当一个域名存在多条 MX 记录时，发送邮件的服务器总是会首先尝试优先级数字最低的记录。如果该服务器无法到达或处于忙碌状态，服务器会继续尝试下一个最低值。
# 带优先级值的 MX 记录示例
yourdomain.com. 3600 IN MX 10 mail.yourdomain.com. (主服务器)
yourdomain.com. 3600 IN MX 20 mail2.yourdomain.com. (二级)
yourdomain.com. 3600 IN MX 30 mail3.backup.com. (三级)对于典型的共享电邮托管，单个优先级为 10 的 MX 记录就足够了。只有当多条 MX 记录指向共享相同邮件存储的不同服务器时，才对设置多条记录有帮助——否则投递到二级服务器的电邮在主账户中将不可见。
重要：使用 Google Workspace、Microsoft 365 或任何第三方电邮提供商时，他们会给您特定的 MX 值和优先级数字。请完全按照提供的方式使用。修改这些数字会导致投递失败或他们基础设施内的负载均衡问题。
MX 设置后电邮进入垃圾箱的故障排除
即使正确设置了 MX 记录，电邮仍可能进入垃圾箱。MX 记录仅控制传入邮件的投递位置——垃圾邮件过滤由身份验证记录驱动。请按照以下检查清单排查：
- SPF 失败——如果您发送服务器的 IP 未列在 SPF 记录中，接收服务器将对邮件进行软失败（
~all）或硬失败（-all）。 - DKIM 签名无效——DNS 中的公钥必须与邮件服务器上的私钥匹配。不匹配会导致 DKIM 失败，降低邮件的信任分数。
- 没有 PTR/反向 DNS——许多邮件服务器检查发送方 IP 是否解析回 SMTP 主机名。缺失 PTR 记录是常见的垃圾邮件触发原因。
- IP 在黑名单上——使用 MXToolbox 的黑名单检查看您的服务器 IP 是否列在任何黑名单上。新 IP 地址可能会从以前的用户那里继承坏名声。
- DMARC 报告——设置
rua=mailto:[email protected]，Google/Outlook 会在 24 小时内向您发送汇总报告，确切显示哪些邮件通过或未通过身份验证。
⚠️ 常见错误：将 SPF 设置为 +all（允许所有 IP）会移除所有保护，这意味着互联网上任何人都可以发送看起来来自您域名的电邮。始终使用 ~all（软失败）或 -all（硬失败）。
在 DirectAdmin 中设置 MX 记录
如果您的域名在 AsiaGB，并且使用 DirectAdmin，请按照以下步骤操作：
- 登录 DirectAdmin → DNS 管理
- 选择要编辑的域名
- 找到 MX 记录部分，删除任何现有记录（如果有）
- 使用您的电邮托管提供商提供的值添加新的 MX 记录
- 将 TTL 设置为 3600（1 小时），或按照您的提供商的建议
- 点击保存
AsiaGB 自有服务器电邮托管的 MX 记录示例：
# 在 DirectAdmin DNS 管理中
Type: MX
Name: @ (或您的域名)
Value: mail.yourdomain.com
Priority: 10
TTL: 3600⚠️ 重要：如果您使用来自 Google Workspace 或 Microsoft 365 等外部提供商的电邮托管，您必须完全按照他们指定的 MX 值输入——不要自己编造值，因为每个提供商使用不同的记录。
使用 dig / nslookup 验证 MX 记录
保存后，等待几分钟让 DNS 传播，然后使用这些命令验证：
# 使用 dig（Linux / macOS） dig MX yourdomain.com # 使用 nslookup（Windows） nslookup -type=MX yourdomain.com
正确的结果将显示您刚添加的 MX 记录，例如：
yourdomain.com. 3600 IN MX 10 mail.yourdomain.com.
您也可以使用在线工具 MXToolbox（mxtoolbox.com）直接从浏览器检查。
设置 SPF、DKIM 和 DMARC 以防止垃圾邮件
MX 记录单独是不够的。您还应该配置电邮身份验证记录，以防止您的电邮被标记为垃圾邮件或被攻击者欺骗。
SPF 记录（发件人策略框架）
声明哪些邮件服务器 IP 地址被授权代表您的域名发送电邮。添加为 TXT 记录：
Type: TXT Name: @（或您的域名） Value: "v=spf1 mx a ip4:您的服务器IP ~all"
DKIM 记录（域密钥识别邮件）
向每条出站电邮添加数字签名，以便收件人的服务器可以验证邮件是否来自授权的来源。您的电邮托管提供商会给您 DKIM 密钥；它看起来像这样：
Type: TXT Name: default._domainkey.yourdomain.com Value: "v=DKIM1; k=rsa; p=MIGfMA0GCS...<公钥>"
DMARC 记录
定义 SPF/DKIM 检查失败的电邮的策略。开始时使用 p=none 来监控，一旦您有信心就切换到 quarantine 或 reject：
Type: TXT Name: _dmarc.yourdomain.com Value: "v=DMARC1; p=none; rua=mailto:[email protected]"
优先级顺序：按此顺序设置 MX → SPF → DKIM → DMARC。完成这四个步骤会显著提高您的电邮投递能力。
DNS 传播需要多长时间？
保存 DNS 记录后，变更不会立即生效。全球 DNS 服务器需要时间更新其缓存：
- 通常：15 分钟到 1 小时
- 使用高 TTL 值时：最长 24–48 小时
- 专业提示：在进行变更前将 TTL 降低到 300 秒（5 分钟）可加快传播速度
在传播期间，某些电邮可能仍会发送到旧服务器——这是完全正常的。
检查清单：MX 记录 ✓ → SPF ✓ → DKIM ✓ → DMARC ✓ → 使用 MXToolbox 验证 ✓ — 一旦这四项都就位，您的域名电邮就完全可以专业使用了。
为什么域名电邮地址能提高商业信誉
除了技术要求外，使用 [email protected] 这样的电邮地址对您的业务专业形象有直接影响：
- 看起来专业——对于商务往来，客户和商业伙伴会比 Gmail 或 Hotmail 地址更重视基于域名的电邮。
- 一致的品牌——相同的域名出现在您的网站和每条电邮中，加强品牌认可。
- 您保持控制权——您的电邮与您的域名相关联。当员工离职或提供商账户关闭时，该地址仍属于您。
- 电邮别名很容易——您可以创建
[email protected]、[email protected]和[email protected]都投递到一个邮箱，零额外成本。 - Google Workspace / Microsoft 365 所需——如果您计划使用这两个平台中的任何一个，正确配置的 MX 记录是任何其他内容工作前的必需第一步。
AsiaGB 的托管计划包括电邮托管，具有完整的 Webmail、IMAP/POP3 和 SMTP 支持。域名注册、DNS 管理和电邮托管都通过 DirectAdmin 在一个地方管理——除非您选择，否则不需要外部电邮提供商。
MX 记录 TTL 策略：规划变更
TTL（生存时间）是告诉全球 DNS 解析器缓存您的 MX 记录多长时间的值。选择正确的 TTL 取决于您的情况以及您是否预期很快进行变更。选择不当的 TTL 可能意味着要等待数小时变更才能全球生效。
| 场景 | 推荐的 TTL | 原因 |
|---|---|---|
| 稳定设置，无变更计划 | 3600–86400 秒 | 降低全球 DNS 查询负载 |
| 即将进行邮件服务器迁移 | 300 秒（5 分钟） | 需要时变更快速传播 |
| 迁移期间活跃切换 | 60–300 秒 | 对切换窗口的精确控制 |
在计划的迁移至少 24 小时前降低您的 TTL。这确保全球 DNS 解析器上的缓存值在切换 MX 记录前过期，给您一个清洁和可预测的切换。
重要：使用 Google Workspace 或 Microsoft 365 时，仅使用他们提供的 MX 记录。添加指向其他服务器的额外 MX 记录可能导致某些电邮被投递到错误的位置。永远不要混合来自不同提供商的记录。
测试和监控您的电邮设置
完成 MX 记录和电邮身份验证设置后，彻底测试可防止您开始发送真实商务电邮后出现尴尬的投递失败。在上线前发现的问题修复成本远低于客户发现的问题。
推荐的测试工具
- MXToolbox 电邮健康检查（
mxtoolbox.com/emailhealth）——在单个报告中检查 MX、SPF、DKIM、DMARC、PTR 和黑名单状态 - Google 管理工具箱（
toolbox.googleapps.com）——详细的 DNS 记录检查，对 Google Workspace 用户特别有用 - Mail-Tester（
mail-tester.com）——发送测试电邮并获得可投递性分数和具体补救建议；10/10 的分数确认配置正确 - DMARC 分析器——将来自 Google 和 Microsoft 的原始 DMARC XML 报告转换为可读的仪表板
上线后的持续监控
- 黑名单状态——至少每月检查一次，特别是在新 IP 地址的最初几周
- DMARC 汇总报告——每周审查以检测使用您域名的欺骗尝试
- DKIM 密钥轮换——某些提供商需要定期密钥轮换；与您的电邮托管提供商确认计划
- SPF 查询限制——SPF 允许每次检查最多 10 次 DNS 查询；太多
include:语句会导致 SPF 失败。如果达到此限制，请使用 SPF 平展工具。
⚠️ 任何服务器变更后：始终在切换前更新 SPF 记录以包含新服务器的 IP 地址。如果新 IP 未列在 SPF 中，来自新服务器的出站邮件将被拒绝或直接进入垃圾箱。
常见 MX 记录问题及其解决方法
这些是设置域名电邮时报告最频繁的问题，以及系统地解决每个问题的诊断步骤。
问题：能发送电邮但无法接收
最常见的原因是 MX 记录仍然指向旧服务器，或 TTL 尚未过期。运行 dig MX yourdomain.com @8.8.8.8 检查 Google 的 DNS 解析器是否已看到更新的 MX。如果仍显示旧值，在进一步调查前等待 TTL 过期。
问题：出站邮件被 SMTP 错误拒绝
仔细阅读退回邮件。550 5.7.1 SPF check failed 意味着您的发送服务器 IP 不在 SPF 记录中。550 5.7.26 This message fails DMARC 意味着 DKIM 或 SPF 失败且您的 DMARC 策略设置为 reject。使用这些命令检查您的当前记录：
# 检查 SPF 记录 dig TXT yourdomain.com | grep spf # 检查 DMARC 记录 dig TXT _dmarc.yourdomain.com # 检查 DKIM（用您实际的选择器替换"default"） dig TXT default._domainkey.yourdomain.com
问题：电邮已发送但很长时间没收到回复
目标服务器可能在使用灰名单——一种垃圾邮件防护技术，暂时拒绝未知发件人并等待重试。配置正确的邮件服务器会在 5–30 分钟内自动重试。检查您的邮件服务器的出站队列以确认邮件已安排重试。如果队列为空且邮件未送达，检查您的服务器 IP 是否被列入黑名单。
迁移电邮托管：逐步 MX 切换计划
从一个电邮托管提供商迁移到另一个是最精细的 DNS 操作之一。如果迁移规划不周，切换期间传输中的电邮可能永久丢失。按照以下顺序进行平稳、低中断的切换：
- 在迁移日期至少 24 小时前将 MX TTL 降低到 300 秒
- 配置并测试新邮件服务器——在触及任何实时 DNS 前确认它可以接收测试电邮
- 导出现有邮箱使用 IMAP 同步或 PST/Mbox 导出作为备份
- 切换 MX 记录在低流量期间（建议晚上）指向新服务器
- 验证传播使用
dig MX @8.8.8.8和dig MX @1.1.1.1从两个独立解析器 - 更新 SPF、DKIM 和 DMARC以匹配新服务器——不要跳过这一步
- 监控入站和出站电邮 48 小时切换后
迁移提示：在切换 MX 记录后至少保持旧邮件服务器运行 48–72 小时。在传播完成前在远程服务器上排队的某些邮件仍会尝试投递到旧服务器。立即关闭它会冒失去这些邮件的风险。