第三章:邮件基础架构与DNS记录

第三章:邮件基础架构与DNS记录

注册了域名,并不代表你能用这个域名发邮件。邮件有一套完整的基础架构,绕不开它,你的邮件就是垃圾邮件。


3.1 邮件系统的工作原理

理解邮件工作原理,需要了解邮件从发出到收到的完整链路。

一封邮件的旅程

假设你用 hello@example.comuser@gmail.com 发邮件:

[1] 你的邮件客户端(Outlook/Thunderbird/Gmail)
      ↓ SMTP(提交)
[2] 你的邮件服务器(发件 MTA)
      ↓ DNS查询:gmail.com 的 MX 记录
[3] 找到 gmail.com 的邮件服务器(如 gmail-smtp-in.l.google.com)
      ↓ SMTP(传输)
[4] Google 的接收服务器(收件 MTA)
      ↓ 验证:SPF、DKIM、DMARC
[5] 反垃圾过滤、病毒扫描
      ↓ 存储
[6] 用户收件箱(IMAP/POP3)

核心协议

协议 全称 用途 端口
SMTP Simple Mail Transfer Protocol 发送邮件 25/465/587
IMAP Internet Message Access Protocol 收件(多设备同步) 143/993
POP3 Post Office Protocol v3 收件(下载到本地) 110/995

端口说明

  • 25:服务器间传输(MX to MX),普通用户的 ISP 通常封锁此端口
  • 587:邮件客户端提交(SMTP Submission),需要认证,这是你应该用的端口
  • 465:SMTP over SSL(历史遗留,已废弃但很多服务仍支持)
  • 993:IMAP over SSL(安全收件)
  • 995:POP3 over SSL

3.2 MX 记录:邮件入口的路牌

MX(Mail Exchange)记录告诉发件服务器:往这个域名发邮件,应该连接哪台服务器。

MX 记录结构

域名          TTL     类型    优先级   邮件服务器
example.com   3600    MX      10       mail1.example.com
example.com   3600    MX      20       mail2.example.com

优先级(Priority):数字越小优先级越高。发件服务器会先尝试优先级最高的服务器,失败后才尝试次高的。这提供了邮件传输的容错能力

常见 MX 配置示例

Google Workspace

MX  @  1   aspmx.l.google.com
MX  @  5   alt1.aspmx.l.google.com
MX  @  5   alt2.aspmx.l.google.com
MX  @  10  alt3.aspmx.l.google.com
MX  @  10  alt4.aspmx.l.google.com

Microsoft 365

MX  @  0   company-com.mail.protection.outlook.com

Zoho Mail

MX  @  10  mx.zoho.com
MX  @  20  mx2.zoho.com
MX  @  50  mx3.zoho.com

Postmark(只发信,不收信,不需要 MX): Postmark 是事务性邮件发送服务,不用设置 MX 记录(除非你还需要接收回复)。

什么情况下没有 MX 记录

如果你的域名只用来发邮件(如系统通知),不需要接收外部邮件,可以不设置 MX 记录,或者设置一个空 MX(优先级0,指向空字符串),明确表示不接收邮件,防止发件服务器尝试发给错误地址。


3.3 SPF:告诉世界谁有权代替你发邮件

SPF(Sender Policy Framework)是最早的邮件验证标准之一(RFC 4408,2006年)。它通过 DNS TXT 记录声明:哪些 IP 或服务器被授权以你的域名发送邮件。

SPF 的工作流程

  1. 你在 DNS 里发布 SPF 记录
  2. 收件方服务器收到邮件后,查看"信封发件人"(Envelope From,也叫 Return-Path)
  3. 查询该域名的 SPF 记录
  4. 检查发件服务器的 IP 是否在授权列表中
  5. 返回 Pass / Fail / SoftFail / Neutral

SPF 记录语法

v=spf1 [mechanisms] [qualifier]all

常用 Mechanism

机制 含义 示例
ip4: 指定 IPv4 地址/段 ip4:192.168.1.0/24
ip6: 指定 IPv6 ip6:2001:db8::/32
include: 包含另一域名的 SPF include:_spf.google.com
a 该域名的 A 记录所在 IP a
mx 该域名的 MX 记录所在 IP mx
all 匹配所有(放在末尾) -all

Qualifier(前缀修饰符)

修饰符 含义 效果
+(默认) 通过 邮件被接受
- 硬失败 邮件应被拒绝
~ 软失败 邮件被接受但标记可疑
? 中立 无明确结论

真实 SPF 记录示例

使用 Google Workspace 发邮件

v=spf1 include:_spf.google.com ~all

使用 Google Workspace + Postmark + 自有服务器

v=spf1 include:_spf.google.com include:spf.mtasv.net ip4:192.168.1.100 ~all

只用 SendGrid

v=spf1 include:sendgrid.net ~all

SPF 的限制:DNS 查询次数上限

SPF 规范限制最多 10 次 DNS 查询(include、a、mx 等都算)。超过 10 次时,SPF 验证结果为 PermError,相当于失败。

随着使用的邮件服务增多(Google + Postmark + Mailchimp + Salesforce…),很容易超过 10 次限制。

解决方案

  1. 使用 SPF 扁平化工具(如 SPF Flattening),将 include 展开为实际 IP 段
  2. 使用商业工具如 Dmarcian、EasyDMARC 自动管理

SPF 验证工具


3.4 DKIM:给邮件加数字签名

DKIM(DomainKeys Identified Mail)通过公私钥对给邮件内容加数字签名,允许收件方验证邮件确实由声称的域名发出,且内容在传输中未被篡改。

DKIM 的工作原理

  1. 发件方:用私钥对邮件头部和内容(选定字段)生成哈希值,作为签名附加在邮件头里
  2. DNS 发布:公钥以 TXT 记录发布在特定子域(如 selector._domainkey.example.com
  3. 收件方:从邮件头取出签名和选择器(selector),查询对应的 DNS 公钥记录,用公钥验证签名

DKIM DNS 记录格式

selector._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."
  • selector:通常是日期(20240101)或服务商名(googlepm
  • v=DKIM1:版本
  • k=rsa:密钥类型(RSA 或 ed25519)
  • p=:Base64 编码的公钥

各服务商的 DKIM 配置方法

Google Workspace

  1. Google Admin → Apps → Google Workspace → Gmail → Authenticate email
  2. 点击"Generate new record"
  3. 复制生成的 TXT 记录到 DNS
  4. 点击"Start authentication"

Postmark

  1. Postmark 控制台 → Sender Signatures → 你的发件人
  2. 点击 DKIM tab
  3. 复制 pm._domainkey.yourdomain.com 的 TXT 记录到 DNS
  4. 等待验证(通常几分钟)

SendGrid

  1. Settings → Sender Authentication → Authenticate Your Domain
  2. 选择 DNS 提供商,按引导配置 CNAME 记录(SendGrid 用 CNAME 指向他们的密钥)

为什么 DKIM 比 SPF 更强

SPF 只验证发件服务器的 IP,但 SPF 验证的是信封发件人(Envelope From),不是"From"头(用户看到的发件人)。DKIM 签名绑定了邮件内容和特定域名,更难伪造。


3.5 DMARC:政策执行者

SPF 和 DKIM 分别验证不同的东西,但都不强制要求通过。DMARC(Domain-based Message Authentication, Reporting, and Conformance)是一个策略层,定义:当 SPF 或 DKIM 验证失败时,收件方应该怎么处理这封邮件。

DMARC 的三个核心功能

  1. 指定处理策略:通过(pass)、隔离(quarantine)、拒绝(reject)
  2. 要求对齐(Alignment):DKIM 签名域名或 SPF 返回路径域名必须与"From"头域名一致
  3. 聚合报告(RUA)和取证报告(RUF):收集各邮件服务商的验证结果报告

DMARC 记录格式

_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; pct=100"
标签 含义
v=DMARC1 版本 必填
p= 策略 none/quarantine/reject
rua= 聚合报告发送地址 mailto: URL
ruf= 取证报告发送地址 mailto: URL
pct= 策略应用百分比 1-100,默认100
adkim= DKIM 对齐模式 r(宽松)/s(严格)
aspf= SPF 对齐模式 r(宽松)/s(严格)
sp= 子域名策略 none/quarantine/reject

DMARC 策略选择

p=none(监控模式)

  • 不过滤任何邮件,只收集报告
  • 适合刚开始配置的阶段,用来了解谁在用你的域名发邮件

p=quarantine(隔离模式)

  • 验证失败的邮件进入垃圾箱
  • 过渡阶段使用

p=reject(拒绝模式)

  • 验证失败的邮件直接被拒绝(不进收件箱也不进垃圾箱)
  • 最高级别的反欺诈保护
  • 确保所有合法发件来源都配置好 SPF/DKIM 后才能开启

DMARC 部署路径(Best Practice)

第一步:p=none,收集报告 2-4 周
第二步:p=quarantine; pct=10,5% 的失败邮件进垃圾箱
第三步:p=quarantine; pct=100
第四步:p=reject; pct=10
第五步:p=reject; pct=100(目标状态)

DMARC 报告解读工具

DMARC 报告是 XML 格式,人类不可读,需要工具解析:

  • Dmarcian:业界标准,免费版可用,付费版功能更多
  • Postmark DMARC:Postmark 提供的免费报告工具(只需一个接收邮件地址)
  • EasyDMARC:可视化好,适合非技术用户
  • Google Postmaster Tools:Gmail 端的域名声誉数据,强烈建议配置

3.6 BIMI:让你的 Logo 出现在邮件中

BIMI(Brand Indicators for Message Identification)是最新的邮件认证标准,允许通过验证的发件人在支持的邮件客户端(Gmail、Apple Mail、Yahoo)中显示品牌 Logo。

BIMI 的要求

  1. DMARC 策略必须是 p=quarantinep=reject(不能是 none
  2. Logo 必须是 SVG 格式(Tiny PS 规范)
  3. 对于 Gmail,还需要 VMC(Verified Mark Certificate),由 DigiCert 或 Entrust 颁发,每年约 $1,000-2,000(2024 年情况)
  4. Logo 要已注册为商标(有些提供商要求)

BIMI DNS 记录

default._bimi.example.com  TXT  "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"
  • l=:SVG Logo 的 HTTPS URL
  • a=:VMC 证书的 URL

哪些邮件客户端支持 BIMI

  • Gmail(需要 VMC)
  • Yahoo Mail(不需要 VMC)
  • Apple Mail(iOS 16+/macOS Ventura+)
  • Fastmail

BIMI 目前仍在推广中,主要价值是品牌可信度提升,减少用户把邮件误判为垃圾邮件。


3.7 反向 DNS(PTR 记录)与发件 IP 声誉

当你用自己的服务器发邮件时,除了上面的 DNS 记录,还需要关注:

PTR 记录(反向 DNS)

PTR 记录是 A 记录的反向:将 IP 地址映射到域名。

34.216.184.93.in-addr.arpa  PTR  mail.example.com

收件服务器会做反向 DNS 查询:如果发件 IP 没有 PTR 记录,或 PTR 记录与 HELO/EHLO 中声称的主机名不匹配,会大幅降低邮件信任度。

配置 PTR 记录:不在你的 DNS 提供商配置,而是在你的服务器 IP 所属的 ISP/云服务商处配置:

  • AWS EC2:在 Elastic IP 页面设置 Reverse DNS
  • DigitalOcean:在 Networking → Domains 配置
  • 阿里云/腾讯云:工单申请

为什么自建邮件服务器越来越难

2024-2025 年,Gmail 和 Yahoo 相继收紧了对批量发件方的要求(每天发 5000+ 封邮件的必须配置 DKIM、DMARC,且对齐)。此外:

  1. 新 IP 的声誉为零,需要"预热"(逐步增加发信量)
  2. 动态 IP 通常被主要邮件服务商黑名单
  3. 共享托管 IP 可能因其他租户的垃圾邮件行为被连累
  4. 维护难度高,24 小时监控

结论:除非你是大型企业邮件团队,自建邮件服务器的 ROI 极低,使用专业服务商(Google Workspace + Postmark)是更理智的选择。


3.8 完整的邮件 DNS 配置清单

以下是使用 Google Workspace 收发邮件 + Postmark 发事务性邮件的完整 DNS 配置:

; ── MX(用 Google Workspace 收邮件)──
@  MX  1   aspmx.l.google.com
@  MX  5   alt1.aspmx.l.google.com
@  MX  5   alt2.aspmx.l.google.com
@  MX  10  alt3.aspmx.l.google.com
@  MX  10  alt4.aspmx.l.google.com

; ── SPF(授权 Google 和 Postmark 发件)──
@  TXT  "v=spf1 include:_spf.google.com include:spf.mtasv.net ~all"

; ── DKIM(Google Workspace)──
google._domainkey  TXT  "v=DKIM1; k=rsa; p=<Google提供的公钥>"

; ── DKIM(Postmark)──
pm._domainkey  TXT  "v=DKIM1; k=rsa; p=<Postmark提供的公钥>"

; ── DMARC ──
_dmarc  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

3.9 邮件验证状态检查

验证工具汇总

工具 检查内容 地址
MXToolbox MX/SPF/DKIM/DMARC 全检 mxtoolbox.com
Mail Tester 发一封测试邮件,打分评估 mail-tester.com
GlockApps 收件箱率测试(多 ISP) glockapps.com
Google Postmaster Gmail 域名声誉 postmaster.google.com
Dmarcian DMARC 报告分析 dmarcian.com
Check-Auth 查看邮件头部验证结果 发到 check-auth@verifier.port25.com

如何用 Gmail 查看验证结果

在 Gmail 中打开一封你发的邮件,点击右上角"更多"→“显示原始邮件”,查找:

Authentication-Results: mx.google.com;
   dkim=pass header.i=@example.com header.s=google header.b=...;
   spf=pass (google.com: domain of hello@example.com designates ... as permitted sender);
   dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

三项都是 pass 就是完美配置。


小结

邮件的 DNS 基础架构是一个系统工程:

  1. MX 告诉世界哪台服务器接收你的邮件
  2. SPF 声明哪些服务器有权以你的名义发邮件
  3. DKIM 给每封邮件加数字签名,防止伪造和篡改
  4. DMARC 是策略执行者,定义验证失败时的处理方式,并收集报告
  5. BIMI 是锦上添花,让你的 Logo 出现在收件箱
  6. 自建邮件服务器在 2025 年已经得不偿失,使用专业服务是正确选择

配置好这些,你的邮件才有资格进入用户的收件箱。下一章,我们看具体的邮件服务方案该如何选择。