国产邮件系统
安全可靠自主可控的电子邮件系统国产化解决方案。
发信人视角的常见退信诊断与修复。每条对应一个具体错误码或症状，看完即可操作。共 86 问，按类别分组。
• 2xx = 命令成功执行（250 OK、221 Bye）
• 3xx = 命令部分成功，还需要更多输入（354 Start mail input）
• 4xx = ⚠️ 临时失败。发件 MTA 会自动排队重试（通常每 15-30 分钟重试一次，最长重试 2-5 天）——你不需要手动管。
• 5xx = 🚫 永久失败。别重发了，先修问题再重新发送。常见：550=拒收/不认可、551=用户不存在、552=容量满、554=事务失败
格式为 class.subject.detail：
• 第一数字（递送结果）：2=成功、4=延迟/临时、5=失败
• 第二数字（问题范围）：1=地址问题、2=邮箱问题、3=邮件系统问题、4=网络问题、5=协议问题、6=内容问题、7=安全/策略问题
• 第三数字：该范围内的具体子问题
例：5.7.1 = 永久失败·安全策略·通用拒收；4.4.5 = 临时失败·网络问题·服务器繁忙
1. 退信中找 Remote-MTA 或 reporting-MTA 行——这是最后拒绝/退信你的服务器，判断是你自己的发件服务器报错还是到了对方 MX 后才被拒。
2. 搜索时用英文原文+错误码命中率高得多，如 "550 5.7.26" gmail fix。
3. DSN 码在 Microsoft Exchange 退信中常以 #550 5.7.1 # 或 Status: 5.7.1 格式出现。
参考：RFC 5321 §4.2（SMTP 响应码体系）· RFC 3464（DSN 投递状态通知格式）· RFC 1893（增强状态码）
SMTP 默认不加密——邮件传输途中可以被中间人（MITM）窃听。STARTTLS 提供了加密选项但属于"机会性加密"（Opportunistic Encryption）：发信服务器发出 STARTTLS 命令、收件方响应并开始 TLS 握手——但如果攻击者删除了 STARTTLS 命令（降级攻击），发信方就会用明文发送邮件。MTA-STS（RFC 8461）解决了这个问题：收件方域名公开发布强制加密策略——声明"发给我域的邮件必须走 TLS 加密、必须验证证书"。发信方检查收件方 MTA-STS 策略后：如果有 MTA-STS→强制 TLS；如果没有→回退到机会性加密。
Step 1：DNS TXT 记录
在你的 DNS 新增一条 TXT 记录：
名称：_mta-sts.yourdomain.com
值：v=STSv1; id=20260706203000
其中 id 是数字串（推荐时间戳 YYYYMMDDHHMMSS）——每次更新策略时必须递增 否则发信方不会重新获取。
Step 2：HTTPS 策略文件
在你的 mta-sts.yourdomain.com 的 Web 服务器上创建路径：/.well-known/mta-sts.txt
内容：version: STSv1mode: testing ← 先 testing 测试几天mx: mx1.yourdomain.commx: mx2.yourdomain.commax_age: 86400 ← 策略缓存秒数（1天）
HTTPS 必须有有效证书（建议 Let's Encrypt）。
确认 testing 阶段无投递故障后改为：mode: enforce ← 强制加密 未加密则拒收
同时增大 max_age：max_age: 604800（7天）。
再新增一条 DNS TXT：
名称：_smtp._tls.yourdomain.com
值：v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com
支持 MTA-STS 的发信方会每天向这个地址发送 JSON 格式的 TLS 投递报告——哪些邮件 TLS 成功、哪些失败了、失败原因是什么。类似 DMARC RUA 报告但针对 TLS 层面。
• MTA-STS 只强制入向（别人发给你的邮件走加密）——不影响你出向的邮件。
• MTA-STS 不是 SPF/DKIM/DMARC 的替代——这四者是互补的独立维度。
• 测试工具：dig txt _mta-sts.yourdomain.com 验证 DNS；curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt 验证策略文件。
• Postfix 可以用 postfix-mta-sts-resolver（GitHub 开源 daemon）自动查询外域 MTA-STS 策略。
参考：RFC 8461（MTA-STS）· RFC 8460（TLS-RPT）· EasyDMARC MTA-STS Checker · GitHub postfix-mta-sts-resolver
Gmail 自 2024 年起要求所有发信域必须通过 SPF 或 DKIM 认证。你的域名缺少或配置了无效的 SPF/DKIM 记录。
1. 检查域名的 SPF 记录：nslookup -type=txt yourdomain.com，应有一条以 v=spf1 开头的 TXT 记录。
2. 检查 DKIM 记录：确认发信 MTA 生成的 DKIM 选择器对应的 TXT 记录已在 DNS 发布。
3. 如缺失，联系邮件服务商获取正确的 SPF 和 DKIM 配置值并添加到 DNS。
参考：RFC 7208 (SPF) · RFC 6376 (DKIM) · Google Email Sender Guidelines
Gmail 要求发信 IP 必须配置 PTR 反向解析记录（RFC 1912 §2.1）。你的发信服务器 IP 未配置 PTR，或 PTR 指向的域名无法正向解析回该 IP。
1. 联系 IP 提供商（云服务商/ISP）为发信 IP 设置 PTR 记录，PTR 值应为邮件服务器的主机名。
2. 确认 PTR 指向的域名可正向解析回该 IP（正反向解析闭环）。
3. 验证：nslookup <发信IP> 应返回你设置的域名。
参考：RFC 1912 §2.1 (PTR) · Google Email Sender Guidelines
Outlook.com/Hotmail 自 2024 年起大幅收紧发件人信誉管控，即使 IP 不在任何公开黑名单（Spamhaus 等）上，仍可因内部信誉评分低而拒收。常见微软内部错误码：SC-001（内容可疑）、BA-004（IP 信誉差）、BA-005（连接行为异常）。微软内部信誉系统独立于公开 DNSBL，被拒不等于被列入公开黑名单。
1. 注册 Microsoft SNDS（Smart Network Data Services）查看 IP 在微软系统的实际信誉数据。
2. 注册 JMRP（垃圾邮件报告程序）获取退订反馈循环。
3. SPF、DKIM、DMARC（p=至少 none）三项全部配置并通过验证。
4. 邮件内容避免：.tk/.top 等高风险顶级域名链接、短链接（bit.ly 等）、品牌名称伪装在发件人显示名中、纯图片无文字邮件。
5. IP 预热：新 IP 每日发送量增长 ≤25%。
6. 在 Microsoft 发件人支持填表申诉（需提供退信原文+发信日志+域名认证截图）。
7. 耐心——微软处理周期通常 5-10 个工作日。
参考：Microsoft SNDS · JMRP · NDR 5.7.1 · RFC 7489 (DMARC)
Relay denied 意味着你的 SMTP 服务器拒绝代你发信给外部域。SMTP relay（中继）= 用一台服务器发信给非本域收件人。SMTP 协议设计为：如果你不是这台服务器的用户，它没义务帮你发信——否则就成了"开放中继"（会被全世界的垃圾邮件发送者利用）。触发三种情况：(1) 客户端没做 SMTP 认证（AUTH LOGIN）就直接发信；(2) 你的 IP 不在服务器中继白名单内；(3) 发件人域名与 SMTP 服务器的管辖域不匹配。注意："Unable to relay" 和"Message rejected as spam"不同——前者是配置问题，肯定能修好。
1. 邮件客户端（Outlook/Thunderbird）：账户设置 → 更多设置 →"发送服务器"选项卡 → 勾选"我的发送服务器 (SMTP) 要求验证"→ 选择"使用与接收邮件服务器相同的设置"。
2. 代码发信（PHPMailer/nodemailer/Python）：使用 SMTP AUTH 方式而不直接 pickup。Python 例：smtp.login(user, password)
3. 自建 Postfix：编辑 /etc/postfix/main.cf → mynetworks = 127.0.0.0/8, [::1]/128, 192.168.1.0/24（加入客户端 IP 段）；smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination。
4. 用第三方 SMTP（如网易/Gmail）：SMTP 用户名必须有权限，且 From: 地址通常必须与 SMTP 账号一致。
5. 手工测试：telnet smtp.xxx.com 587 → EHLO test → AUTH LOGIN 确认认证步骤通过。
参考：RFC 4954 (SMTP AUTH) · Postfix relay 配置文档
Microsoft 的 5.7.708 是"网络保护"模块决策代码——IP 信誉过低被 Microsoft 内部系统拒绝。不同于 5.7.1（内容/公开黑名单），5.7.708 使用 Microsoft 自有威胁情报数据库。常见触发：(1) 新购 VPS IP，前租户做过群发/钓鱼 → 该 IP 在 Microsoft 系统有"前科"；(2) Azure/Microsoft 365 试用订阅的发信 IP；(3) IP 近期在 Outlook 系统垃圾率 >0.1%。公开 DNSBL（Spamhaus 等）查不到不代表 IP 干净。
1. 注册 Microsoft SNDS 用 IP 查询微软内部信誉——"All Normal"干净、"Blocked"或"Stale"有问题。
2. 在 Microsoft 发件人支持 填表申诉，附退信原文 + SPF/DKIM/DMARC 配置截图 + 发信日志。
3. SPF、DKIM、DMARC 三项认证缺一不可（DMARC 至少 p=none）。
4. IP 预热：日发量 50→125→310→775→1950 逐步递增，日增量 ≤25%。
5. Microsoft 处理周期通常 5-10 个工作日。长期不恢复 → 换 IP 或改用 SendGrid/Mailgun/SES 等专业发信平台。
参考：Microsoft NDR 5.7.708 · SNDS · RFC 7489 (DMARC)
Gmail 基于安全防护策略，永久拒绝特定文件类型作为邮件附件——无论是否打包成 .zip 都不可发送。Gmail 通过检测文件头（magic bytes）识别真实文件类型，不是靠扩展名判断。以下扩展名的文件一律禁止：
.ade .adp .bat .chm .cmd .com .cpl .exe .hta .ins .isp .jse .lib .lnk .mde .msc .msp .mst .pif .scr .sct .shb .sys .vb .vbe .vbs .vxd .wsc .wsf .wsh另外受密码保护的压缩包（encrypted .zip/.rar）也可能触发此拦截。
1. 不要试图改扩展名蒙混——Gmail 检测文件头而非文件名。
2. 将可执行文件上传到 Google Drive / Dropbox / OneDrive，邮件正文中放共享链接代替附件。
3. 如果文件确实安全且必须作为附件发送：(a) 去除密码保护、(b) 压缩为 .zip 不含上述扩展名的文件、(c) 考虑用自建 MTA 直投（但对方 Webmail 仍可能拦截）。
4. 对加密码的 .zip：要么解密发送、要么改用其他传输方式。
参考：Gmail Help（File types blocked in Gmail）· RFC 2045 §6.8（MIME Base64）
SMTP 认证被服务器拒绝。常见原因：(1) 邮箱开启了两步验证，需要用应用专用密码；(2) SMTP 地址/端口/加密方式配置错误；(3) 邮箱服务商要求使用授权码而非登录密码。
1. Gmail 用户：在 Google 账户 → 安全性中生成应用专用密码，替换客户端中的登录密码。
2. Outlook.com/Microsoft 365：SMTP 为 smtp.office365.com，端口 587，加密 STARTTLS。
3. QQ/163 邮箱用户：在邮箱设置中开启 SMTP 服务并获取授权码，用授权码替代登录密码。
4. 确保邮件客户端勾选了"发送服务器需要身份验证"。
参考：RFC 4954 (SMTP AUTH) · Google App Passwords · Outlook.com SMTP Settings
SMTP 服务器拒绝中继，因为邮件客户端未启用发送身份验证。
1. Outlook：文件 → 账户设置 → 双击邮箱账户 → 更多设置 → 发送服务器 → 勾选"我的发送服务器要求验证"，选择"使用与接收邮件服务器相同的设置"。
2. Foxmail：账户设置 → 服务器 → 勾选"SMTP 服务器需要身份验证"。
3. 确认 SMTP 服务器地址为邮箱服务商提供的外发服务器，而非本机。
参考：RFC 4954 (SMTP AUTH) · RFC 5321 §4.1.1.2
SMTP 连接失败。常见：端口错误、加密方式不匹配、本地防火墙/杀毒软件拦截、ISP 封禁 25 端口。
依次检查：
1. SMTP 服务器地址是否正确（以邮箱服务商官方文档为准）。
2. 端口：常见为 587（STARTTLS）或 465（SSL/TLS），不使用 25。
3. 加密方式：端口 587 选 STARTTLS，端口 465 选 SSL/TLS。
4. 暂时关闭防火墙和杀毒软件测试连接。
5. 住宅宽带：部分 ISP 封禁 25 端口（反垃圾邮件），改用 587 即可。
参考：RFC 8314 (IMAP/POP/SMTP TLS) · RFC 5321 §3.1
发件箱卡住最常见四种原因：大附件阻塞队列、Outlook 处于脱机工作模式、SMTP 认证过期、某封邮件本身损坏导致的连锁阻塞。
按顺序排查：
1. 大附件：带大附件的邮件放在发件箱最前面会阻塞后面所有邮件。删掉或缩小附件后重试。
2. 脱机工作：点击"发送/接收"选项卡，确认"脱机工作"按钮未高亮。如已按下，点击取消。
3. 认证过期：文件 → 账户设置 → 双击账户 → 重新输入密码（或应用专用密码）。
4. 找"害群之马"：将发件箱中所有邮件拖到草稿箱，关闭 Outlook，重新打开后逐封从草稿箱发送，找到引起阻塞的那封。
参考：Microsoft Outlook Support · Office 365 Diagnostic Tool
SMTP 信封发件人（MAIL FROM）或 From 头地址与 SMTP 登录认证的用户名不一致。部分邮件服务商（如 Spectrum/Road Runner、Comcast）强制要求二者必须匹配，否则拒绝发送。
1. 确认邮件客户端的"电子邮件地址"字段与你用于 SMTP 认证的用户名完全一致。
2. Outlook：文件 → 账户设置 → 双击账户 → 确认"电子邮件地址"和"用户名"是同一个邮箱地址。
3. 如果邮箱有多个别名/代发地址，SMTP 登录必须用主账号用户名，发件人地址也只能用该主账号地址。
4. 如确实需要用不同地址发信，向邮箱服务商申请代发权限。
参考：RFC 4954 (SMTP AUTH) §5 · RFC 5321 §3.3
这属于行为反垃圾：收件方不看你发了什么，而是看你怎么发的——频率、连接模式、收件人分布等行为特征。收件方服务器通过行为分析判断你是否像垃圾邮件发送者（spammer pattern）。454 = 临时拒绝（你的 MTA 队列会自动重试，过几分钟可能就过了）；554 = 永久失败（当前邮件放弃，重新发送也不行）。常见触发模式：(1) 同一 IP 短时间内并发连接过多；(2) 同一域名/账号短时间内发件量突然暴增；(3) 收件人都是不认识的地址且均匀分布——像群发工具；(4) 发件节奏过于规律（如正好每秒一封）。
1. 降低速率：每封间隔 ≥1-2 秒，并发 SMTP 连接 ≤3。
2. 分批发送：同一批邮件中收件人域名多样化，不要把所有 同一邮件系统的收件人集中一批发送。
3. 保持发件人地址一致：不要每个批次的 MAIL FROM 都变——稳定的发件人信誉更好。
4. 控制总量在服务商限制内：(a) 阿里邮箱免费版 ≤2000封/天/企业，付费版 ≤2500封/天/账号；(b) Gmail 个人账号 ≤500封/天；(c) Outlook 个人 ≤300封/天。
5. 454 被拒后在队列中自动重试，不要手动反复重发同一封——会加长封禁时间。
6. 新 IP/新域名：从极低量开始（日发 50→125→300→1000 逐步递增），至少预热 7 天。
参考：阿里云退信帮助·RFC 5321 §4.2（SMTP 响应码）
邮件自动转发（Forwarding）本质上用转发方服务器的 IP 重新发送邮件——转发方不是你（原始发件人），所以：
(1) SPF 失败：转发服务器的 IP 不在你域名的 SPF 允许列表里——别想了，不可能把所有转发服务的 IP 都加进去。
(2) DMARC 生效：如果你域名的 DMARC 策略是 p=reject，收件方看到 SPF fail → 直接拒绝——邮件不会进垃圾箱、不会收到退信、直接消失了（静默丢弃）。
(3) 个别场景 DMARC p=quarantine 或 p=none：邮件可能进垃圾箱（看收件方策略）。
典型场景：老王用 Gmail → 设置自动转发到企业邮箱 → 同事发邮件到老王 Gmail → Gmail 转发到企业邮箱时 SPF 失败 → 企业邮箱拒收/垃圾箱。
根本解决方案是 SRS（Sender Rewriting Scheme）——转发方重写 MAIL FROM 地址，把你的地址封装后用自己的域重新发送。
1. 自建转发：Postfix 安装 postsrsd（pip/apt install postsrsd→配置 /etc/postsrsd.conf）
2. Gmail → Gmail 转发：同 Gmail 内部转发不受影响
3. Gmail → 第三方：部分邮件可能丢失，建议改用 Gmail 收件方直接 POP3/IMAP 拉取而非自动转发
4. 商业转发服务：ForwardEmail.net、Cloudflare Email Routing 等有内置 SRS
5. 不可控转发方时的替代方案：请收件方把你转发后的来源地址加入白名单（绕过 SPF 检查）
注意：Gmail 即使开启了转发，转发的邮件不带原始 DKIM 签名，DMARC 也会受影响。
参考：RFC 8617（ARC 转发认证协议）· SRS 设计文档 · Gmail Help
收件方告知该邮箱地址不存在（RFC 5321 §4.2.2）。可能是拼写错误、地址已停用或对方已离职。
1. 核对地址：注意 gmail.com vs gmial.com 等常见笔误。
2. 如地址无误，通过电话/微信等渠道确认该邮箱是否仍在使用。
3. 企业邮箱：对方可能已离职，联系对方公司获取有效邮箱。
参考：RFC 5321 §4.2.2 (SMTP Reply Codes)
附件经 Base64 编码后膨胀约 33%：20MB 文件编码后约 27MB。常见限制：Gmail 25MB、Outlook.com 25MB、国内企业邮箱通常 20-50MB。
1. 压缩附件（WinRAR / 7-Zip）。
2. 拆分为多封邮件分开发送。
3. 使用云盘上传后分享链接代替附件。
4. 如文件不大但仍超限，检查是否含未压缩的高分辨率图片。
参考：RFC 5321 §4.2.2 (552) · Gmail Send Limits
收件人邮箱存储配额已用满，无法接收新邮件（RFC 5321，5.2.2）。
1. 通过电话/微信等非邮件渠道告知收件人清理邮箱。
2. 等待对方清理后重新发送。
3. 如长时间不清理，询问是否有备用邮箱。
参考：RFC 5321 §4.2.2 (552 - mailbox full)
收件方收到你的邮件后，会回查 MAIL FROM（Return-Path）中的发件域名的 DNS 记录——查不到或解析失败就拒收。这是一种基础防伪造措施：如果发件域名连 DNS 都查不到，说明大量邮件可能来自伪造域名。请注意：查的是 MAIL FROM 中的域名（信封发件人），不是 From: 头中的显示域名。
1. 命令行验证：(a) nslookup yourdomain.com → 必须有 A 记录；(b) nslookup -q=mx yourdomain.com → 必须返回 MX 记录。
2. 使用 MXToolbox DNS Check 多点验证全球解析。
3. 新注册域名：DNS 全球传播 24-48 小时，等传播完再批量发信。
4. 检查 DNS 托管商：DNSPod/Cloudflare/AWS Route53 区域线路是否全部生效。
5. 确认域名没有过期：whois yourdomain.com。
6. 如果你用第三方发信服务（如 SendGrid）的 MAIL FROM 域名是自己的域名：确保该域名已在发信平台验证（一般需加 CNAME/TXT 记录）。
参考：RFC 5321 §2.3.5（域名解析验证）· RFC 1035（DNS 规范）
这是 Qmail/Postfix 收件方服务器的 rcpthosts / chkuser 限制——收件方服务器只接受在「允许接收域名列表」中的收件地址。这个错误比较少见，通常只出现在一些特定服务商的服务器上（如 TOM 邮箱、部分自建 Qmail 服务器）。常见原因：(1) 你和收件方曾经使用同一家邮件服务商，你已迁走但你的域名仍残留在该服务商的系统中——对方的服务器误认为你"应该在本地列表"→ 不在就拒绝；(2) 你发送的目标是一个邮件群组/邮件列表地址，但你没有获授权发送给该列表；(3) 收件方服务器配置了"只接受已知域名发件"的白名单机制。
1. 确认场景：你和收件方是否曾经使用同一家邮箱服务商（如网易企业邮、TOM 企业邮、腾讯企业邮等）？如果是：联系该服务商管理员（或收件方的 IT），要求从后台彻底删除你的域名残留信息。
2. 邮件群组权限：请收件人确认目标地址是个人邮箱还是群组地址——如果是群组，联系群组管理员把你的发件地址加入允许列表。
3. 替代方案：改用收件人的另一个邮箱地址（非群组地址）、或用其他渠道联系对方 IT。
这句话的核心：不在你这边能修——得请对方 IT 动手。发件人自己能做的就是确认你的域名 DNS 没问题、用别的收件地址试试。
参考：qmail-1.03 rcpthosts 文档 · RFC 5321 §4.1.1.3
单封邮件中的收件人（To/CC/BCC）总数超过了接收方服务器的限制。
1. 将收件人分成多批，每批不超过 50-100 人，分多次发送。
2. 各平台参考：Gmail 个人免费版每封最多 500 收件人，多数企业邮箱限制 50-100。
3. 如确实需要大规模群发，用专门邮件群发平台或邮件列表服务。
参考：RFC 5321 §4.5.3.1 · Google Workspace Sending Limits
你今天发出的邮件总数超过了邮箱服务商的单日发信限额。Gmail 个人免费版每日 500 封、Outlook.com 每日 300 封、企业邮箱由管理员设定。
1. 等待次日凌晨配额自动重置后继续发送。
2. 将剩余邮件保存为草稿，次日发送。
3. 企业邮箱用户：联系邮件管理员申请提高单日限额。
4. 如需高频群发，使用专业邮件群发服务而非个人邮箱。
参考：Gmail Sending Limits · Outlook.com Sending Limits
收件方邮件服务器暂时不可用或启用了灰名单（greylisting, RFC 6647）。收件方对首次见到的发信三元组返回临时拒收，要求发件服务器稍后重试。
1. 不需要任何操作。发件服务器会自动在几分钟到十几分钟后重新投递，通常第二次即可通过。
2. 如超过 1 小时仍未送达且无新退信，可能是邮件卡在发件队列中，联系邮件服务商管理员查看队列。
参考：RFC 5321 §4.2.2 (421) · RFC 6647 (Email Greylisting)
常见免费邮箱对每个发信 IP 有三级频率控制：每分钟、每小时、每日限制（具体数值不公开）。同一 IP 短时间内发送到 QQ 的邮件超过阈值，触发 IP 级临时封禁。
1. 立即暂停发信，等待数分钟到数小时后以较低频率重新发送。
2. 将群发邮件分批发送，每批间隔 1-2 分钟。
3. 企业邮箱用户（多人共用同一发信 IP）：联系管理员排查是否有其他同事同时大量发信导致 IP 配额被占。
4. 大规模发信需求：使用邮件群发平台。
参考：腾讯企业邮箱帮助中心 · 邮件系统帮助中心
QQ 邮箱判定邮件内容涉嫌群发垃圾——通常因为：(1) 主题或正文含批量群发特征词；(2) 相同内容短时间内发送给大量收件人；(3) 此前有收件人将类似内容举报为垃圾邮件。
1. 修改邮件主题，去掉"免费""优惠""限时"等营销敏感词。
2. 正文增加个性化内容，避免千篇一律的套话。
3. 单次发送收件人数不超过 100 人。
4. 内容正常：请收件人将你的发件地址加入 QQ 邮箱白名单（设置 → 反垃圾 → 白名单）后重新发送。
参考：邮件系统帮助文档 · RFC 5321 §4.2.2
552=永久失败·邮件系统·大小超标。你发送的邮件（正文+附件合并后）超过了收件方允许的最大尺寸。核心概念：MIME 附件在传输前经过 Base64 编码——编码后体积膨胀约 37%（原文每 3 字节编码为 4 字节）。一个号称"25MB 限制"的邮箱实际只能接收约 18MB 的原始文件。
• Gmail：25MB（含附件和正文，收+发相同限制）
• Outlook.com / Hotmail：25MB（收+发）
• 常见免费邮箱：普通附件 50MB / 超大附件 2GB（但需中转站方式）
• 网易 163 免费邮：50MB
• 网易企业邮箱：100MB（可调）
• 自建 Postfix：默认 10MB（message_size_limit = 10240000）
• 自建 Exchange Online：35MB（不可调）
注：限制通常指编码后体积（SMTP DATA阶段的大小）。
1. 压缩附件减小体积（.zip/.7z 压缩率可达 50-80%）。
2. 用云盘/超大附件链接代替真实附件（Google Drive/Dropbox/腾讯微云等）。
3. 拆分大附件分成多封邮件发送。
4. 自建 Postfix 调大限制：postconf -e "message_size_limit = 52428800"（设 50MB），然后 postfix reload。
5. 提醒：你调大了自己服务器限制，但收件方服务器的限制你改不了——超大邮件到对方照样被拒。
参考：RFC 2045 §6.8（Base64 编码）· Gmail Help · Postfix 文档
收件方反垃圾系统拒绝接收。常见触发：主题含促销敏感词、正文全图片/文字极少、发件 IP 信誉低或被列入公共黑名单。
1. 修改主题去掉夸张营销词汇。
2. 正文确保有足够文字（建议 ≥100 字），不要只发一张图片。
3. 正常内容仍被拦：请收件人将你的发件地址加入白名单后重试。
4. 多人报告同类问题：在 MXToolbox 查询发件 IP 是否在黑名单中。
参考：RFC 5321 §4.2.2 (554) · NIST SP 800-177 Rev.1 · Google Spam Policies
收件方管理员设置了自定义安全策略，明确拒绝你的发件地址或域名。这和你 SPF/DKIM 配置无关——验证通过不代表对方一定接收。
1. 通过其他渠道联系收件人，请其通知邮箱管理员将你的发件地址或域名移出拒绝列表。
2. 对方用 Google Workspace：管理员 → 应用 → Gmail → 高级设置 → 被拒绝的发件人列表中添加白名单。
3. 对方用 Microsoft 365：管理员在 Exchange 管理中心 → 邮件流 → 规则中查找针对你发件域的拦截规则。
参考：RFC 5321 §4.2.2 (550 5.7.0) · Google Workspace Admin Blocked Senders
Gmail 禁止接收可执行文件类型（.exe、.bat、.scr、.vbs、.msi 等）和部分脚本文件。即使打包在 .zip 中也会被扫描拦截。
1. 将文件打包为 .rar 或 .7z 格式（Gmail 不扫描这两种压缩包内部）。
2. 用 WinRAR / 7-Zip 对压缩包设置密码保护后发送。
3. 最稳妥：上传至云盘后分享链接代替附件。
参考：Google Gmail Blocked File Types Policy · RFC 2045 (MIME)
发件人用 Outlook 以"RTF 格式"发送，RTF 将附件打包为微软私有的 TNEF 格式 winmail.dat。非 Outlook 客户端无法解析该格式。
1. 发件人：新建邮件 → "设置文本格式" → 改为 HTML 或 纯文本 后重新发送。
2. 一次性修复：文件 → 选项 → 邮件 → "以该格式撰写邮件"下拉选 HTML。
3. 已收到且不想麻烦对方重发：用在线 TNEF 解码工具提取附件。
参考：Microsoft Outlook Email Formats · RFC 2045 (MIME)
DNS 中存在多条以 v=spf1 开头的 TXT 记录。RFC 7208 §4.5 规定一个域名必须只有一条 SPF 记录，多条时接收方返回 PermError。
1. 检查：nslookup -type=txt yourdomain.com | findstr "v=spf1"。
2. 将全部 include:/ip4:/ip6: 授权合并为一条。
3. 删除 DNS 中多余的 SPF TXT 记录（勿误删其他 TXT 记录）。
4. 等待 DNS TTL 生效后重新测试。
参考：RFC 7208 §4.5 (Selecting Records) · RFC 7208 §4.6.4
发件客户端使用的字符编码与收件人不兼容。常见场景：(1) Outlook 未设置 UTF-8 编码；(2) 用程序代码发信时 MIME 头未声明 charset=utf-8；(3) 服务器自动转换编码导致乱码。
1. Outlook：文件 → 选项 → 邮件 → 编辑选项 → 高级 → 国际选项 → 将待发邮件编码设为 Unicode (UTF-8)。
2. Foxmail：账户设置 → 高级 → 发送编码选 UTF-8。
3. 程序代码发信：确保 MIME 头声明 Content-Type: text/plain; charset=utf-8。
4. Python smtplib：在 MIMEText 中指定 _charset='utf-8'。
参考：RFC 3629 (UTF-8) · RFC 2045 (MIME) · RFC 2231
主流邮箱的反垃圾系统有"学习"机制：收件人手动标记垃圾会训练个性化过滤器，后续来自同一发件地址的邮件可能自动归入垃圾箱。
1. 请收件人在垃圾箱中找到你的最新一封邮件，点击"这不是垃圾邮件"或"移动到收件箱"。
2. 同时请收件人将你的发件地址加入通讯录/联系人。
3. 注意：已在垃圾箱中的旧邮件不会自动移回，需逐个手动操作。
4. Gmail 用户：还可创建过滤器 → 发件人=你的地址 → "永不将其发送至垃圾邮件"。
参考：Google Gmail Spam Settings · NIST SP 800-177 Rev.1
邮件转发会破坏原发件域的 SPF 认证。转发服务器将 envelope-from 改为自己，收件方检查 SPF 时对转发服务器 IP 做认证——如果原发件域配置了 DMARC p=reject，SPF 验证失败的转发邮件会被直接拒收。
1. 确认退信原因：看退信中是否提到 DMARC / SPF 相关提示。
2. 使用邮件服务商的自动转发功能，联系其技术支持确认是否支持 SRS（Sender Rewriting Scheme）——SRS 重写回信地址可修复 SPF 问题。
3. 替代方案：改用邮件客户端 POP3 收取再转发，或定期登录原邮箱手动处理。
4. 如果你控制原发件域：将 DMARC 策略调整为 p=none（仅报告不拦截），但这会降低域名安全性。
参考：RFC 7489 (DMARC) · RFC 7208 (SPF) · RFC 8617 (ARC Protocol)
最常见原因：(1) 图片是网络链接（URL 引用）而非嵌入到邮件中，常见邮箱默认阻止外部图片；(2) 图片托管服务器不可访问或链接已过期；(3) Outlook 自身的 CID 图片引用 bug（微软2026年5月确认的已知问题）。
1. 发件人侧：在邮件中直接粘贴图片（Ctrl+V）而非插入图片链接。嵌入到邮件中的图片不会被阻止。
2. 如必须使用链接：确认图片 URL 可公网访问且未过期。
3. 收件人侧：右键图片位置 → 下载图片；或在 Outlook 信任中心中允许自动下载图片。
4. Outlook 图片红叉 bug：检查图片的 cid 内容 ID 是否异常，微软已发布补丁，更新 Office 到最新版本。
参考：RFC 2392 (Content-ID) · Microsoft Outlook Known Issues 2026
DMARC p=reject 要求收件方拒绝所有 SPF 与 DKIM 均验证失败的邮件。常见"误杀"场景：(1) 域名使用了第三方邮件转发（forwarding），转发破坏了 SPF；(2) 组织有多个发信渠道（CRM、工单系统、营销平台等），部分未纳入 SPF/DKIM；(3) 子域名未配置独立 SPF/DKIM 记录。
1. 先调回监控模式：将 DMARC 策略改为 p=none，确保不会继续拒收邮件。
2. 读报告找漏洞：查看 DMARC 记录中 rua 邮箱收到的每日聚合报告（XML 格式），找出所有发信源及其认证通过率。
3. 补全认证：为每一个合法发信渠道配置 SPF 和 DKIM。
4. 逐步收紧：确认全部合法源通过后，先改为 p=quarantine（标记垃圾箱），运行一段时间无误后再改为 p=reject。
5. 建议：切勿直接跳到 p=reject，从 p=none → p=quarantine → p=reject 渐进式部署。
参考：RFC 7489 (DMARC) · M3AAWG DMARC Best Practices · Google DMARC Implementation Guide
收件方使用 SpamAssassin 反垃圾系统，你的邮件触发了垃圾内容规则（如 BAYES_99、HTML_MESSAGE、URI_WPBL 等），综合评分超过拒绝阈值。
1. 简化主题和正文，去掉过度营销化措辞。
2. 以纯文本格式发送一封测试邮件——如果通过说明原邮件 HTML 或链接触发了规则。
3. 减少邮件中的外链和图片数量。
4. 请收件人将你的发件地址加入白名单后重试。
5. 需要频繁与该收件方通信：请对方联系其邮件服务器管理员提供 SpamAssassin 命中规则详情。
参考：RFC 5321 §4.2.2 · Apache SpamAssassin Wiki
第三方平台的发信服务器 IP 未包含在你域名的 SPF 记录中。收件方检查 SPF 时发现发信 IP 不在授权列表里，导致 SPF Fail。
1. 在 DNS 的 SPF 记录中加入该平台的 include: 机制：
- SendGrid：include:sendgrid.net
- Mailgun：include:mailgun.org
- 阿里云邮件推送：include:dm.aliyun.com
- AWS SES：include:amazonses.com
2. 合并示例：v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all
3. 为该平台配置 DKIM（平台提供 DKIM 公钥添加到 DNS）。
4. 等待 TTL 生效后用 MXToolbox SPF 检查器验证。
参考：RFC 7208 (SPF) §5.2 · SendGrid SPF Setup · Mailgun SPF Setup
QQ 邮箱有三层独立的发信频率限制：(1) Domain frequency limited = 整个发件域名的总发信量/频率触达阈值 → 封禁该域名所有发信若干分钟到若干小时；(2) Sender frequency limited = 单个发件人地址发信过快/过多 → 封禁该邮箱若干分钟；(3) Connection frequency limited = 发信 IP 并发连接数过多或短时间频繁建立/断开连接 → 封禁该 IP。QQ 邮箱不公开具体阈值数值。
1. 统一先降低速率：单分钟 ≤60 封、每封间隔 1-2 秒、并发 SMTP 连接 ≤5。
2. 同一域名用多个子账号分摊发信量（noreply1@、noreply2@…）。
3. 不要把大量 QQ 号收件人集中一批发——分散到不同批次、穿插发给其他域名收件人。
4. 新 IP/新域名前 3 天日发 <500 封且均匀分布到全天（不要突发）。
5. 被限制后不要反复重试——大量重试延长封禁时间，通常等 1-6 小时自动解封。
6. 使用企业邮件系统作为发信通道，通常享有更高频率上限和内部信任。
7. 自建批量发信需高频 → 多 IP 部署 MTA 负载均衡。
参考：QQ 邮箱帮助中心 · winwebmail 退信说明 · RFC 5321 §4.5.3.2
全球邮件服务商普遍使用 PBL（Policy Block List）和 dynamic/dial-up IP 范围名单拒绝从动态/住宅/ADSL/4G/5G IP 直接发来的邮件。同时多数服务商要求发信 IP 必须有 PTR 反向 DNS 记录（正向 A 指向该 IP → 反向 PTR 指回域名）。原因：动态 IP 是僵尸网络/垃圾邮件的最主要来源——全球 >90% 的垃圾邮件来自被感染的动态 IP 设备。
1. 确认 IP 类型：在 Spamhaus PBL 查询你的 IP——如果被列出就是动态 IP 段，基本无法直投邮件。
2. 申请 PTR 记录：(a) 阿里云：控制台 → 弹性公网 IP → 反向解析 → 填写你的邮件主机名（如 mail.xxx.com）→ 确保域名 A 记录指向该 IP → 提交申请；(b) 其他云：联系客服工单。(c) 家庭宽带：ISP 通常不提供 PTR 设置。
3. 无法获取 PTR 时的替代方案：不要从该 IP 直接投递！改用 SMTP relay（中转）模式——把你的邮件通过认证后提交给专业发信平台：(a) 昆仑邮件系统 SMTP relay、(b) SendGrid、(c) Mailgun、(d) Amazon SES、(e) 各类邮件推送服务。这些平台的 IP 已有稳定信誉和 PTR。
4. Postfix 中转配置：/etc/postfix/main.cf 中设置 relayhost = [smtp.sendgrid.net]:587 + SASL 认证即可。
参考：RFC 5321 §4.1.4（反向 DNS 建议）· RFC 1912 §2.1 · Spamhaus PBL
与行为反垃圾（频率/速率/Q53）和认证验证（SPF/DKIM/Q46）不同——内容过滤是审核你邮件中写了什么。收件方的内容过滤引擎（如 SpamAssassin、Rspamd、微软 EOP、Google Content Filtering）扫描正文/主题/附件/H5代码后判定为垃圾特征而拒绝。常见触发：(1) 主题含大量感叹号、全大写、夸张营销语言（"限时抢购!!!!""免费!!!100%有效!!!"）；(2) 正文链接过多、文字过少；(3) HTML 邮件含隐藏文字（如白色字体）、1x1 追踪像素、恶意 JavaScript；(4) 附件的文件头特征被识别为恶意；(5) 大量邮件正文雷同——群发邮件内容模板化程度过高。
1. 简化主题：去掉所有感叹号和全大写、避免夸张词汇（"免费""奇迹""100%"）
2. 平衡正文：确保文字内容比例远大于链接数量（至少 3:1 的文字:链接比）
3. 去掉隐藏追踪：不插入 1px 追踪图、隐藏文字、恶意脚本
4. 先发纯文本版本测试：把同一封邮件改成纯文本（Plain Text）发送到目标地址——如果纯文本能过，说明 HTML 内容被拦截；修改 HTML 后重试
5. 差异化群发：避免所有邮件正文完全雷同——加上收件人姓名变量、调整部分措辞
6. 被误判时：请收件人把你的发件地址加入白名单/安全发件人列表
参考：SpamAssassin 规则文档 · 网易企业邮箱帮助 · RFC 5321
"已发送"仅表示发件服务器接受并投递了邮件，不等于对方一定收到了。常见原因：(1) 邮件被对方邮箱服务商无声丢弃；(2) 邮件被分到 Gmail 的"促销"/"社交"等非主收件箱标签页；(3) 收件人设了过滤规则将邮件移到其他文件夹。
1. 请对方搜索你的发件地址，检查所有文件夹和标签页。
2. 请对方将你的发件地址加入通讯录/联系人。
3. 确认地址无误后重新发送并在正文注明"收到请回复"。
4. 持续出现此问题：用 mail-tester.com 测试邮件评分和可送达性。
参考：Google Gmail Category Tabs · NIST SP 800-177 Rev.1
突然全面退信通常指向三类原因：发件 IP 刚被列入黑名单、DNS 记录失效或变更出错、邮箱账户被暂停或限流。
按优先级排查：
1. 查黑名单：在 MXToolbox 输入发件 IP，看是否刚被列入 Spamhaus/Barracuda 等黑名单。
2. 查 DNS：确认 SPF/DKIM/DMARC 记录是否仍能查到。
3. 查账户状态：登录网页版邮箱看是否有异常提示（锁定、超额、暂停）。
4. 查变更：最近 24 小时内是否修改了 SMTP 配置或 DNS 记录？如有则回滚。
5. 联系服务商：以上都正常则联系邮箱服务商技术支持。
参考：MXToolbox Blacklist Check · RFC 7208 · RFC 6376 · RFC 7489
邮件延迟最常见原因是灰名单（greylisting, RFC 6647）：收件方对首次见到的发信三元组返回临时拒收（4xx），发件服务器自动等待后重试。正常延迟在几分钟到一小时。更长的延迟可能由收件方服务器队列积压或网络路由问题导致。
1. 延迟在 1 小时内：正常现象，无需处理。
2. 延迟超过 4 小时：联系邮件服务商技术支持，提供发件时间和收件地址，请其查询投递日志。
3. 频繁出现长延迟：企业邮箱用户请管理员检查发件服务器队列是否有积压。
参考：RFC 5321 §4.5.4.1 (Retry Strategies) · RFC 6647
SMTP 退信包含标准化的状态码和诊断信息，无需逐字读懂整封退信也能抓出关键信息。
1. 看第一位数字：4xx = 临时失败（系统会自动重试，无需操作）；5xx = 永久失败（需人工修正后重发）。
2. 找到收件方返回的消息：退信中看 said: 或 Remote Server returned 后面的内容——那是收件方邮件服务器给出的确切原因，最关键。
3. 按错误码搜索：把退信中的错误码（如"550 5.1.1"）加关键词搜索，即可找到针对性解决方法。
参考：RFC 5321 §4.2 (SMTP Reply Codes) · RFC 3463 (Enhanced Mail System Status Codes)
大型邮箱对新出现的发信 IP 和域名默认不信任——没有信誉积累。垃圾箱判定由 IP 信誉、域名信誉、认证完整度、内容质量、用户互动率等多维因素决定。
1. 认证三件套：确认 SPF、DKIM、DMARC 均已配置并通过验证。
2. PTR 反向解析：联系 VPS/主机商为发信 IP 设置 PTR，指向可正向解析回该 IP 的域名。
3. IP 预热：新 IP 先给少量活跃用户发，逐步增加（2-4 周）。
4. 查黑名单：MXToolbox 查 IP 黑名单，VPS IP 段常被 Spamhaus PBL 预拦截。
5. 测分：用 mail-tester.com 评分，目标 ≥9/10。
6. 监控信誉：注册 Google Postmaster Tools、Microsoft SNDS。
7. Docker 环境：确保 MTA 的 myhostname 设为真实 FQDN 而非容器随机 ID。
8. 邮件内容确保有文字、无可执行附件、不是纯图片。
参考：RFC 7208 (SPF) · RFC 6376 (DKIM) · RFC 7489 (DMARC) · RFC 1912 §2.1 (PTR) · Google Postmaster Tools · Microsoft SNDS
421 表示临时拒绝（服务器说"现在不行，等下再试"），正常 MTA 会排队自动重试。4.4.5=接收方服务器繁忙/过载；4.7.0=IP 发信行为异常触发反垃圾临时阻断。但如果几分钟后持续不过，通常是你的发信 IP 或域名信誉出了系统性问题，而非简单的临时波动。
1. 注册 Google Postmaster Tools 查看域名和 IP 的实际信誉状态（Spam Rate、IP Reputation、Domain Reputation、Feedback Loop）。
2. 确认发信量在合理范围：新 IP 日发 <500 封逐步增长，突发暴增会触发限速。
3. 查是否被 Google Safe Browsing 标记为不安全（会连带影响邮件信誉）。
4. 降低发信速率：单连接速率 ≤1封/秒，并发连接 ≤5。
5. 大发送量场景考虑用 Gmail SMTP relay 或 Google Workspace 官方通道。
6. 所有认证 SPF/DKIM/DMARC 必须通过，DMARC p=至少为 none。
参考：Gmail 发送限制 · RFC 5321 §4.2.1 · Google Postmaster Tools
邮件投递链路长（发件客户端→发件SMTP→可能中转→收件MX→收件反垃圾→收件箱），任何一个环节都可能出问题。服务商说"没问题"通常只看自己的发件队列没有堆积，不保证送达。
1. 看发件日志：邮件状态是 Sent（已发出）、Deferred（排队等重试）、Bounced（退回）？Deferred 超过 4 小时=大概率最终进垃圾箱或硬退。
2. telnet 手工投递：nslookup -q=mx <收件域名> 找到 MX 记录 → telnet → 手工 EHLO/MAIL FROM/RCPT TO/DATA 发送一封简单测试邮件，记录每一步的响应码。
3. 读退信的 DSN 部分：退信（NDR/DSN）中 Remote-MTA 行告诉你最后是哪个服务器拒绝的。
4. MXToolbox Email Health：一次性检测 DNS/MX/SPF/DKIM/DMARC/黑名单/PTR 7 项。
5. mail-tester.com：发送一封测试邮件给随机地址，获取综合评分报告（内容/认证/黑名单/链接/HTML质量），目标 ≥9/10。
6. 数据说话：注册 Google Postmaster Tools + Microsoft SNDS，看实际送达率/垃圾邮件率——而不是"我觉得被拦了"。
参考：RFC 5321 §3.7 · RFC 3464 (DSN 格式) · MXToolbox · mail-tester.com
这和 Q55（DNS 查不到域名）不同——你的 DNS 在你自己这边查是正常的（MX/A/CNAME 都有），但收件方用了 Postfix sender address verification（发件地址回调验证）：收件方服务器不只是查 TXT 记录，而是主动向你的域名发 SMTP 连接，假装要发一封邮件到你的 MAIL FROM 地址，看你的服务器会不会接受。如果回调连接失败或返回地址无效，就拒收。可能原因：(1) 你的邮件服务器 25 端口从收件方网络不可达——你只开了 587 提交端口但 25 端口被防火墙拦截；(2) 你用的是纯发信环境（send-only），没有收信 MX、25 端口未开放；(3) 你的 MAIL FROM 域名和实际发信服务器不是同一个主体——对方回连到 MAIL FROM 的 MX 后发现不存在该邮箱；(4) DNS 区域线路限制——你的 A/MX 记录只对国内 DNS 生效，海外收件方的 DNS 查不到。
1. 测试 25 端口连通性：从外网环境 telnet your-mx-hostname 25，确认返回 220 开头的 SMTP 欢迎信息。
2. 不要关 25 端口：586/587 是提交端口，邮件服务器之间的传输走 25 端口。如果你关了 25 或只允许 587——对方 MTA 无法回连验证。
3. 配置 Postfix sender verify 白名单（如果可以控制收件方）：在收件方 /etc/postfix/main.cf 中 smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access。
4. 联系收件方 IT：说明你的域名 DNS 正常，请对方将你的发件地址/发件域加入 sender verify 例外列表。
5. 确保 MAIL FROM 域名的 MX 指向可连接的服务器：使用免费邮箱服务（如阿里企业邮箱、Gmail SMTP）的 MAIL FROM 改为它们自己的域名，它们保证 25 端口可达。
参考：Postfix verify(8) 手册 · RFC 5321 §3.2
无退信≠送达。静默丢失常见 4 种情况：
1. DMARC p=reject 静默丢弃——收件方验证 SPF/DKIM 失败→DMARC 对齐失败→拒绝，收件方按 RFC 7489 不产生退信（DMARC reject 不响应 bounce）→邮件人间蒸发。
2. 放进了垃圾箱（Spam Folder）——收件方反垃圾引擎判定为低信誉邮件 放进垃圾箱而不通知你。收件人不去翻垃圾箱就以为没收到。
3. 灰名单（Greylisting）暂存——收件方临时返回 451 临时失败 让发信服务器稍后重试。正常 5-30 分钟后重试成功投递 如果重试还没到就是被彻底拒绝但已有退信在路上了。
4. 发信服务器自身发送队列堵塞——邮件根本没出你的服务器（队列拥堵、DNS 解析失败、TLS 连接超时反复重试中）——这时候你看本地队列会发现攒了一堆 但没退信因为还没尝试完。
1. 检查你自己的发信服务器队列：Postfix: mailq（或 postqueue -p）；Exim: exim -bp；Sendmail: mailq。看有没有待投递的邮件堆积在某特定收件域上。
2. 检查发信日志：grep 'recipient@domain' /var/log/maillog（或 journalctl -u postfix），看最后一条 SMTP 应答是什么。status=deferred 是正在重试 不是已丢失。
3. 查 DMARC 聚合报告：打开你 rua 邮箱收到的 XML 报告→搜索收件方域名→看 disposition 字段：reject=已拒绝且无退信、quarantine=进垃圾箱、none=正常通过。
4. 叫收件人去垃圾箱找：如果上面三步都没有异常→叫收件人搜你的发件地址/主题词 翻垃圾箱。
参考：RFC 7489（DMARC §6.7 关于 reject 不产生 DSN）· RFC 5321 §4.5.4 · Postfix Qshape 文档
552 5.2.2：永久错误，立即通知发件人收到 NDR 退信。452 4.2.2：临时错误，服务器队列重试（最多 5 天数十次），不立即通知。
发件方 552 需立即通知收件人。452 不急但提醒。收件方清理邮件或扩容。自建服务器：postqueue -p 或 doveadm quota get。预防：配额告警 80% 提醒，95% 紧急。
参考：RFC 5321 4.2.2 · Postfix mailbox_size_limit · Dovecot quota 文档
Spamhaus 是全球最大的反垃圾邮件组织，其 ZEN 黑名单整合了 SBL（手工黑名单）、XBL（漏洞利用黑名单）、CBL（行为黑名单）、PBL（策略黑名单）。被列入后，所有使用 Spamhaus 的邮件服务商（Gmail/Outlook/Yahoo 等）都会拒绝你的邮件。查看退信中返回的链接确认被列入哪个列表。
1. 定位列表：访问 spamhaus.org/lookup 输入 IP 查询被列入哪个子列表。
2. PBL 解除：PBL（策略黑名单）——点击 Remove an IP from PBL，填写 IP/邮箱/国家/类型，用收到的 5 位验证码确认。邮箱不能用 Gmail/Hotmail/Yahoo 等免费邮箱，必须用发件域的真实邮箱。
3. CBL/XBL 解除：被列入说明 IP 有发垃圾行为（可能被黑客利用），先清除恶意软件/修复安全漏洞。CBL 自动检测并移除，通常在 24 小时内。
4. SBL 解除：最严重的手工黑名单，通过 Spamhaus 官网提交详细申诉。
5. 解除后约 1 小时生效。解除后查找并修复被列的根本原因，否则会被再次列入。
参考：Spamhaus PBL FAQ · Spamhaus CBL FAQ · RFC 5782 (DNSBL)
微软将你的发信 IP 列入了内部拦截列表（S3140/S3150 为微软内部代号）。与 Spamhaus 不同，这是微软自家的信誉系统，通常因为历史上有 Outlook/Hotmail 用户将你的邮件标记为垃圾邮件。
1. 注册 SNDS：访问 Microsoft SNDS，用发信 IP 对应的域名邮箱注册。
2. 验证 IP 所有权：在 SNDS 中请求 IP 访问权限，需邮件域名管理员确认。
3. 注册 JMRP：同步注册 JMRP（垃圾邮件报告计划），接收 Outlook 用户投诉报告。
4. 根据投诉整改：分析 JMRP 报告中的投诉原因（内容类似垃圾、收件人不认识发件人等）。
5. 提交申诉：在 SNDS 面板中提交解除请求，通常 1-3 个工作日处理。
6. 务必先确保 SPF/DKIM/DMARC 配置正确，否则解封后可能再次被列。
参考：Microsoft SNDS (Smart Network Data Services) · Microsoft JMRP · Outlook.com Deliverability Guide
设置 rua=mailto:你@你的域名.com 后，支持 DMARC 的收件方（Gmail、Outlook、Yahoo 等）每天给你发一封或多封 ZIP 压缩邮件，里面是 XML 格式的聚合摘要报告——报告过去 24 小时内你的域名被哪些 IP 发信、发多少封、过没过 SPF/DKIM 验证、DMARC 最终结果。
一条报告记录的关键字段：
• <source_ip>：发信的源 IP 地址
• <count>：从这个 IP 发了多少封
• <disposition>：收件方实际处理（none=正常入收件箱，quarantine=入垃圾箱，reject=拒收）
• <spf>result/pass|fail：SPF 验证结果
• <dkim>result/pass|fail：DKIM 验证结果
• <header_from>：你在 DMARC 中指定的 Header From 域名
• <policy_evaluated>dkim/spf：DMARC 对齐判定（not just pass, but aligned）
DMARC 要求不仅要 SPF/DKIM pass，还要"域名对齐"——即验证的域名必须与 From 头显示域名一致：
• Strict（严格对齐）：SPF 域=From 域、DKIM d=From 域（完全匹配）
• Relaxed（宽松对齐）：组织级域名相同（如 mail.example.com 与 example.com 也算对齐）
常见坑：你的 SPF pass 了但域名不对齐——因为 MAIL FROM 用的不是你自己的域名（比如用 SendGrid 发信但 MAIL FROM 是 sendgrid.net → SPF 对齐失败 → DMARC fail）。解决办法：第三方发信服务要配置自定义 MAIL FROM 域名。
原始 XML 量很大（一天几千条），手动看不现实。免费工具：
• dmarcian.com（Web 界面，免费基础版）
• parsedmarc（开源 Python CLI：pip install parsedmarc → parsedmarc --file=report.xml 自动生成 CSV/JSON）
• MXToolbox DMARC Analyzer（在线简单查看）
• URIports（免费基础版）
建议选一个工具配置定期自动解包，人工看不过来。
参考：RFC 7489（DMARC）· DMARC.org · parsedmarc 项目主页
国内云厂商（云服务商）默认封禁云服务器 TCP 25 端口出方向流量，防止服务器被用作垃圾邮件发送源。
几乎所有 SMTP 服务商支持的替代端口：
465 端口（SSL 隐式加密）
587 端口（STARTTLS）
客户端/代码切换端口即可，无需申请。
云服务商：控制台 → 头像 → 安全管控 → 25端口解封 → 填写IP和域名 → 提交（约1个工作日审核）。
云服务商：部分云服务商支持即时解封（安全管控 → 25端口解封 → 选择实例，即时生效） → 安全管控 → 25端口解封 → 选择实例（即时生效，限5次）。
解封后需在安全组放行25端口出方向。禁止直连外部MTA发垃圾邮件，否则永久封禁。
参考：云服务商邮件推送 文档 · 云服务商 25端口解封文档 · RFC 8314
25：MTA间中继（服务器→服务器），RFC 821（1982）定义。国内云厂商默认封禁。
465：SMTPS（隐式SSL/TLS），连接即加密。曾弃用，RFC 8314重新推荐为安全端口。
587：Submission（邮件提交端口），STARTTLS升级为加密，现代客户端标准。
2525：非标准备选端口，部分服务商（如SendGrid/Mailgun）提供以替代被封的25。
程序发信（Python/Java/PHP）：587（STARTTLS）或465（SSL）
邮件客户端（Outlook/Foxmail/Thunderbird）：587或465
自建MTA（Postfix/Exchange）对外通信：25
国内云服务器：直接弃用25，用465/587。
参考：RFC 821 · RFC 8314 · Mailgun: Which SMTP Port to Use
553 表示发件地址与SMTP认证用户不匹配，服务器拒绝。常见于代码调用SMTP时 From地址写了一个未授权的地址。
1. SMTP认证用户名即你的完整邮箱地址（如 user@domain.com），不是前缀
2. 代码中 From 地址必须等于登录用户名
3. 腾讯企业邮/阿里企业邮支持代发：管理后台-添加允许代发的外域地址
4. SendGrid/Mailgun：先验证发件域名所有权才能用该域发信
5. Exchange Server：接收连接器权限勾选"匿名用户"
参考：RFC 4954 SMTP AUTH · RFC 6409 Message Submission · 邮件系统帮助文档
DKIM签名包含对邮件正文的哈希值。收件方重新计算哈希，发现不匹配，说明正文在签名被添加后又被修改过。
1. 自动转发/邮件网关：中间服务器修改了正文（加footer/免责声明/编码转换）——最常见
2. 邮件列表/Mailman：在正文追加订阅信息和链接
3. MIME编码转换：如 Quoted-Printable → Base64
4. 反病毒/防泄露系统：在签名后追加安全标记或修改正文
确保 DKIM 签名在邮件处理链的最后一步生成（所有内容修改完成之后）。
使用宽松规范化（relaxed/relaxed而非 simple/simple），容忍空白和编码差异。
在线测试：dkimvalidator.com 或 mail-tester.com
参考：RFC 6376 DKIM Signatures §3.4 Body Length Limits · RFC 6376 §5.3 Relaxed Canonicalization · OpenDKIM 文档
退信头中的 X-Spam-Status: Yes, score=8.5 required=5.0 表示：
score=8.5：SpamAssassin为此邮件打的垃圾概率总分
required=5.0：阈值，超过即判定为垃圾（YES）
后面列出命中的规则名，如 RCVD_IN_PBL, HTML_MESSAGE, BAYES_80
RCVD_IN_PBL / RCVD_IN_XBL：发信IP在Spamhaus PBL或XBL → 到Spamhaus申请移除或换固定IP
HTML_MESSAGE + HTML_IMAGE_ONLY：只有图片没有文字 → 增加正文文本比例
BAYES_50/80/99：贝叶斯分析认为像垃圾邮件 → 大幅修改邮件文案
T_SPF_PERMERROR：SPF记录语法错误 → 修复SPF记录
调高阈值：required_score 8.0（/etc/mail/spamassassin/local.cf）
添加白名单：whitelist_from *@trusted-domain.com
训练贝叶斯：sa-learn --ham 学习正常邮件
参考：SpamAssassin 官方文档 spamassassin.apache.org · Spamhaus PBL FAQ · SA 规则文档
常见免费邮箱反垃圾系统（网易自研引擎）拒绝了你的邮件。DT:SPM 是网易专用反垃圾代码。常见触发：(1) 主题或正文含促销敏感词（如"免费""优惠""发票""促销"）；(2) 邮件中超链接过多；(3) 纯图片邮件几乎没有文字；(4) 短时间内向大量收件人发送相同内容。
1. 修改主题，去掉促销/营销类敏感词。
2. 减少邮件中的超链接数量。
3. 正文确保有足够文字（建议 ≥100 字），不要只发一张图片。
4. 发送时将自己（发件人）加入抄送（CC）——这经常是一个立竿见影的方法。
5. 降低单次发送量，分批发送。
6. 确认使用的是邮箱授权码（在邮箱设置中开启 SMTP 服务后获取）而非网页登录密码。
参考：163邮箱 SMTP 错误码说明 · 邮件系统帮助中心 · RFC 5321 §4.2.2
每封邮件携带完整的传输元数据——类似快递包裹上的逐站扫描记录。从发信到收信，每一跳 MTA 在邮件顶部添加一个 Received: 头，最终形成从下到上的完整路由链。此外还包括 SPF/DKIM/DMARC 验证结果、垃圾评分、发件人信息、时间戳等。邮件头是诊断投递问题的第一手证据。
• Gmail（Web版）：打开邮件 → 右上角三点 → 「显示原始邮件」
• Outlook 桌面版：双击邮件 → File → Properties → Internet headers 文本框
• Outlook.com Web版：打开邮件 → 三点 → 查看 → 查看邮件源
• QQ/网易企业邮箱：打开邮件 → 更多 → 查看信头/显示原文
1. Received 链（从下往上读）
底部第一条 Received: = 发信人邮件客户端 → 发信服务器（提交阶段）
中间每一条 Received: = 服务器到服务器的转跳
顶部最后一条 Received: = 最后一跳 MTA → 收件人邮箱
每行包含：服务器主机名、IP 地址、时间戳、with 协议（ESMTP/ESMTPS/LMTP）、TLS 加密版本（version=TLS1_2 或 version=TLS1_3）。找到时间跳变大的跳→ 该跳是瓶颈所在。
每个收件方服务器会在邮件头中加入一行：Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com
读法：
• spf=pass/fail/neutral/softfail：SPF 验证结果——fail 说明发信 IP 不在你的 SPF 允许列表中
• dkim=pass/fail/none：DKIM 签名验证结果——fail 说明签名被篡改或签名域名与 From 不匹配
• dmarc=pass/fail：DMARC 对齐结果——即使 spf 和 dkim 都 pass，如果域名不对齐仍然 dmarc=fail
X-Spam-Status: Yes, score=7.8——score 是 SpamAssassin 等垃圾过滤器的评分，≥5 通常判定为垃圾。X-Spam-Report:列出触发每条规则的得分明细——看哪条规则触发得分最高 → 针对性修改邮件内容。
注意：Gmail 和 Outlook 不对外暴露内部垃圾评分逻辑，仅有自建/开源 MTA 部分会带这些头。
MXToolbox Email Header Analyzer：把整段原始邮件头粘贴进去 → 自动解析 Received 链、SPF/DKIM 状态、时间线可视化 → 比用手逐行看快很多。Google Admin Toolbox Messageheader 也提供类似功能。
参考：RFC 5322（Internet Message Format）· RFC 8601（Authentication-Results 头格式）· MXToolbox Email Header Analyzer · Google Admin Toolbox
微软对所有发往 Outlook.com/Hotmail/Microsoft 365 的邮件按发信 IP 的历史信誉评分——IP 信誉低于阈值→直接拒收（550 5.7.1 / 550 5.7.511 Access denied / blocked）。这和你的 SPF/DKIM 配没配好是两件不同的事——信誉看的是你的发信历史行为（投诉率、发送量、是否群发）。新 IP 或从共享主机发信的 IP 特别容易低信誉。
1. 注册 SNDS（Smart Network Data Services）：访问 postmaster.live.com/snds → 用微软账号（Outlook.com/Microsoft 365 账号）登录 → 申请你的 IP 范围的数据访问权限 → 获批后可以看到你 IP 的发信量、投诉率、垃圾邮件陷阱命中数。
2. 检查 JMRP（Junk Email Reporting Program）：SNDS 里的投诉率来自 JMRP——Outlook 用户的「标记为垃圾邮件」操作次数。投诉率超过 0.1%（每 1000 封邮件超过 1 个投诉）→触发封锁概率大幅上升。
3. 提交解封申请：确认没有发垃圾邮件且修正了问题（如已配置 SPF/DKIM、已预热新 IP、已确认用户是主动订阅不是滥发）→ 通过 postmaster.live.com 的「Delist/Unblock」表单提交 IP 白名单申请→填写：IP 地址、用途描述（如「企业邮件服务器，仅发送事务性通知」）、已修正的问题。
4. 等待处理 3-5 个工作日：解封申请不是立刻生效的 耐心等待。处理期间继续发信只会降低你信誉。
前置条件：解封申请前必须先配置好 SPF 和 DKIM——没配置直接提交申请会被拒绝。
预防：新 IP 先预热再发 Outlook 用户（见 Q9 服务器预热）。
参考：Microsoft SNDS 文档 · Outlook Postmaster · Microsoft Learn NDR 5.7.1 修复指南
BIMI（Brand Indicators for Message Identification）让支持该标准的邮箱在收件箱列表里显示发件人的品牌 Logo——你的公司 Logo 出现在用户收件箱中邮件的旁边。当前支持：Gmail（免费/付费版均支持）、Yahoo Mail、Apple Mail、Fastmail 等。
BIMI 不是一个独立认证协议——它必须建立在 DMARC 之上：DMARC 验证通过后，收件方才去查询并显示 Logo。BIMI 不提升投递率也不提升安全性——它纯粹是品牌视觉效果。
1. DMARC 策略必须是 p=quarantine 或 p=reject 且 pct=100——p=none 不能用 BIMI
2. SPF 和 DKIM 必须通过
3. Logo 文件必须是 SVG Tiny 1.2 格式（不是专业版 SVG）——用 BIMI SVG 转换工具压缩到 32KB 以下，方形、居中、纯色或渐变
4. Logo 文件托管在 HTTPS 可访问的 URL（如 https://yourdomain.com/logo.svg）
Gmail 不需要 VMC 就能显示——如果只需要在 Gmail 中显示 Logo，你甚至不需要 VMC。
Yahoo/Apple Mail 需要 VMC（Verified Mark Certificate）——这是由证书颁发机构（DigiCert/Entrust）签发的品牌认证证书，证明你的 Logo 是合法注册商标。VMC 证书需要付费（约 $1000-1500/年）。
简单版（仅 Gmail）：default._bimi.yourdomain.com TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=self"→ a=self 表示你自行认证，不依赖 VMC。
完整版（Gmail+Yahoo+Apple）：default._bimi.yourdomain.com TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=cert"→ a=cert 表示需要 VMC 验证。a= 字段的可选值在 BIMI 规范中定义。
dig txt default._bimi.yourdomain.com 验证 DNS 记录→ MXToolbox BIMI Checker 检查完整配置→ 发一封测试邮件到 Gmail 检查是否显示 Logo（通常几小时内生效）。注意：Logo 首次出现可能需要 Gmail 缓存刷新——不同收件人看到的速度不同。
参考：BIMI Group 规范（bimigroup.org）· Adobe BIMI 实施文档 · Amazon SES BIMI 文档 · MXToolbox BIMI Checker
554 5.7.1 Relay access denied 表示 SMTP 服务器拒绝中继。Open Relay 是垃圾邮件主要来源，Postfix 默认禁止 relay。
Step 1：确认发信人来源
来自外部客户端（Thunderbird/Outlook）需启用 SMTP AUTH：/etc/postfix/main.cf 设 smtpd_sasl_auth_enable=yes。
来自同机 Web 应用（PHP/Python）加到 mynetworks：mynetworks = 127.0.0.0/8, 192.168.1.0/24, ::1
Step 2：确认收件域
自己的域名加到 mydestination：mydestination = yourdomain.com
代收域名加到 relay_domains
重启：service postfix restart。测试：telnet localhost 25 验证。
Exchange：管理中心-邮件流-接收连接器-匿名用户权限。
参考：Postfix 文档 · RFC 5321 3.8.2 · Red Hat KB 1282193
收件方检查 HELO 主机名合法性。退信：553 5.7.1 HELO hostname does not match。
1. myhostname 必须是全限定域名（FQDN）在 DNS 有 A 记录
2. NAT 后面用 smtp_helo_name = mail.yourdomain.com 强制 HELO 名称
3. PTR 反向 DNS 与正向 A 一致
4. 检查防火墙是否改写 HELO 名称
参考：RFC 5321 4.1.1.1 · Postfix main.cf · PTR 反向 DNS
Google 2025 年关闭低安全性应用方式。
1. 开启两步验证
2. Google 账号-安全-应用密码，生成 16 位密码
3. 客户端替换原密码
4. SMTP: smtp.gmail.com 端口 587（TLS）
用于程序发信，需 Google Cloud Console 创建 OAuth 客户端 ID。免费 Gmail 日限额约 500 封，批量发信用 Google Workspace 或 SendGrid。
参考：Google Account 安全设置 · Google Workspace OAuth 2.0 文档
退信：530 5.7.0 Must issue STARTTLS / 554 5.7.5 TLS required / Server certificate SAN mismatch。
1. Postfix 设 smtpd_tls_security_level = may 启用 TLS
2. Let's Encrypt 免费证书：sudo certbot certonly --standalone -d mail.domain.com
3. 配置 smtpd_tls_cert_file = fullchain.pem（含中间证书，不能用 cert.pem）
4. 证书 SAN 必须匹配域名，避免自签名证书
5. openssl s_client -connect host:25 -starttls smtp 检查链
参考：RFC 3207 SMTP STARTTLS · RFC 8461 MTA-STS · Let's Encrypt Certbot
邮件正文行尾格式不符合 SMTP 规范。SMTP 要求每行以 CR+LF（
，回车+换行）结尾，但你的邮件用了纯 LF（
）——俗称"裸换行"。常见于 Linux/Unix 系统或程序直接用
而非
拼接邮件内容。Exchange Online 和部分严格 MTA 会直接拒收。
1. 代码中确保邮件正文每行以
结尾。
2. PHP：$body = preg_replace('/(?<!\r)\n/', "\r\n", $body);
3. Python：body = body.replace('\n', '\r\n') — 注意不要在已含
的数据上再运行。
4. Postfix 自建服务器：在 main.cf 加 smtp_fix_bare_newlines = yes 自动修复。
5. 确认邮件库（PHPMailer、nodemailer 等）为最新版本。
参考：RFC 5321 §2.3.7 / §4.1.1.4（CRLF 行尾要求）· Microsoft Learn NDR 5.6.11
收件方服务器对发信 IP 做了反向 DNS 查询（PTR 查询），但没有找到 PTR 记录，或 PTR 记录指向的域名无法正向解析回同一 IP。PTR 是 IP→域名的映射，由 IP 归属方（ISP/IDC/VPS 商）设置，你不能自己在 DNS 控制台设。Gmail、Outlook、QQ 邮箱等大型服务常要求有 PTR 作为基本反垃圾手段。
1. 联系你的 VPS 或服务器提供商（如阿里云/腾讯云/AWS），要求为发信 IP 添加 PTR 记录。
2. PTR 指向的域名应与你的邮件服务器 HELO/EHLO 主机名一致（如 mail.yourdomain.com）。
3. 该域名必须有 A 记录能正向解析回同一 IP（正向+反向一致）。
4. 验证：nslookup <IP> 返回域名 → nslookup <域名> 返回同一 IP。
5. 如用家庭宽带/动态 IP → PTR 通常无法设置，改用邮件中继服务（如 SendGrid/Mailgun）。
参考：RFC 1912 §2.1（PTR 记录）· RFC 5321 §4.1.1.1（HELO 验证）· Gmail 发件人指南
Gmail 从 2023 年底起对批量发件人强制要求发信 IP 有有效的 PTR 记录，这是"Gmail 发件人指南"中"IP 实践"的一部分。错误码 5.7.25 专指 PTR 缺失或不一致。
1. 联系 IP 提供商为发信 IP 设置 PTR 记录（参见上一条 FAQ 38 的操作步骤）。
2. PTR 指向的域名必须能正向解析回同一 IP。
3. 发信 HELO/EHLO 主机名必须与 PTR 域名一致。
4. 用 MXToolbox Reverse Lookup 验证 PTR 是否生效。
5. 连带检查：SPF、DKIM、DMARC 是否全部配好 — Gmail 5.7.26 会在缺少 DKIM/DMARC 时拒收。
6. 注册 Google Postmaster Tools 监控域名信誉和投递率。
7. 如果是新 IP 新域名，需要预热后再大量发送（参见 FAQ 1）。
参考：Gmail 发件人指南 · RFC 1912 · RFC 7489 (DMARC)
两类错误：5.2.2 Over quota = 收件人邮箱存储空间已用完；5.3.4 = 邮件大小（含附件）超过收件方服务器的接收上限。常见接收限制：Gmail 25MB、Outlook/Hotmail 25MB、常见免费邮箱 50MB、大部分企业邮箱 10-50MB。
1. 检查附件总大小 — 注意 Base64 编码会使实际传输体积增大约 33%。
2. 大附件改用云盘链接：上传到 Google Drive、OneDrive、阿里云盘或奶牛快传，邮件中只放分享链接。
3. 如果提示 Over quota：通知收件人清空邮箱或升级容量。
4. 需要发送数百 MB 文件：用专业大文件传输服务（如 WeTransfer）。
5. 自建服务器：在 Postfix 中用 message_size_limit 控制发出邮件大小。
参考：RFC 5321 §4.5.3.1（SIZE 扩展）· Gmail 附件限制 · Outlook 收发限制
SMTP 用户名或密码未通过服务器验证。最常见 6 种原因：(1) 使用了网页登录密码而非 SMTP 授权码/客户端专用密码；(2) 用户名格式错误；(3) 邮箱开启了二次验证但没生成应用专用密码；(4) 服务器地址或端口/加密方式配错；(5) 账户因异常活动被临时锁定；(6) IP/客户端被服务商标记为不安全。
1. Gmail：需开启二次验证 → 在 Google 账户 → 安全性 → App passwords 生成应用专用密码。
2. QQ 邮箱：设置 → 账户 → POP3/SMTP 服务 → 生成授权码。
3. 常见免费邮箱：设置 → POP3/SMTP/IMAP → 客户端授权密码。
4. 企业邮箱：部分服务 SMTP 密码与网页登录密码独立设置。
5. 确认用户名：大多数服务需要完整邮箱地址（如 user@gmail.com），少数只要 @ 前部分。
6. 确认端口和加密：SMTP SSL 用 465、STARTTLS 用 587、无加密用 25。
7. 如多次失败账户被锁：检查邮箱是否有安全提醒邮件，按提示解锁。
8. 测试连接：openssl s_client -connect smtp.xxx.com:465 -crlf 然后 EHLO test AUTH LOGIN 手工测试。
参考：RFC 4954 (SMTP AUTH) §4 · Gmail App Passwords · 邮件系统帮助文档
SMTP 握手时 HELO/EHLO 命令发送的主机名不合法。合法主机名必须是 FQDN（完全限定域名，如 mail.example.com），不能是：裸主机名（mail）、IP 地址、含中文/下划线/特殊字符的名字、不存在的域名。
1. Postfix：编辑 /etc/postfix/main.cf，设 myhostname = mail.yourdomain.com，重启 postfix reload。
2. Exim：设 primary_hostname = mail.yourdomain.com。
3. Sendmail：设 confDOMAIN_NAME。
4. Docker/容器环境：用 --hostname mail.yourdomain.com 启动容器，确保 MTA 的 hostname 不是随机容器 ID。
5. 客户端（Outlook/Thunderbird）：客户端本身不发送 HELO，这是发件 SMTP 服务器的配置问题——联系服务器管理员。
6. 验证：nslookup mail.yourdomain.com 必须能解析到发信 IP。
7. 用 MXToolbox SMTP Test 在线验证。
参考：RFC 5321 §4.1.1.1（EHLO 必须为 FQDN）· RFC 1035（域名规范）
发件 SMTP 服务器尝试查询收件方域名的 MX 记录（邮件交换记录），DNS 返回了 NXDOMAIN（域名不存在）或 SERVFAIL（查询失败）。SMTP 协议要求发件服务器先通过 DNS 定位收件方邮件服务器——找不到 MX 记录则回退用 A 记录，都找不到就无法投递。
1. 先确认地址没打错：gmial.com→gmail.com、qq.con→qq.com 非常常见。
2. 手工验证 DNS：命令行运行 nslookup -q=mx <收件域名>。(a) 返回 NXDOMAIN → 域名真的不存在/过期/没配 DNS → 联系收件人；(b) 返回 MX 但没 IP → MX 指向 CNAME 断了 → 对方 DNS 错误；(c) 返回正确 MX → 你的发件服务器 DNS 有问题。
3. 发件服务器 DNS 问题：Linux 编辑 /etc/resolv.conf 改用 nameserver 8.8.8.8 或 1.1.1.1；Windows ipconfig /flushdns 清除缓存。
4. Postfix 管理员：main.cf 中设 smtp_host_lookup = dns（而非 native），设 smtp_dns_resolver_options = timeout:10 避免超时假阴性。
参考：RFC 5321 §5（地址解析与 MX 查询）· RFC 1035（DNS 规范）
RFC 7208 §4.6.4 规定：SPF 每封邮件的 DNS 查询不得超过 10 次（包括 include / a / mx / ptr / exists / redirect 引发的递归查询）。超过即返回 PermError（永久错误），等同于 SPF 未通过。
典型场景：域名用了多个第三方发信服务，v=spf1 include:spf1.com include:spf2.com include:spf3.com ... ~all
每个 include 消耗 ≥1 次 DNS 查询，多层嵌套的 include（include 里又有 include）累积很容易超 10。
1. 裁剪无用 include：只保留确实在用的服务，删除已停用的
2. 合并为 IP：把低频变更的 include 手动解析为 ip4/ip6 引用
3. 展平（Flatten）：用自动化工具（如 dmarcian SPF Flattener、AutoSPF）把嵌套 include 递归展开成扁平 IP 列表
4. 子域名隔离：不同服务的发信用不同子域名，各子域名配自己的短 SPF
在线检测：mxtoolbox.com/spf.aspx 或 dmarcian.com/spf-survey/
参考：RFC 7208 §4.6.4 DNS Lookup Limits · DMARCLY Safe SPF · MxToolbox SPF Checker
DMARC 通过的前提不仅是 SPF/DKIM 各自通过，还要对齐——即 SPF 的 Return-Path 域或 DKIM 的 d= 域，必须与邮件 From 头的组织域（@ 后面的部分）一致。
SPF：Return-Path 的组织域（即 registrable domain）与 From 组织域相同即可。如 Return-Path bounce@mail.example.com 与 From user@example.com 对齐通过。
DKIM：d= 标签的组织域与 From 组织域相同即可。如 d=email.example.com 对齐 user@example.com。
SPF：Return-Path 域必须完全匹配 From 域（含子域名）。mail.example.com ≠ example.com。
DKIM：d= 域必须完全匹配 From 域。
严格模式更安全但容易误杀，建议 adkim=r; aspf=r（默认宽松），新手不要设 strict。
参考：RFC 7489 DMARC §3.1 Identifier Alignment · dmarcian DMARC Alignment 解释
Google 提供的免费域名信誉监控面板（gmail.com/postmaster），可查看你域名发给 Gmail 用户的：垃圾率（Spam Rate）、IP 信誉（IP Reputation）、域信誉（Domain Reputation）、投递错误率、加密率（TLS）、反馈循环（FBL）等。
1. 用 Google 账号登录 postmaster.google.com
2. 添加你的发信域名 → Google 会提供一条 TXT 验证记录
3. 在 DNS 中添加该 TXT 记录 → 验证通过
4. 等待数据出现（需日发送 Gmail ≥ 200 封才有统计）
Spam Rate：必须 < 0.10%（千分之一），超过 0.3% 可能被暂时限制。
IP/Domain Reputation：Bad/Low/Medium/High，Medium 及以下需排查。
FBL (Feedback Loop)：Gmail 用户点了"这是垃圾邮件"的报告率。
TLS：入站/出站加密率，应 ≥ 95%。
参考：Google Postmaster Tools 帮助中心 · Gmail Bulk Sender Guidelines
邮件从 alice@example.com → 你的服务器 → 转发到 Gmail。
Gmail 收到后检查 SPF：发信 IP 是你的服务器，但 example.com 的 SPF 记录里不一定有你的 IP → SPF fail。
SRS 把原始 Return-Path（信封发件人）重写为转发服务器自己的地址，格式：SRS0=HHH=TT=example.com=alice@yourdomain.com
这样 Gmail 检查的是 yourdomain.com 的 SPF → 通过。
回弹时 SRS 会自动还原原始发件人，退信正确路由回去。
Postfix：安装 postsrsd（github.com/roehling/postsrsd），apt install postsrsd → 配置 main.cf。
Sendmail：使用 srs-milter。
商业服务：多数企业邮箱和邮件转发平台内置 SRS。
确认生效：检查转发邮件的 Return-Path 头是否变成了 SRS0- 前缀。
参考：RFC 7208 SPF §2.2 Forwarding Problem · postsrsd 文档 · Oracle Messaging Server SRS 指南
行业最佳实践：每 6-12 个月 轮换一次 DKIM 密钥。Gmail 要求 DKIM 密钥至少 1024 位，推荐 2048 位（部分旧 DNS 解析器不支持 >2048）。
1. 新增 selector：生成新密钥对，用新 selector（如 202607 而非 default）发布 DKIM 公钥到 DNS：202607._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
2. 新旧并行签名：邮件服务器同时用旧 selector（default）和新 selector（202607）签名，持续 1-2 周
3. 确认新 selector 覆盖率：检查 DMARC 报告，确认用新 selector 签名的邮件都能正常验证通过
4. 下线旧密钥：停用旧 selector 签名，删除旧 DNS 公钥记录
按上述双密钥过渡法操作，新密钥生成时指定 2048 位：openssl genrsa -out dkim_private.pem 2048
注意：部分短域名（≤3字符的 TLD 如 .ai/.io）如果 DKIM TXT 值 >255 字符需确认 DNS 支持 RFC 6376 §3.6.2.2 分段。
参考：RFC 6376 DKIM Signatures §3.6 Key Management · RFC 8301 DKIM Algorithm Update · Google Gmail DKIM 要求
这是 Email Spoofing（邮件伪造）——发件人地址可以被任意伪造，SMTP 协议本身不验证发件人身份。黑客从历史上各种数据泄露中收集你的邮箱和密码组合，拼凑出一封看似吓人的邮件："我知道你的密码是 xxx，我黑进了你的电脑拍了你的摄像头……"实际上密码来自某次你注册过的网站被拖库，并非你的电脑被入侵。大多数情况下你不是被定向攻击，而是批量的恐吓诈骗。
1. 不要回复、不要付款——这是批量诈骗，回复只会确认你邮箱活跃。
2. 检查原始邮件头：看 Return-Path（真实发信路由）和 Authentication-Results（SPF/DKIM 验证结果），判断是否真从你域名发出。
3. 在 haveibeenpwned.com 输入你的邮箱查是否在泄露数据中。
4. 邮件中提到的密码如果确实是你用过的，立即在所有使用该密码的服务上改掉——切勿在不同网站重用密码。
5. 为邮箱开启二次验证（2FA）。
6. 域名管理员：为你的域名配置 SPF、DKIM、DMARC（p=reject）防止别人伪造你的域名发信。
参考：FBI IC3 · RFC 7208 (SPF) · haveibeenpwned.com
邮件撤回的成功率完全取决于双方使用的邮件系统。组织内部 Exchange/Microsoft 365 之间有一定撤回可能，发送到外部（Gmail/QQ/163 等）几乎无法撤回。
1. Exchange/Microsoft 365 内部撤回：打开已发送邮件 → 文件 → 信息 → 重发或撤回 → 撤回该邮件。仅当双方在同一 Exchange 组织且对方未读时生效。
2. Gmail 撤销发送：设置 → 常规 → 撤消发送，最多可设 30 秒撤销窗口。邮件一旦过了这 30 秒就无法收回。
3. 发到外部：邮件已发出 → 几乎无法撤回。如涉及机密信息泄露，应立即通知管理员和法务评估影响。
4. 预防措施：敏感邮件先写正文再填收件人；启用 Outlook 规则在每封邮件发送前延迟 1-2 分钟（在此期间可从发件箱中取消）；Gmail 开启 30 秒撤销。
参考：Microsoft Exchange Message Recall · Gmail Undo Send · NIST SP 800-177 Rev.1
新 IP（或长期未发信的冷 IP）在收件方的信誉为零。突然大量发信会触发反垃圾系统的异常流量检测，导致投递率极低甚至被封锁（RFC 7489 DMARC 和邮件系统发件人指南均强调渐进式建立信誉）。
Week 1：每天 50-100 封，仅发给活跃用户（经常打开/回复的收件人），收件人域名尽量分散
Week 2：每天 200-500 封，逐步增加新收件人
Week 3：每天 1000-2000 封，引入更多收件人域名
Week 4：每天 5000+ 封，接近目标日发量
关键原则：(1) 先把邮件发给最可能打开的用户；(2) 永远保持日增量而非跳跃；(3) 每天检查 Google Postmaster Tools 垃圾率 < 0.10%
Google Postmaster Tools：监控 IP/Domain 信誉和垃圾率
Microsoft SNDS：监控 Outlook/Hotmail 信誉数据
mail-tester.com：每 1-2 天发测试邮件看评分变化
参考：邮件系统发件人指南 · Microsoft SNDS · mail-tester.com
rua（聚合报告，RFC 7489 §7.1）：每天发一次 ZIP/XML，只有统计数据（哪个 IP 发了多少封、SPF/DKIM pass fail 各多少、最终处理结果）。不含邮件内容，不含收件人地址。
ruf（鉴证报告/失败报告，RFC 7489 §7.2）：每次 DMARC 验证失败即时发送，包含失败邮件的主题、From、SPF/DKIM 详细结果，甚至可能包含邮件头的部分原始内容。用于精确诊断为什么某封特定邮件被拒。
注意：大部分收件方不发送 ruf 报告（隐私顾虑），Google 和 Yahoo 均已停止或大幅限制 ruf 报告。
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com
ruf 建议用独立邮箱，因为报告量可能很大。
ruf 报告可能包含邮件主题、发件人、投递路径等。配置 ruf 前确认：(1) 邮箱符合 GDPR/《个人信息保护法》要求；(2) 通知员工其邮件头可能被第三方以 ruf 形式发回。
参考：RFC 7489 DMARC §7.1-7.2 · dmarcian
邮件发到邮件列表（如 Mailman、Google Groups）或经中间服务器转发后，中间服务器会修改主题加 [list] 标记、修改正文加退订链接等。这导致原始 DKIM 签名中的 body hash 不再匹配 → DKIM fail → DMARC fail → 邮件被拒或进垃圾箱（RFC 8617 §1）。
ARC（RFC 8617）在邮件头中插入 ARC-Authentication-Results、ARC-Message-Signature、ARC-Seal 三条链，记录原始 SPF/DKIM/DMARC 验证结果，并用中间服务器自己的 DKIM 签名覆盖验证。收件方可以沿 ARC 链回溯原始验证状态，判断中间服务器是否可信。
作为发件方：(1) 对邮件列表场景使用温和 DMARC 策略（p=none 或 p=quarantine 而非 p=reject）；(2) 对于已知的重要邮件列表，请求管理员启用 ARC 签名（主流的如 Google Groups、Mailchimp 已支持）；(3) 作为收件方管理员：在 MTA 中启用 ARC 验证（Postfix+OpenARC、rspamd ARC 模块）。
参考：RFC 8617 ARC · OpenARC · Google Groups ARC 支持
不自动继承。每个子域名的 SPF 是独立的。如果主域 example.com 有 SPF，但 mail.example.com 没有，则 email@mail.example.com 发信时 SPF 查询返回 none（等同于不设 SPF）。必须为每个实际发信的子域名单独添加 SPF TXT 记录。通常做法：子域 SPF 指向主域 SPF：v=spf1 include:example.com ~all
部分继承。DKIM d= 标签可指向组织域（如 d=example.com），子域名发信时引用主域 DKIM 签名即可。但如果 DKIM d=mail.example.com，必须为子域单独发布 selector._domainkey.mail.example.com 公钥。
自动继承。如果子域没有 DMARC 记录，收件方会查父域的 DMARC 记录——"Tree Walking"（RFC 7489 §6.6.3）。要精确控制子域行为，建议每个子域单独发布 DMARC，通过 sp= 标签指定子域策略：_dmarc.example.com TXT "v=DMARC1; p=reject; sp=quarantine; ..."
sp=none/reject/quarantine 仅对子域生效，不影响主域。
参考：RFC 7489 DMARC §6.6.3 · RFC 7208 SPF · dmarcian
旧私钥不可恢复 → 旧 DKIM 公钥仍存在 DNS 中 → 当前发出的邮件用旧公钥验证会失败（没私钥签名）→ DKIM fail。必须立即生成新密钥以恢复签名。
1. 生成新密钥对：openssl genrsa -out dkim_new_private.pem 2048 + openssl rsa -in dkim_new_private.pem -pubout -outform PEM
2. 用新 selector 发布：选择从未用过的 selector 名（如 202607），在 DNS 发布新公钥：202607._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
3. 配置邮件服务器用新 selector 签名：在 Postfix/昆仑邮件系统中配置新私钥路径和 selector
4. 保持旧 DNS 记录 48 小时：等缓存中的旧签名邮件全部被投递完毕后，再删除旧的 default._domainkey DNS 记录
5. 验证：用 mail-tester.com 发测试邮件确认新 selector DKIM-pass
如果之前是 1024 位密钥，这是升级到 2048 位的好时机。推荐新 selector 双轨过渡而非直接覆盖旧公钥。
参考：RFC 6376 DKIM Signatures §3.6.2 · RFC 8301 DKIM Algorithm Update · OpenDKIM 文档
Google Postmaster Tools（GPT）是 Google 免费提供的邮件发件人数据平台，显示你的域名/IP 在 Gmail 系统中的送达表现——包括 合规状态（SPF/DKIM/DMARC/PTR/TLS 是否通过）、用户垃圾投诉率（接收者标记为垃圾邮件的比例）、认证状态、投递错误 等。它不是黑名单，是你的域名在 Gmail 生态的「体检报告」。2025 年 10 月后 Google 淘汰了 v1 界面和「IP 信誉」「域名信誉」仪表板，v2 界面聚焦于 合规状态仪表板（六大项：SPF 认证、DKIM 认证、DMARC 对齐、PTR 正向/反向 DNS、TLS 加密、一键退订）和 垃圾率仪表板（用户举报垃圾邮件的实时百分比）。
Step 1：添加域名
访问 postmaster.google.com → 用 Gmail 账号登录 → 左下角「+」添加域名。
Step 2：验证域名所有权
GPT 会生成一条 TXT 验证记录，添加到域名的 DNS 中：
主机记录：@ 或留空（取决于 DNS 服务商）
记录值：google-site-verification=...（一串随机字符串）
添加后点击「验证」→ 通常几分钟内生效。
Step 3：等待数据积累
验证通过后，GPT 需要 至少发送数百封邮件到 Gmail 用户 才开始显示数据。常规流量域名通常 1-3 天后数据开始出现。低流量域名（每天 <100 封到 Gmail）可能始终显示「没有数据」。
合规状态仪表板——你的技术清单：
该仪表板列出 SPF、DKIM、DMARC、PTR、TLS 加密、一键退订六项是否「通过」（绿色）或「失败」（红色）。任何一项红色 = 你的域名未满足 Gmail 2024 年起的最低发件人要求，可能导致拒收或垃圾箱。Gmail 从 2025 年 11 月起对不合规域名执行 5xx 级拒收。
垃圾率仪表板——你的用户行为红线：
Google 要求垃圾投诉率 始终低于 0.3%（即每 1000 封进收件箱的邮件≤3 封被标记为垃圾）。计算公式：(用户标记为垃圾的邮件数 ÷ 进入收件箱的邮件数) × 100。
注意：如果邮件未进收件箱（直接被拒收），不会被计入分母。因此垃圾率仪表板可能低估真实投诉比例。
垃圾率 >0.3% 时：立即停止发送非必要邮件，检查近期邮件内容是否触发垃圾关键词（促销、免费、立即点击等），确认退订链接醒目且有效——用户找不到退订按钮 = 最高频的垃圾投诉原因。
GPT 有两个重要盲区：(1) 只报告用户手工点击「报告垃圾」的数据，不显示 Gmail 自动将邮件归类到垃圾箱的过滤决策——邮件被 Gmail AI 判定为垃圾但没有用户举报的话，GPT 不会反映；(2) 只覆盖 Google 邮箱用户，不适用于 Outlook/Yahoo/企业邮箱等其他收件方。因此 GPT 应配合第三方收件箱监控工具（如 GlockApps、MXToolbox Deliverability Monitor）使用，才能全面了解送达率。
参考：Google Postmaster Tools 官方帮助 · Google Email Sender Guidelines（2024 年更新）· RFC 7489
Spamhaus 维护三个主要 DNSBL 列表，全部整合在 ZEN（综合 DNSBL） 中：
• SBL（Spamhaus Block List）：手动列入的已知垃圾邮件发件源、僵尸网络 C&C——很少误判，列入说明你的 IP 确实在发送垃圾邮件或被入侵。
• XBL（Exploits Block List）：自动检测的恶意软件、被入侵设备、开放代理——实时动态更新。
• PBL（Policy Block List）：不是 被作为垃圾源列入的——这个是「策略阻止列表」，列入的是 ISP 主动声明「这些 IP 不应该直接对外发信」的地址段，如住宅宽带 DHCP 池、云服务商未申请解封的网段。
关键区别：SBL 列入 = 你的 IP 有罪，需要调查、清除、申诉。PBL 列入 = 你的 IP 可能只是在一个策略阻止范围内，但你不是垃圾发件人——只需自助移除即可。
Step 1：查 IP 是否在 PBL
打开 spamhaus.org/query/ip/你的IP地址，查看返回结果。如果显示 is listed in the PBL，继续下一步。
Step 2：点击页面中的 PBL 条目编号
常见格式：PBL123456 或 PBL IP Address Lookup。
Step 3：点击 Remove an IP from PBL
进入移除页面后填写：
• IP 地址（要移除的 IP）
• 联系邮箱（接收验证邮件）
• 所属国家
• IP 类型：选 Static（静态 IP）——云服务器的公网 IP 几乎都是静态的
• 移除原因：说明这是固定 IP 的邮件服务器，需要对外发信（英文："This is a static IP address on a VPS/mail server. It needs to send mail directly to external domains."）
• 如果页面要求域名：填写你的邮件服务器主机名/域名
Step 4：验证邮箱
提交后 Spamhaus 会发送验证邮件到填写的邮箱 → 点击邮件中的验证链接 → 页面自动跳转确认移除。
Step 5：等待生效
移除请求处理后，PBL 中通常在 几分钟到 1 小时 内清除。使用 MXToolbox Blacklist Check 或 mxtoolbox.com 确认。
会。如果 IP 在 ISP 的 PBL 策略网段中（如阿里云/腾讯云/华为云默认的所有 VPS 网段都在一些 ISP 的 PBL 中），PBL 移除只是暂时的。建议：(1) 如果发信 IP 仍在 PBL 策略网段中，可能需要每几个月重新移除；(2) 确认 IP 不是动态 DHCP 池中的——Spamhaus 会定期扫描并重新列入动态地址；(3) 长期方案：考虑使用固定 IP 的中继服务（SMTP relay service）。
参考：Spamhaus Blocklist Removal Center · spamhaus.org/pbl · RFC 5782（DNSBL 实践建议）
收件方 MTA 建立 SMTP 连接时的三步验证：(1) 你的 IP 连接过来 → 查 PTR 记录（反向 DNS）→ 得到主机名（如 mail.yourdomain.com）；(2) 正向查该主机名的 A 记录 → 确认指向你的 IP（正反向 DNS 闭环）；(3) 你的 SMTP 服务器在 220 响应的 Banner 中自报的主机名也要与 PTR 解析出的主机名一致。这三步任一不一致，都可能被判定为「你的 IP 是谁都说不清楚，可能是垃圾邮件发件源」。
MXToolbox 的 SMTP Test 显示 Reverse DNS does not match SMTP Banner 就是第三步——你的 SMTP 服务器说的主机名跟 PTR 记录指向的域名不一致。
Step 1：检查当前 PTR 记录nslookup 你的发信IP → 记下返回的域名（如 mail.hostprovider.com）。
Step 2：检查当前 SMTP Bannertelnet 你的发信主机名 25 或 openssl s_client -connect 你的主机:25 -starttls smtp → 看 220 后面跟的主机名（如 220 mail.yourdomain.com ESMTP Postfix）→ 记下来。
Step 3：对齐两种方案
方案 A（推荐）：修改 SMTP Banner 主机名以匹配 PTR → Postfix：/etc/postfix/main.cf 中设 myhostname = 与PTR一致的域名 → systemctl reload postfix。
方案 B：修改 PTR 以匹配 Banner → 联系云服务商/ISP 将 IP 的 PTR 改为你的 SMTP Banner 主机名。
Step 4：验证对齐
去 MXToolbox → SMTP Test → 输入你的发信域名 → 看 SMTP Banner Check 和 Reverse DNS 项都显示绿色 √。
/etc/postfix/main.cf：myhostname = mail.yourdomain.com ← 这个值会在 Banner 中显示mydomain = yourdomain.comsmtpd_banner = \$myhostname ESMTP ← 使用系统主机名作为 Banner
验证：postconf -n | grep -E "myhostname|smtpd_banner"。Exim：primary_hostname = mail.yourdomain.com。
注意：有些反垃圾系统还会检查 Banner 中的主机名和 HELO/EHLO 是否一致——如果邮件客户端用 EHLO laptop.local，Fix 方法见 FAQ 第78题（HELO/EHLO 主机名不匹配）。
参考：RFC 5321 §4.3.1（SMTP 验证序列）· RFC 1912 §2.1（PTR 最佳实践）· Postfix smtpd_banner 文档
收件方邮箱存储空间已满，无法接收新邮件。SMTP 会话中 RCPT TO 阶段通过，但邮件最终投递到收件箱时 MTA 发现邮箱配额耗尽 → 生成退信。退信代码体系：552 = 邮件数据太大或存储满了（RFC 5321 §4.2.5），5.2.2 = 持久性失败·邮箱问题·超出配额（RFC 3463）。Microsoft Exchange 中 STOREDRV.Deliver.Exception:QuotaExceededException.MapiExceptionQuotaExceeded 是该错误的内部表述。
默认不能。SMTP 协议不支持发件方「强制投递」到已满邮箱——这是防滥用的设计。如果收件方 MTA 开启了邮箱溢出自动清理或临时超配额允许，邮件可能会等待：一些 MTA 在退信前尝试 72 小时（由 maximal_queue_lifetime 决定）内重试。如果这期间收件方清理了空间 → 邮件正常投递。
但大多数现代 MTA（Gmail、Exchange Online、outlook.com）对 quota-exceeded 直接生成 NDR（Non-Delivery Report），不重试。
1. 告知收件人：通过其他渠道（微信/电话/文字消息）通知对方邮箱已满，请对方清理空间后你重新发送。
2. 重新发送不要立即：邮件已满的邮箱清理空间后立即收到大量旧退信的重试——可能会再次填满。建议等 1-2 小时后重新发送。
3. 附件很大的话：邮件附件通常占空间大。考虑改用文件分享链接（如微云/OneDrive/Google Drive）替代附件，发送纯文本链接。
4. 如果对方是企业客户：提醒对方 IT 管理员提高邮箱配额——Exchange Online 默认邮箱大小为 50GB/100GB（视许可证），满到这个程度说明邮件量异常大或配额设置不当。
参考：RFC 5321 §4.2.5（552 响应码）· RFC 3463（增强状态码）· Microsoft Learn: NDR error 554 5.2.2 mailbox full
Google 从 2024 年 2 月起实施更严格的大规模邮件发送者要求。核心红线：向 Gmail 用户发送的任何邮件，用户垃圾投诉率必须始终低于 0.3%（即每 1000 封进收件箱的邮件≤3 个投诉）。
不同投诉率后果：
• ≤0.1%：正常——绝大多数合规发件人低于此线。
• 0.1%-0.3%：黄色警告区间——Gmail 不会主动拒收但可能增加垃圾箱投递比例。
• >0.3%：红色——可能触发全部邮件进垃圾箱或直接拒收。
• >0.5% 并持续：域名/IP 可能被 Gmail 降级——影响所有邮件投递质量。
按频率排序：
1. 退订链接不易找到——用户在邮件底部找不到退订按钮 → 退订无门 → 点击「报告垃圾邮件」→ 退订链接必须位于邮件底部、文字醒目（不能是灰色小字）、直接跳转退订页面（不要跳首页）。
2. 发错了——用户没注册/没同意接收——你的邮件列表没有验证 opt-in 状态。任何购买的邮件列表 100% 会产生高投诉率。
3. 内容与用户预期不符——用户注册的是「每月产品更新」，你发的是「每日促销」→ 心理预期落差 → 投诉。
4. 发信频率过高——每天多发 ≠ 效果好。每周 1-2 封营销邮件是大多数行业的最佳频率。
1. 确认退订链路完整体验：用自己的 Gmail 账号订阅你的邮件列表 → 找退订按钮 → 点退订 → 确认不再收到邮件 → 全过程 ≤30 秒 → 才算合格。
2. 支持一键退订：在邮件头中加 List-Unsubscribe 和 List-Unsubscribe-Post 头（RFC 8058）→ Gmail 会在界面顶部显示一个「退订」按钮。
3. 未互动的用户做日落策略：超过 6 个月没打开/点击任何邮件的用户 → 先发「确认继续接收」邮件 → 未确认的 → 从发送列表清除。不互动的用户是最可能投诉的。
4. 设置发件人地址识别：用户能一眼认出谁发来的邮件——发件人显示名要稳定，不能今天叫「系统通知」明天叫「客服团队」。
5. Google Postmaster Tools 监控：至少每周检查一次 GPT 的垃圾率仪表板，发现上升趋势立即切消费确认邮件。
参考：Google Email Sender Guidelines（2024 年更新）· RFC 8058（List-Unsubscribe）· Google Postmaster Tools v2 · Mailgun: How to Keep Your Spam Complaint Rate Low