黑名单与信誉

大型邮箱对新出现的发信 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. 邮件内容确保有文字、无可执行附件、不是纯图片。

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。

邮件投递链路长（发件客户端→发件SMTP→可能中转→收件MX→收件反垃圾→收件箱），任何一个环节都可能出问题。服务商说"没问题"通常只看自己的发件队列没有堆积，不保证送达。

1. 看发件日志：邮件状态是 Sent（已发出）、Deferred（排队等重试）、Bounced（退回）？Deferred 超过 4 小时=大概率最终进垃圾箱或硬退。
2. telnet 手工投递：nslookup -q=mx <收件域名> 找到 MX 记录 → telnet 25 → 手工 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，看实际送达率/垃圾邮件率——而不是"我觉得被拦了"。

这和 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 端口可达。

无退信≠送达。静默丢失常见 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. 叫收件人去垃圾箱找：如果上面三步都没有异常→叫收件人搜你的发件地址/主题词 翻垃圾箱。

552 5.2.2：永久错误，立即通知发件人收到 NDR 退信。
452 4.2.2：临时错误，服务器队列重试（最多 5 天数十次），不立即通知。

发件方 552 需立即通知收件人。452 不急但提醒。收件方清理邮件或扩容。自建服务器：postqueue -p 或 doveadm quota get。预防：配额告警 80% 提醒，95% 紧急。

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 小时生效。解除后查找并修复被列的根本原因，否则会被再次列入。

微软将你的发信 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 配置正确，否则解封后可能再次被列。