电子邮件协议排障：SMTP、IMAP、MIME与SPF/DKIM/DMARC

排查邮件问题这件事，我干过太多次了。印象最深的一次是某个内部系统发出的通知邮件，一部分收件人能收到，另一部分直接进垃圾箱，日志里干干净净，什么错都没有。当时我第一反应是查业务代码，翻了两小时没看出问题，最后把原始报文抓下来一看，From头写的是系统账号，MAIL FROM却是另一个域，正文里还塞了一张巨大的 base64 图片——问题全在协议层。从那以后我就认定一件事：电子邮件协议不是“老古董知识”，而是排障和做系统对接时绕不开的基本功。SMTP 管发，IMAP 管收，MIME 管内容怎么装，SPF、DKIM、DMARC 管这封信凭什么被信任，四块拼起来才是一套完整的认知。下面这些内容，是给需要做邮件对接的后端、要维护发信通道的运维、以及正在被“邮件进垃圾箱”折磨的同行准备的，从报文级细节一直讲到能直接抄的代码和配置，新手能照着跑通，老手也能在排查思路那几节里找到点共鸣。

1. 邮件系统的四层分工：先搞清谁在什么时候出场

很多人学邮件协议卡住，不是因为命令记不住，而是因为脑子里没有一张“谁把信交给谁”的图。SMTP 只是其中一段，把整条链路画出来，后面所有奇怪的报错都能对号入座。

1.1 一封信的三段旅程与两套身份

一封邮件从按下发送到躺进对方收件箱，中间至少经过三个环节：提交（Submission）、传输（Relay）、投递（Delivery）。提交是发件人的客户端把信交给自己的邮件服务器，常用 587 端口配 STARTTLS，或者 465 端口直接 TLS；传输是发件方服务器找收件方服务器，走 25 端口，这一步才是真正的服务器对服务器通信；投递是收件方服务器把信塞进某个用户的邮箱，之后客户端用 IMAP 或 POP3 去取。

这里有个特别容易被忽略、但决定了后面一大半知识点的概念：一封信有两套身份。一套叫“信封”（envelope），由 SMTP 会话里的MAIL FROM和RCPT TO决定，它只活在传输过程中，相当于快递单上的寄收信息；另一套叫“信纸”（header），就是你在邮件客户端里看到的发件人、收件人、主题，写在DATA阶段的内容里。这两套身份允许不一致，而且实际系统里经常不一致。

为什么要这么设计？因为信封是给传输系统看的，信头是给人看的。转发、退信、邮件列表都会让两者分离。理解了这一点，你就能明白为什么 SPF 校验的是MAIL FROM的域而不是From头，为什么 DKIM 要对信头做签名，为什么 DMARC 要专门定义“对齐（alignment）”这个概念来检查两者是否同源。所有反垃圾机制，本质上都是在想办法确认“信封和信纸说的是不是同一家”。

1.2 四类协议各管一段，边界别搞混

把协议按职责摊开，选型和排障就不会乱。

选型上我的经验很明确：收信一律用 IMAP，别碰 POP3。POP3 的设计哲学是“把信搬到本地然后删掉服务端”，多设备场景下必然出现“这台机器收到了、那台看不到”的混乱，而且它没有文件夹、没有标志位、没有 UID 增量拉取，做程序化处理非常难受。IMAP 的代价是协议复杂、状态多，第一次全量同步慢，但只要把 UID 那一套用对，增量拉取会非常省事。

发信这块有个值得说的取舍：现在很多团队直接用云厂商的邮件推送 API，而不是自己跑 SMTP。API 的好处是有投递回执、有退信分类、签名和重试都托管了；SMTP 的好处是通用、不绑定供应商、内部系统对接最省事。我的建议是面向外部用户的大批量通知走 API，内部系统之间的通知走 SMTP，两套并存很正常，别硬统一。

1.3 端口和加密方式的组合陷阱

端口这件事，踩过坑的人都知道它有多烦。同样是 587，有的服务器要求先明文EHLO再STARTTLS，有的直接拒绝明文；同样是 465，它是“隐式 TLS”，也就是连接建立的那一刻就开始 TLS 握手，不能先发明文EHLO。很多脚本报“连接被重置”，原因就是对着 465 端口发了明文命令，服务器直接掐断。

提示：写代码时不要自己拼“端口决定加密方式”的逻辑，而是把“加密模式”和“端口”作为两个独立参数传进去。生产环境里遇到非标准端口是常态，硬编码迟早出事。

还有一类更隐蔽的问题：某些网络环境下 25 端口被封，服务器之间无法直连，只能走 587 提交口做中继。这类问题在日志里表现为“连接超时”，看起来像对方服务器挂了，实际上是链路层就不通。排查时先确认端口连通性，再谈协议层，顺序不能反。

2. 报文级拆解：把信封、信纸和包装纸分开看

协议学到能用的程度，标志就是能对着一坨原始报文说出每一行是干什么的。这一节我们把 SMTP 会话、头部字段、MIME 结构、IMAP 命令模型逐个拆开。

2.1 一次 SMTP 会话到底发生了什么

下面这段是一次完整的会话记录，我把它当作“标准答案”来记，排障时逐行对照就行。

S: 220 mail.example.com ESMTP ready C: EHLO client.example.com S: 250-mail.example.com S: 250-SIZE 36700160 S: 250-8BITMIME S: 250-STARTTLS S: 250 AUTH LOGIN PLAIN C: STARTTLS S: 220 2.0.0 Ready to start TLS （TLS 握手，之后重新 EHLO） C: EHLO client.example.com S: 250-mail.example.com S: 250 AUTH PLAIN C: AUTH PLAIN <base64 凭证> S: 235 2.7.0 Authentication successful C: MAIL FROM:<sender@example.com> SIZE=20480 S: 250 2.1.0 Ok C: RCPT TO:<rcpt@example.net> S: 250 2.1.5 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: From: "系统通知" <sender@example.com> C: To: rcpt@example.net C: Subject: =?UTF-8?B?5pyI5bqm5oql6KGo?= C: Date: Tue, 09 Jan 2024 10:21:33 +0800 C: Message-ID: <20240109102133.1234@example.com> C: Content-Type: text/plain; charset="utf-8" C: C: 正文第一行 C: 正文里如果有一行以点开头，要写成两个点 C: . S: 250 2.0.0 Ok: queued as 4F2A1B7C C: QUIT S: 221 2.0.0 Bye

几个必须记住的点。EHLO不是HELO，前者是扩展模式，能拿到服务器能力清单，包括最大邮件尺寸（SIZE）、支持的认证方式、是否支持 8 位内容（8BITMIME）和管道化（PIPELINING）。看到SIZE 36700160，你就知道这台上限是 35MB，超过就会被552拒掉，这个数字决定了你附件能放多大。

返回码的语义要烂熟于心：2xx 成功，4xx 临时失败（可以且应该重试），5xx 永久失败（重试没用，别浪费资源）。我在代码里见过对着550死循环重试三天的脚本，把对方服务器惹毛了直接拉黑。4xx才是重试信号，典型如421 服务不可用、450 邮箱暂时不可用、451 本地错误。

DATA阶段的结束标志是单独一行的句号，这就是所谓的点透明（dot-stuffing）：正文里任何以点开头的行，发送时都要变成两个点，接收方再还原。如果你手写 SMTP 客户端，这一条忘了，正文会被提前截断，而且不报错，非常难查。

Message-ID和Date这两个头，很多自研脚本都不写，觉得可有可无。实际情况是，缺失或格式非法的Date是垃圾邮件评分里的经典扣分项，而重复的Message-ID会让收件方服务器把后续邮件当成重复投递直接丢弃。

2.2 From、Sender、Reply-To、Return-Path 到底谁是谁

这四个字段是邮件头里最容易被搞混的一组，我把它们的职责列清楚：

关键结论：Return-Path不是你写的，是接收方服务器根据MAIL FROM自动加上的，所以你在客户端里永远看不到自己发出的那封信的Return-Path，只有在收到的原始报文里才能看到。想查 SPF 为什么不过，第一件事就是把原始报文里的Return-Path和From拿出来对比。

还有一个字段必须提：Received链。每经过一台服务器就加一行，加在最上面。所以读Received要从下往上读，最下面那行是最早的一跳，最上面那行是最后一跳。这条链是排查延迟和丢信的金矿：你能看出这封信在哪台机器上停了几分钟，也能看出中途是不是被某个网关重写过。

2.3 MIME 结构与编码膨胀的计算

MIME 解决的是一件事：怎么在一个只支持 7 位 ASCII 的协议里，塞进中文、图片、PDF 和混合内容。它的做法是分层：最外层multipart/mixed表示“我有多个部分”，其中一个部分是multipart/alternative表示“同一内容我有纯文本和 HTML 两个版本”，再往外挂附件。

编码方式主要有两种。quoted-printable适合以 ASCII 为主、少量非 ASCII 的文本，中文会变成=E6=9C=88=E5=BA=A6这种形式，可读性差但膨胀小；base64适合二进制，通用但膨胀大。

膨胀多少是可以算的。base64 把每 3 字节编码成 4 个字符，所以：

编码后长度 = 4 × ceil(原始长度 / 3) 膨胀率 = 4/3 - 1 ≈ 33.3%

实际还要加上换行开销：MIME 规定 base64 每 76 个字符插入一个 CRLF，也就是每 76 字节多 2 字节，额外约 2.6%。所以一封带 18MB 附件的邮件，编码后大约是18 × 1.333 × 1.026 ≈ 24.6MB，再算上头部和正文，刚好卡在很多服务器 25MB 的上限边缘。这就是为什么大部分邮件系统把“单封邮件总大小”限制在 25MB，而“附件大小”建议不超过 10MB 到 18MB 之间。你如果按“附件 25MB”去设计，用户必然遇到“明明没超限却发不出去”。

我一般会给业务方一个更保守的口径：附件超过 8MB 就走对象存储发链接，别塞邮件里。原因是接收方的限制往往比发送方更严，你这边能发出去，对方网关照样可能因为体积直接拒收，而且大附件对移动端用户极不友好。

2.4 IMAP 的状态模型与 UID 的稳定性

IMAP 和 SMTP 完全是两种风格：SMTP 是无状态的一次性对话，IMAP 是长连接、有状态的会话。连接后先选邮箱（SELECT），然后在这个上下文里操作。

几个必须吃透的概念。序列号（sequence number）是消息在当前邮箱里的位置，从 1 开始，一旦有邮件被删除或 expunge，后面的序号全部前移。UID是消息在邮箱内的唯一标识，配合UIDVALIDITY使用，只要UIDVALIDITY不变，同一个 UID 永远指向同一封信。做增量同步必须用 UID，用序号迟早错乱——我曾经写过一个用序号做游标的同步程序，测试时一切正常，上线后用户一删邮件，整个同步就错位了，把已读状态套到了别的信上。

命令层面，FETCH是核心。FETCH 1 (BODY[])会取回整封信，但同时会把 \Seen 标志置上，等于把用户的未读邮件变成已读；要只读不改状态，必须用BODY.PEEK[]。这个细节不知道的人非常多，做归档或分析系统时如果用了前者，用户会投诉“我的未读全没了”。

实时性靠IDLE命令：客户端发IDLE后服务器保持连接，有新邮件就推一条* 3 EXISTS。这也是为什么移动端能秒收推送，而不用轮询。不过IDLE需要长连接保活，一般 29 分钟要重发一次，否则会被中间设备掐断。

3. 动手：从发一封信到收一封信的完整实操

理论讲完，直接上能跑的东西。下面的代码只用 Python 标准库，不引入第三方依赖，方便你在任何环境里复现。

3.1 环境与凭证准备

准备三样东西：一个可用的发信账号、一个收信账号、以及正确的服务器地址。这里有个坑必须先说：很多公共邮箱服务商在开启了两步验证之后，不能直接用登录密码做 SMTP 认证，需要单独生成一个“客户端专用密码”或“授权码”。第一次做对接的人经常卡在这里，报错是535 认证失败，然后开始怀疑代码，实际上密码那一栏填的东西就不对。

注意：授权码和登录密码是两回事，授权码只在第三方客户端协议里有效，而且通常可以单独吊销。不要把登录密码硬编码进脚本，也不要把授权码提交进代码仓库。

调试阶段建议先用一个本地能收信的测试账号，别拿真实用户邮箱试。发信量控制住，一次性发几十封测试邮件很容易触发对方的风控。

3.2 发信：构造符合规范的报文

import os import ssl import smtplib from email.message import EmailMessage from email.utils import formatdate, make_msgid msg = EmailMessage() msg["From"] = "系统通知 <noreply@example.com>" msg["To"] = "receiver@example.net" msg["Subject"] = "月度报表已生成" msg["Date"] = formatdate(localtime=True) msg["Message-ID"] = make_msgid(domain="example.com") msg.set_content("报表见附件，如有疑问请回复本邮件。") with open("report.pdf", "rb") as f: msg.add_attachment( f.read(), maintype="application", subtype="pdf", filename="report.pdf", ) ctx = ssl.create_default_context() with smtplib.SMTP_SSL("mail.example.com", 465, context=ctx, timeout=20) as s: s.login("noreply@example.com", os.environ["MAIL_PASS"]) s.send_message(msg)

几个参数值得解释。timeout=20一定要设，不设的话默认是全局超时，遇到对方服务器不响应会把你的进程挂死。ssl.create_default_context()会做证书校验，别图省事用_create_unverified_context()，那等于关掉了 TLS 的意义。send_message比sendmail聪明，它会自动从To、Cc、Bcc里提取收件人填进RCPT TO，并且会把Bcc从报文里删掉——这个处理很重要，自己拼报文时忘了删Bcc，等于把密送名单广播给所有人。

如果你用的是 587 端口，改成这样：

with smtplib.SMTP("mail.example.com", 587, timeout=20) as s: s.ehlo() s.starttls(context=ctx) s.ehlo() s.login("noreply@example.com", os.environ["MAIL_PASS"]) s.send_message(msg)

starttls之后必须再ehlo()一次，因为加密前后服务器暴露的能力清单可能不同，很多认证方式只有在 TLS 建立后才出现。漏掉这一步，login会报“服务器不支持认证”。

还有个安全细节：所有进入头部的变量都要过滤换行符。如果用户在昵称里输入\r\nBcc: attacker@example.net，而你没做过滤，这封信就会被悄悄多发一份。这种头注入是真实存在的攻击面。

3.3 收信：用 UID 做增量拉取并解析 MIME

import email import imaplib from email.header import decode_header M = imaplib.IMAP4_SSL("mail.example.com", 993) M.login("user@example.com", os.environ["MAIL_PASS"]) M.select("INBOX") # 只取上次同步点之后的邮件，用 UID 而不是序号 typ, data = M.uid("search", None, "UID", "1000:*") uids = data[0].split() for uid in uids[-20:]: typ, parts = M.uid("fetch", uid, "(BODY.PEEK[])") raw = parts[0][1] msg = email.message_from_bytes(raw) subject_parts = decode_header(msg["Subject"] or "") subject = "".join( p.decode(enc or "utf-8") if isinstance(p, bytes) else p for p, enc in subject_parts ) print(uid.decode(), subject, msg["From"], msg["Date"]) for part in msg.walk(): ctype = part.get_content_type() disp = str(part.get("Content-Disposition") or "") if "attachment" in disp: name_parts = decode_header(part.get_filename() or "unnamed") name = "".join( p.decode(enc or "utf-8") if isinstance(p, bytes) else p for p, enc in name_parts ) with open(name, "wb") as f: f.write(part.get_payload(decode=True))

这段代码里有两个“必须这么写”的地方。第一，用UID SEARCH而不是SEARCH，用UID FETCH而不是FETCH，游标才稳定。第二，用BODY.PEEK[]而不是BODY[]，避免污染用户的已读状态。

decode_header那一坨是处理 RFC 2047 编码的，=?UTF-8?B?...?=这种形式就是它。不处理的话，中文主题会显示成一串乱码。附件名更麻烦一些，如果文件名是非 ASCII，现代客户端会用 RFC 2231 的filename*=utf-8''...形式，get_filename()一般能正确处理，但遇到老系统发来的非标准写法，还是得自己兜底。

3.4 裸连诊断：出问题时先别改代码

遇到认证失败、连接超时、TLS 握手错误，最快的定位方式是用命令行做“裸连”，把代码排除在外。

# 看 993 端口的证书和 banner openssl s_client -connect mail.example.com:993 -crlf -quiet # 对 SMTP 做 STARTTLS 后再手打命令 openssl s_client -connect mail.example.com:587 -starttls smtp -crlf # 查域名的 SPF / DKIM / DMARC 记录 dig +short TXT example.com dig +short TXT selector1._domainkey.example.com dig +short TXT _dmarc.example.com # 查反向解析 dig +short -x 203.0.113.10

openssl s_client连上之后你能直接看到对方服务器吐出来的220banner，有些网关会在 banner 里写明“你的 IP 不在白名单”，一眼就能定位。证书过期也会在这里暴露，报错是certificate has expired，改代码是没用的。

dig那条尤其重要。SPF 配置错误最常见的情况是：记录存在，但嵌套的include太多，超过了 10 次 DNS 查询上限，校验方直接返回permerror，表现就是“SPF 配置明明有，但就是不通过”。查的时候要把 include 一层层展开算次数，这一步没法偷懒。

3.5 认证方式的演进与选择

SMTP 认证方式从弱到强大致是：LOGIN/PLAIN（明文，必须跑在 TLS 里）、CRAM-MD5（挑战应答，密码不在链路上传）、XOAUTH2（令牌认证）。现在新建系统我基本都推荐XOAUTH2这条路，因为它是基于短期访问令牌的，可以细粒度授权、可以随时吊销，也不用在服务器上存长期密码。代价是令牌获取流程要走一遍 OAuth 授权码模式，比填个密码复杂，需要额外处理令牌刷新。

如果你的场景是内部系统互发通知，用一个专用账号加授权码就够了，不必上 OAuth。技术选型要看实际风险，内部系统为了“更安全”去接一套令牌刷新机制，最后往往因为刷新失败导致通知中断，反而更不稳。

4. 送达率：协议层解决不了的那八成问题

代码跑通只代表“信发出去了”，不代表“信被收下了”。真正让人头疼的是信发出去了、对方服务器也返回250，但用户就是收不到——因为它进了垃圾箱。这部分属于协议之上的信任体系。

4.1 SPF、DKIM、DMARC 各管一段，别互相替代

三者的分工，我用一句话概括：SPF 管“谁有权用这个域发信”，DKIM 管“这封信中途有没有被改”，DMARC 管“前两者和用户看到的发件人对不对得上，以及不对得上时怎么办”。

SPF 的原理是在域名下发布一条 TXT 记录，列出允许发信的 IP 或网段，接收方拿MAIL FROM的域去查，再比对连接来源 IP。注意它校验的是信封发件域，不是From头，这是最常见的误解。而且 SPF 有一个硬伤：邮件转发之后，转发服务器的 IP 不在原始域的 SPF 里，必然失败。这就是为什么单靠 SPF 不够。

DKIM 用非对称签名解决这个问题。发信方对指定的头部字段和正文计算哈希，用私钥签名，把签名放在DKIM-Signature头里；接收方从 DNS 的selector._domainkey.域名取公钥验签。因为签名跟着报文走，转发也不会失效（只要转发方不改内容），这一点比 SPF 强得多。

DMARC 建立在前两者之上，要求From头的域与 SPF 通过的域或 DKIM 签名的域对齐。对齐分宽松（relaxed，只比组织域）和严格（strict，子域也必须完全一致）两种。对齐失败时，按策略处置：none只观察、quarantine进垃圾箱、reject直接拒收。

4.2 记录怎么写，参数怎么算

SPF 记录长这样：

example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.example.net -all"

这里有两处必须讲清楚。-all是硬失败，表示“不在列表里的一律不是我发的”；~all是软失败，只标记不拒绝。刚上线时建议先用~all观察一段时间，等确认所有发信源都覆盖了再切-all，直接上-all很容易把还没登记的业务线打死。

include的代价是 DNS 查询次数。SPF 规定单次校验最多 10 次 DNS 查询（包括include、a、mx、ptr、exists机制），超过就返回permerror，等同于没有 SPF。另一个限制是“空查询（void lookup）”不超过 2 次。实际算起来很反直觉：一个include本身算 1 次，被 include 的那个域里的机制还要再算，mx机制会为每个 MX 记录再查一次。所以嵌套三层include很容易就爆了。我的经验是控制在两层以内，总数留出 3 次余量。

DKIM 的 DNS 记录：

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg...(公钥)"

密钥长度现在建议 2048 位，1024 位已经不被推荐。但要注意一个细节：2048 位公钥 base64 之后大约 400 多字节，加上记录本身的字段，单条 TXT 记录会超过 255 字节，DNS 会把它拆成多段字符串。绝大多数解析库能自动拼接，但如果你自己写解析，必须处理这种情况。另外公钥太长时，UDP 响应会超限触发 TCP 回退，极少数老旧设备会因此拿不到记录，表现为“DKIM 偶尔验不过”。

DMARC 记录：

_dmarc.example.com. TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

上线节奏我踩过坑，建议按这个顺序走：先p=none加报告地址，跑两周把rua报告里的发信源梳理清楚，把漏掉的 IP 补进 SPF、把漏签的通道补上 DKIM；然后p=quarantine; pct=10小比例放量，观察退信率变化；确认无异常再逐步提到 100，最后切p=reject。跳过观察期直接reject，后果是自家业务邮件被自己拒收，而且因为拒收发生在对方服务器，你的日志里什么都看不到。

4.3 那些不在协议文档里但影响巨大的细节

第一是反向解析（PTR）。发信 IP 必须有 PTR 记录，而且 PTR 指向的域名最好和EHLO里声明的域名一致。很多接收方会做这种“正反一致性”检查，不一致就扣分。云主机默认的 PTR 通常是一串内部标识，一定要提工单改成你的发信域。

第二是HELO 域名。EHLO里别随便填个localhost，填你的真实域名，这是最基本的态度问题。

第三是发信 IP 的信誉是共享的。如果你用的是共享 IP 的发信服务，别人的投诉会算到你头上。这也是为什么认真做业务的公司最终都会走到独立 IP 加热这条路——但独立 IP 有“热身期”，新 IP 突然发大量邮件必然被拦，要按每天递增的节奏跑一两周。

第四是投诉率和退信率。硬退信（地址不存在）要立刻从列表里剔除，反复投递无效地址是典型的垃圾邮件特征。用户在客户端点“标记为垃圾邮件”会直接拉低你的信誉，所以退订入口要显眼、要一键、要能用。

第五是内容层面的诱因。整封信只有一张大图、正文里短链接特别多、Subject全大写带感叹号、HTML 里藏着与可见内容不符的链接，这些都会提分。我见过最冤的一次是模板里用了某个短链服务的域名，那个域名被大量滥用，导致整批邮件被降权，换成自有域名后立刻恢复。

5. 常见问题与排查实录

排障这件事，方法论比经验重要。我一般按“返回码 → 日志 → 原始报文 → DNS”这个顺序走，绝大多数问题在前两步就能定位。

5.1 四步定位法

第一步看返回码。5xx是永久错误，不需要重试，直接看原因；4xx是临时错误，检查重试策略和退避时间是否合理。550、551、553多为地址或策略问题，535是认证问题，552是超限，421是连接被断。

第二步看日志的哪一段。发送端日志只能告诉你“我发出去了”或者“对方拒了”，收不到信的时候发送端日志往往是干净的。真正有用的是接收端的日志，如果你没有接收端权限，那就只能靠原始报文里的Received链推断。

第三步抓原始报文。让收件人把邮件“显示原文”导出，重点看Received、Return-Path、Authentication-Results。Authentication-Results这一行会直接告诉你 spf、dkim、dmarc 各自是 pass 还是 fail，省掉大量猜测。

第四步查 DNS。确认记录真的存在、真的没超限制、真的没写错域。这一步用dig就行，别用网上那些在线工具，缓存和解析路径不一样，结果可能不一致。

5.2 常见问题速查表

5.3 我踩过的几个坑，写下来省得你再踩

第一个坑是灰名单。有些接收方对陌生发信方会先返回450让你过几分钟再来，这是防垃圾的正常机制。如果你的重试策略是“失败就放弃”，那这封信永远发不出去；如果重试间隔是 10 秒，你会被连续拒绝然后被拉黑。正确的做法是第一次等 1 分钟，之后 5 分钟、15 分钟、1 小时指数退避，总重试时长控制在 24 到 48 小时。

第二个坑是一封邮件塞多个收件人。用 SMTP 发通知时，如果为了省事把 100 个地址全塞进RCPT TO，一是所有人都能在To里看到彼此，二是只要有一个地址无效，某些服务器会整封拒收，剩下 99 个也收不到。正确做法是一人一封，或者用Bcc但报文里要删掉Bcc头。批量发信时还要控制速率，一秒钟几百封的脉冲式发送非常像攻击。

第三个坑是IMAP 的\Seen标志。前面提过一次，但我还是要重复：做邮件归档、做内容分析、做客服工单接入，只要你的程序读了邮件，就一定要用BODY.PEEK[]。否则上线第一天，全公司的未读邮件都会被“读”掉，然后你会收到一堆投诉。

第四个坑是时间字段。Date头缺失、时区写错、格式不符合 RFC 5322，都会影响垃圾邮件评分。用formatdate(localtime=True)生成，别自己拼字符串。还有一个隐蔽的问题是服务器时间不准，导致Received链里出现“后面的跳比前面的跳时间还早”，某些反垃圾系统会直接判定异常。

第五个坑是测试环境用真实域名。测试时图省事，把From写成生产域名，结果测试邮件被当成正式发信计入信誉，投诉率一下上去了。测试一律用独立的子域，SPF 和 DKIM 单独配，和生产隔离。

第六个坑是以为250就万事大吉。250只代表对方服务器接收了，后面的过滤、投递、进垃圾箱它一概不负责。真正可靠的做法是接入投递事件回执，把“送达、延迟、退信、投诉”这几类事件收回来，形成闭环。没有回执的群发系统，等于闭着眼睛开车。

5.4 一点个人体会

我现在做任何邮件相关的对接，第一步都不是写代码，而是先把四条 DNS 记录和端口连通性确认一遍，再写一个最小可用的发信脚本，用openssl s_client抓一次完整会话存成参考，最后才去写业务逻辑。这个顺序反过来，出问题时你会在业务代码和协议细节之间反复横跳，效率极低。

另外，原始报文要养成随手保存的习惯。一封被判垃圾的邮件，原始报文里通常已经写明了原因——Authentication-Results说 DKIM fail，Received链显示中途被重写，Content-Type显示字符集声明错了。这些东西不看报文永远猜不到。我电脑里现在还有一个目录专门存各种“疑难邮件原文”，遇到新问题先翻旧档，命中率相当高。

最后说个容易被忽视的扩展方向：如果哪天你需要做邮件数据分析，比如统计某段时间的往来频次、提取附件做归档、自动归类工单邮件，那 IMAP 的UID增量机制和SEARCH的查询语法就是核心武器，SINCE、BEFORE、FROM、SUBJECT、UNSEEN这些条件可以组合出相当精确的筛选，配合本地存一份 UID 游标，跑起来比全量拉取快一个数量级。这块我自己用了两年多，稳定性没什么问题，唯一要留意的就是UIDVALIDITY变化时要触发一次全量重建，否则会漏信。