- 正确的 MX、A/AAAA 和 PTR 记录可确保电子邮件被路由并识别到正确的邮件服务器。
- TXT 记录中的 SPF、DKIM 和 DMARC 用于验证发件人身份并定义如何处理可疑邮件。
- 支持 NS、SOA、SRV、TLSA 和 BIMI 等 DNS 记录可提高一致性、安全性和品牌信任度。
- 大多数邮件送达率问题都可以追溯到 DNS 配置错误、传播延迟或缺少身份验证。
电子邮件对 DNS 的依赖程度远超大多数人的想象。每次点击“发送”按钮时，都会有一系列 DNS 查询悄悄决定您的邮件是进入收件箱、被归入垃圾邮件箱，还是被彻底拦截。如果您的电子邮件 DNS 配置错误，即使是精心策划的营销活动或最重要的交易邮件也可能就此消失。
如果你觉得 DNS 神秘莫测或过于技术化，你并不孤单。许多经验丰富的IT专业人士仍然认为网站托管和电子邮件必须放在同一台服务器上，但实际上DNS允许您根据需要拆分服务。好消息是：一旦您了解了电子邮件的核心DNS记录——MX、SPF、DKIM、DMARC以及其他一些记录——您就可以构建一个稳定、安全且送达率高的电子邮件系统，并且该系统大部分功能都可以自动运行。
什么是 DNS？它为什么对电子邮件如此重要？
DNS（域名系统）是互联网的地址簿人类喜欢这样的名字 您的公司网站但是，计算机之间通过 IP 地址进行通信，例如 203.0.113.10 or 2001：db8 :: 1DNS 将域名转换为这些数字地址，以便浏览器、应用程序和邮件服务器知道从哪里连接。
当你在浏览器中输入域名时，DNS 查询便会开始一段短暂的旅程。您的设备请求 递归解析器 （通常由您的互联网服务提供商或公共 DNS 服务商，例如 Google 或 Cloudflare 运行），其中可能已经缓存了答案。如果没有，解析器将遍历一系列服务器： 根名称服务器，则 顶级域名服务器 （例如 .com、.net、.org 等），最后是 权威名称服务器 对于该特定域名而言，最后一个服务器保存着DNS记录，这些记录告诉互联网如何处理该域名的流量。
当涉及到电子邮件时，也会发生完全相同的情况。发送服务器会查询 DNS 以确定三件重要的事情：将某个域的邮件投递到哪里、哪些服务器可以从该域发送邮件，以及邮件是真实的还是伪造的。如果这些 DNS 记录缺失、错误或不完整，您就会看到邮件被退回、被放入垃圾邮件文件夹，或者发件人信誉受损。
电子邮件如何通过 DNS 传输
每封外发邮件都会至少触发一次 DNS 查询。当有人发送消息给 user@yourcompany.com发送邮件服务器会向 DNS 服务器查询：“哪个服务器处理此域的邮件？” 它会查找…… MX记录 首先，如果存在 MX 记录，它们指向接收邮件服务器的域名。如果 MX 记录不存在，大多数系统会回退到域的 . A 或 AAAA 记录但对于专业安装来说，这并不推荐。
邮件送达率和安全性不仅仅取决于知道邮件寄往何处。现代接收服务器也会查询 DNS 以获取更多信息。 防晒指数 （发件人政策框架）， DKIM （域名密钥识别邮件），以及可选的 DMARC （基于域的消息认证、报告和一致性）。这些记录告知收件人消息是否真的来自授权来源，以及如何处理可疑消息。
在后台，几种不同类型的服务器协同工作来传输消息。寄出的邮件通常通过…… SMTP服务器 简单邮件传输协议 (SMP) 与邮件传输代理 (MTA) 配合使用，通过互联网传输邮件。在接收端，用户可以使用以下两种方式之一来获取邮件： POP3 （通常会从服务器下载并删除邮件） IMAP （它将消息保存在服务器上并在设备间同步）。所有这些组件都依赖 DNS 记录来确定要联系的主机名和 IP 地址。
电子邮件相关的核心 DNS 记录类型，您必须了解。
并非所有DNS记录都直接影响电子邮件，但其中一些至关重要。 用于路由、身份验证和垃圾邮件过滤。其他服务则在可靠性和信任方面发挥辅助作用。
A 和 AAAA 记录：将您的域名映射到 IP 地址
A 记录将域名连接到 IPv4 地址 （例如， 93.184.216.34如果没有至少一条有效的 A 记录，您的域名实际上在互联网上就不存在。许多服务在 MX 记录缺失或配置错误时也会依赖 A 记录——您需要通过发布正确的 MX 记录来避免这种情况。
AAAA 记录是 IPv6 中 A 记录的对应物。它将域名映射到 IPv6 地址，随着 IPv4 地址空间的日益枯竭，这一点变得越来越重要。虽然 A 和 AAAA 记录并不定义邮件的投递位置，但它们将您的域名与实际的基础设施关联起来，并且在 MX 记录缺失时可以用作备用邮件路由。
MX唱片：告诉全世界邮件应该投递到哪里
MX（邮件交换）记录是电子邮件 DNS 的基石。它们声明哪些服务器接受来自您域的传入邮件。每个 MX 记录都包含一个 优先 （数值越低越好）和 主机 （不是原始 IP 地址）邮件服务器的地址。接收服务器会按优先级对 MX 记录进行排序并按顺序尝试，从而提供内置的冗余。
一个域名可以只使用一条 MX 记录，但强烈建议使用多条记录。 为了提高系统弹性。许多托管电子邮件解决方案，例如 Microsoft 365 或 Google Workspace，都提供一个主 MX 值，但大型基础架构通常会发布多个具有不同优先级的 MX 记录，这样即使一台服务器宕机，另一台服务器仍然可以接收邮件。
配置 MX 记录时，您的 DNS 提供商不会自行创建这些值。您的电子邮件服务提供商会提供确切的主机名、优先级以及任何特殊要求。您通常需要在 DNS 控制面板中设置：主机名或名称（通常为 1234567）。 @ 对于根域），优先级编号，邮件服务器主机名（例如 smtp.provider.com），以及 TTL（生存时间），用于控制缓存。
TXT 记录：现代电子邮件安全的容器
TXT 记录存储附加到您域名的任意文本电子邮件系统大量使用它们来存储策略和身份验证数据。SPF 和 DMARC 存储在 TXT 记录中，DKIM 通常也存储在 TXT 记录中（尽管有些提供商通过 CNAME 来公开 DKIM）。
由于 TXT 记录可以包含任何内容，因此它们也被用于域名所有权检查。 （例如，由电子邮件服务提供商、网络服务商或 SSL 提供商提供），以及用于机会加密提示和 BIMI 品牌标识等高级功能。对于电子邮件发件人而言，三种关键的基于 TXT 的机制是 SPF、DKIM 和 DMARC。
SPF：授权可以代表您的域名发送邮件的服务器
SPF 是一个电子邮件身份验证框架，它回答一个问题“是否允许此 IP 或服务器使用此域名作为发件人地址发送邮件？” 您可以将策略发布为 TXT 记录，该记录通常以以下内容开头： v = spf1 并以诸如以下的限定词结尾： -all, ~全部 或 ？全部.
简单的SPF策略可能只允许来自您域名自身MX主机的邮件。例如： “v=spf1 mx -all”该行代码指示收件人仅接受来自您 MX 记录所用 IP 地址的邮件，并将所有其他来源视为未经授权的邮件。如果您还通过新闻通讯工具、CRM 或云服务发送邮件，则需要扩展此策略。 包括 每个提供商的 SPF 域的声明。
典型的多服务 SPF 策略会将多个包含项链接到一个记录中。例如，如果您同时使用主服务提供商、客服平台和交易邮件服务发送邮件，最终结果可能如下： v=spf1 a mx include:service1.com include:service2.com ~all您的电子邮件平台通常会提供您必须添加的确切字符串和语法。
每个域名只需维护一条 SPF TXT 记录即可，这一点非常重要。在同一个 DNS 名称下堆叠多个 SPF 记录可能会破坏验证。因此，应将所有必需的机制合并到一个精心管理的策略中，并在添加或删除发送服务时更新该策略。
DKIM：使用加密指纹对消息进行签名
DKIM（域名密钥识别邮件）提供防篡改签名。 在发送邮件时，您的发送系统会使用私钥，根据某些邮件头（有时也包括邮件正文）生成哈希值。此签名会写入一个特殊的邮件头字段中。
相应的公钥存储在DNS中。DKIM 选择器（类似这样的小标签） mail or mlsend2加上域名，就构成了公钥记录的主机名，通常类似于这样 selector._domainkey.yourcompany.com当接收系统收到电子邮件时，它会查看 DKIM 标头，查询 DNS 以获取该选择器，获取公钥，并检查签名是否有效以及内容是否已被更改。
DKIM 可以发布为 TXT 记录或 CNAME 记录。许多服务商会提供以“.”开头的大额 TXT 充值卡。 v=DKIM1 以及一段漫长的 p= 包含 base64 编码的公钥的字段。其他服务商则要求您创建一个从您的选择器主机名指向他们托管的主机的 CNAME 记录，这样他们就可以集中轮换密钥，而无需您每次都编辑 DNS。
每个发送域通常至少有一个 DKIM 选择器不同的服务可能使用各自的 DKIM 记录。这完全没问题；只要选择器不同，您可以拥有多个 DKIM 记录。您的电子邮件服务提供商会告诉您需要添加哪些内容，通常只需将其复制粘贴到您的 DNS 控制面板即可。
DMARC：通过策略将 SPF 和 DKIM 结合起来
DMARC（基于域的消息认证、报告和一致性）建立在 SPF 和 DKIM 之上。它不直接验证邮件的真实性；而是检查邮件是否通过了 SPF 和/或 DKIM 验证，以及验证结果是否与显示的“发件人”域一致。然后，它会应用您定义的策略，以说明如果检查失败应该如何处理。
DMARC 策略存储在特殊主机名的 TXT 记录中 _dmarc.yourcompany.com记录以……开始 v=DMARC1 并包含如下标签 p= （策略：无、隔离或拒绝）以及地址举报选项。借助 DMARC，您可以指示接收方仅进行监控（不强制执行）、将失败邮件标记为垃圾邮件，或直接屏蔽这些邮件。
DMARC 的报告功能是安全性和送达率方面的一项隐藏瑰宝通过在……中指定地址 街道 和 RUF 通过标签，您可以要求接收方发送关于身份验证结果的汇总报告或取证报告。这些报告可以帮助您发现未经授权的发件人、配置错误的服务或被滥用于网络钓鱼的域名。
其他影响电子邮件的 DNS 记录
除了 MX、SPF、DKIM 和 DMARC 之外，还有一些 DNS 记录类型会影响您的邮件是否受信任以及是否能成功送达。虽然它们可能并非绝对必要，但它们经常出现在送达率检查清单和反垃圾邮件逻辑中。
PTR（反向 DNS）：验证发送 IP
PTR 记录执行的是与普通 DNS 查询相反的操作。它不是将域名映射到 IP 地址，而是将 IP 地址映射回主机名。这种反向映射称为 反向 DNS 或反向域名系统 (rDNS)。
接收邮件服务器会定期检查发送邮件 IP 的反向 DNS。如果邮件中没有 PTR 记录，或者 PTR 记录返回的主机名与邮件头中的域名不匹配，一些邮件服务商会将邮件视为可疑邮件。这可能会触发“反向 DNS 解析失败”之类的错误，或者导致邮件被拒收，并显示与缺少 PTR 记录相关的错误代码。
实际上，您很少会在常规 DNS 区域中管理 PTR 记录。它们由拥有该IP地址段的一方控制——通常是您的互联网服务提供商 (ISP)、主机托管商或电子邮件平台。对于专用邮件服务器，您通常需要请求提供商设置指向您选择的主机名的PTR记录，然后确保该主机名也具有匹配的A或AAAA记录。
SRV、NS 和 SOA：支持一致交付的基础设施
SRV（服务）记录描述特定协议的主机和端口对于电子邮件，它们可以引导客户端访问正确的 SMTP、IMAP 或 POP 服务器和端口。虽然它们不能直接控制邮件送达率，但 SRV 记录可以帮助自动配置工具发现正确的端点。
NS（名称服务器）记录定义了哪些名称服务器对您的域具有权威性。这些服务器存储并响应您的 DNS 数据。如果 NS 记录错误，DNS 提供商之间的不一致可能会导致邮件行为不可预测，因为某些发件人可能会看到过时或不完整的记录。
SOA（起始授权）记录标识主名称服务器 它提供区域的详细信息，例如区域文件的序列号以及用于缓存和刷新的计时值。它不直接控制电子邮件逻辑，但正确的 SOA 配置对于可靠地复制和传播邮件相关更改至关重要。
BIMI 和 TLSA：高级信任和加密信号
BIMI（邮件识别品牌标识）允许您在兼容的收件箱中显示您的徽标。从技术上讲，它使用指向您徽标 SVG 图像的 TXT 记录，并且在许多情况下，它依赖于已验证的品牌证书和强制执行的 DMARC 策略。虽然 BIMI 本身无法解决送达率问题，但它是一种视觉信任信号，可以在您的身份验证机制稳固之后提升用户参与度。
TLSA 记录支持 DANE（基于 DNS 的命名实体认证）。TLSA 通过 DNSSEC 将 TLS 证书绑定到 DNS 名称。对于电子邮件，TLSA 可以通过指定哪些证书有效来强化邮件服务器之间的 STARTTLS 连接。这有助于防止针对 SMTP 的中间人攻击，但实际上它需要 DNSSEC，并且仍然不如 SPF/DKIM/DMARC 普遍。
为您的电子邮件提供商配置 DNS
大部分繁重的工作都由您的电子邮件托管商完成。它会提供您必须添加的确切 DNS 条目。您的任务是将这些值复制到域名注册商或 DNS 服务商处正确的记录类型中，并仔细检查是否有拼写错误。
逐步操作：添加和验证 MX 记录
要将您域名的电子邮件指向特定的服务提供商，首先需要设置 MX 记录。注册托管电子邮件或云平台后，请查找其关于“DNS 设置”或“邮件交换记录”的文档。文档中会列出您必须使用的主机名和优先级。
在 DNS 管理控制台中，找到添加新记录的选项 并选择类型 MX对于主机名或名称，域名通常使用 @ 表示根（例如， 您的公司网站将邮件服务器主机名粘贴为值，设置所需的优先级，除非另有说明，否则保留默认的 TTL，然后保存。对他们提供的任何其他 MX 记录重复此操作。
MX记录保存后，会有一个传播期。互联网上的 DNS 缓存需要时间来清除旧数据。新的邮件路由生效可能需要几分钟到几小时，有时甚至长达 24-48 小时。在此期间，部分发件人可能仍会将邮件投递到旧的地址。
在您的 DNS 中发布 SPF
邮件路由设置完成后，发布 SPF 记录以声明哪些用户可以代表您的域名发送邮件。您的主要电子邮件服务、营销平台和任何交易系统都应该在一条 SPF TXT 记录中体现。
大多数服务提供商都会向您展示所需的确切 SPF 代码片段。例如，发送平台可能会说：“添加一条名为 TXT 的记录” @ 和价值 v=spf1 include:_spf.example.com ~all“如果您已经有一个 SPF 记录，请将新的包含项合并到该记录中，而不是创建同名的第二个记录。
选择使用 -all 还是 ~all 会影响接收器处理故障的严格程度。彻底失败（-all表示任何未明确列出的发送源都应被拒绝，而软失败（~全部通常情况下，系统会允许邮件通过，但可能会将其标记为垃圾邮件。许多组织在审核所有发送系统时，会先采用软性限制，然后随着时间的推移逐步实施更严格的策略。
添加来自服务提供商的 DKIM 密钥
只要在服务提供商的控制面板中找到正确的界面，DKIM 设置通常就很简单。查找标有“域身份验证”、“DKIM”或“电子邮件签名”的部分。您会看到一个或多个选择器以及TXT值或CNAME目标。
如果您的提供商提供了 TXT 记录，请在选择器主机名处创建 DNS 条目 （例如， selector._domainkey.yourcompany.com）并粘贴他们提供的长 DKIM 字符串。如果他们要求的是 CNAME 记录，您需要将选择器主机名指向他们的主机名，这实际上是告诉外界直接从您的 DNS 服务器获取密钥。
许多服务要求您点击“验证”或“检查 DNS”按钮。 添加 DKIM 后，对方会进行密钥查询；一旦验证通过，他们就会开始对发送的邮件进行签名。在验证通过之前，邮件可能未经 DKIM 验证就被发送出去，从而削弱您的身份验证。
安全地推出DMARC政策
DMARC部署最好分阶段进行。首先要制定一项政策： 没有该功能要求接收方报告失败情况，但不会阻止任何邮件。这样您就可以查看谁在代表您的域名发送邮件，以及 SPF 和 DKIM 是否正确匹配。
一个基本的 DMARC 记录可能看起来像一个位于 _dmarc.yourcompany.com 的 TXT 文件。 例如，具有这样的值 v=DMARC1; p=none; rua=mailto:reports@yourcompany.com在分析报告并弥补任何不足之后，您可以将政策提升至…… 检疫 （将可疑邮件发送到垃圾邮件箱）并最终 拒绝 如果您想要最大程度地防止欺骗攻击。
许多电子邮件客户端，尤其是大型服务提供商，现在都要求发送大量邮件的域名启用 DMARC。结合正确配置的 SPF 和 DKIM，强大的 DMARC 策略是表明您的域名管理良好且不会遭到滥用的最清晰信号之一。
基于 DNS 的垃圾邮件预防和发件人信誉
现代垃圾邮件过滤器严重依赖 DNS 数据来判断是否信任电子邮件。他们在决定如何处理每条消息时，会查看 MX、SPF、DKIM、DMARC、PTR，甚至 A 记录和 NS 记录的一致性。
当 SPF、DKIM 和 DMARC 全部正确配置时，您的域名就能建立良好的信誉。随着时间的推移，互联网服务提供商 (ISP) 会发现，通过身份验证发送的邮件可以降低投诉率并保持稳定的互动。相反，缺失或损坏的 DNS 记录则是一个危险信号：邮件可能仍然会到达，但更有可能被标记为垃圾邮件或直接拦截。
DNS 还有助于保护收件人免受网络钓鱼和欺骗的侵害。攻击者喜欢伪造发件人地址，冒充知名品牌或内部员工。SPF、DKIM 和 DMARC 可以大大增加这种攻击的难度。收件人可以安全地丢弃或隔离那些伪装成来自您域名但违反已发布策略的邮件。
当然，邮件送达率不仅仅取决于域名系统解析 (DNS)。内容质量、发送量、邮件列表维护、投诉率和用户互动都很重要。但如果没有稳固的 DNS 基础，即使是完美的内容也无法消除未经认证或配置错误的邮件所带来的疑虑。
排查由 DNS 引起的常见电子邮件问题
邮件服务出现故障时，DNS 通常是罪魁祸首。症状各不相同——从带有数字 SMTP 代码的硬退信到邮件悄无声息地消失在垃圾邮件中——但在许多情况下，根本原因在于缺少或无效的 DNS 记录。
邮件被退回或直接被拒绝
出现 550、554 等错误代码或提及无效域名的硬退信通常指向 DNS 配置问题。两个常见的违规行为是缺少 MX 记录和 SPF 策略，其中不包含实际的发送 IP 或服务。
如果错误提示“缺少 A 记录或 MX 记录”或“邮件服务器域无效”，请检查您的区域。确认发件人地址中的域名具有有效的 A 记录，至少有一条指向可解析主机名的 MX 记录，并且这些主机名本身具有有效的 A 或 AAAA 记录。主机名中的任何拼写错误都可能导致链中断。
引用反向 DNS 故障或黑名单 IP 的拒绝通常可以追溯到 PTR 记录。检查您的发送 IP 是否具有解析到您控制的主机名的 PTR 记录，并且该主机名是否具有匹配的 A 记录。如果不是，请联系您的电子邮件或主机提供商，要求他们更正反向 DNS 设置。
邮件不断被误判为垃圾邮件。
如果你的邮件发送成功但总是被判定为垃圾邮件，首先要检查你的身份验证机制。使用在线工具验证您域名的 SPF、DKIM 和 DMARC。任何验证失败或警告都表明接收邮件系统对您的流量并不完全信任。
检查可见的“发件人”地址中的域名是否与您的 SPF 和 DKIM 记录一致。对于 SPF，信封发件人（Return-Path）域必须经过授权。对于 DKIM，DKIM 标头中的 d= 值应为您拥有的域，并且理想情况下应与发件人域匹配或一致。DMARC 会评估这种匹配情况，以确定如何对邮件进行评分。
用户行为也会影响垃圾邮件算法如果许多收件人不看邮件就删除、根本不打开邮件或将邮件标记为垃圾邮件，即使您的 DNS 服务再好，您的信誉也会下降。将强大的 DNS 认证与良好的邮件发送实践相结合才是制胜之道。
网页表单或应用程序发送的邮件从未送达。
当网站联系表单或应用程序显示“发送”电子邮件但实际却收不到任何邮件时，通常是 SPF 配置错误。. 网络服务器的 IP 地址或平台的邮件程序可能未包含在您的 SPF 记录中，因此收件人会将邮件视为可疑邮件或直接拒绝接收。
如果您的网站使用主邮箱提供商的域名发送邮件。请确认实际的发送服务器（例如，您的网站托管商或事务型电子邮件服务提供商）已出现在 SPF 策略中。在某些情况下，使用专用子域名和已配置的电子邮件服务提供商比依赖网站托管商的默认邮件功能更好。
处理 DNS 传播延迟
每次更改 MX、SPF、DKIM 或 DMARC 记录时，请给互联网一些时间来更新。DNS 的工作原理是缓存：解析器会将响应信息保留一段 TTL（生存时间），TTL 可以是几分钟或几小时。在此期间，一些发送方会看到新的配置，而另一些发送方仍然使用旧的配置。
如果您计划进行大规模的电子邮件迁移，请提前一两天降低 TTL（生存时间）。将关键记录的 TTL 值降低到 300 秒左右，可以加快未来更改的传播速度。切换稳定后，您可以再次提高 TTL 值，以提高性能并减少查询次数。
通过多个网络进行测试并使用外部 DNS 查询工具有助于确认传播何时真正完成。不要仅仅依赖本地解析器，因为它可能会过度缓存或以不寻常的方式配置。
总而言之，电子邮件的 DNS 与其说是魔法，不如说是精心协调的记录。当 MX、SPF、DKIM、DMARC、PTR 以及其他辅助条目准确且一致时，您的域名在邮件服务商眼中就成为了值得信赖的发件人。这种信任，再加上干净的邮件列表和精心撰写的内容，就能确保您的邮件顺利送达收件箱，并让您的品牌远离垃圾邮件箱。
