退信诊断与修复（续）

550 5.7.1 "Unable to relay" 表示 SMTP 服务器拒绝了中继请求——发信连接未通过认证，服务器认为发件人在试图利用它转发外部邮件。触发场景：客户端未启用 SMTP AUTH 认证、IP 不在中继白名单内、发件域与服务器管辖域不匹配。注意这属于配置问题而非内容拦截，确定可修复。

1. 确认 SMTP 认证已启用：邮件客户端（Outlook/Foxmail/Thunderbird）账户设置 → 发送服务器 → 勾选"服务器需要身份验证"，选择"使用与接收服务器相同设置"。
2. 验证 AUTH LOGIN/PLAIN 是否通过：
openssl s_client -connect smtp.yourdomain.com:587 -starttls smtp
EHLO test
AUTH LOGIN → 输入 Base64 编码的用户名和密码 → 应返回 235 2.7.0 Authentication successful
3. 检查 mynetworks 配置：Postfix 中 postconf mynetworks 确认本地子网在列表中。昆仑邮件系统管理后台 → 安全设置 → 中继白名单。
4. 确认不是 open relay：在 MXToolbox SMTP Test 中检查，不应允许未经认证的外部中继。
5. 代码发信：PHPMailer/Python smtplib 中确保调用了 smtp.login(user, password) 而非直接 sendmail。

5.1.1 错误码表示收件方邮件系统确认该邮箱地址不存在（RFC 5321 §4.2.1）。收件方 MTA 在 RCPT TO 阶段查询本地用户数据库未匹配到该地址，返回永久拒绝。常见原因：拼写错误（gmail.com 打成 gmial.com）、邮箱已停用或注销、企业内部邮箱已离职未保留别名。这是最终投递失败，需人工确认而非等待重试。

1. 验证收件地址拼写：仔细核对用户名和域名，常见笔误如 gmail→gmial、hotmail→hotmail.com 少写字母。
2. telnet 手工测试：
nslookup -type=mx recipient-domain.com
telnet mx-server 25
HELO test
MAIL FROM:<you@yourdomain.com>
RCPT TO:<suspect@recipient-domain.com> → 观察返回码
3. 确认该邮箱在服务器上有定义：对方 IT 管理员检查邮件系统中是否存在该邮箱对象，是否被禁用或删除。
4. 检查收件域 MX 记录：dig MX recipient-domain.com → 确认 MX 记录存在且解析正确。

SPF/DKIM/DMARC 三项认证全部通过不代表邮件一定进收件箱。邮件系统的垃圾邮件判定使用机器学习模型，综合考虑认证状态、内容质量、发送行为、用户互动率等多维信号。认证全绿只是入场券——还需要内容质量和发送行为过关。Gmail 2024 年起对批量发件人强制要求一键退订（RFC 8058），缺失也会影响投递质量。

1. 检查邮件内容：避免纯图片无文字、避免短链接（bit.ly/t.cn 等）、去除夸张营销词汇（"免费""限时""立即点击"）、正文文字 ≥100 字。
2. Google Postmaster Tools 查数据：登录 postmaster.google.com 查看域名垃圾率（必须 <0.3%，建议 <0.1%）和合规状态仪表板——SPF/DKIM/DMARC/PTR/TLS/一键退订六项是否全部绿色。
3. 分析 DMARC rua 报告：用 dmarcian/URIports 等解析收件 DMARC 聚合 XML 报告，看是否存在 SPF/DKIM fail 的次要发信源。
4. 验证 rDNS（PTR）：发信 IP 必须有 PTR 且正反向解析一致：nslookup 发信IP → 得到域名 → nslookup 域名 → 返回同一 IP。
5. 检查 IP 声誉：MXToolbox Blacklist Check 确认不在任何公共黑名单；Spamhaus ZEN 查询 IP 是否在 PBL/SBL/XBL。

550 5.7.26 是收件方（如 Gmail）执行 DMARC p=reject 策略后的明确拒收信号：发件域名配置了 DMARC reject 但实际发出的邮件未能通过 DMARC 对齐验证——SPF 和 DKIM 均未 pass 或未与 From 域对齐。RFC 7489 §6.6.1 规定接收方在 p=reject 时必须拒收未通过验证的邮件。Gmail 自 2024 年起要求所有批量发件人必须通过 DMARC 验证。

1. 检查发件域 DMARC 记录：nslookup -type=txt _dmarc.yourdomain.com → 看 p= 是 reject/quarantine/none。如果 p=reject 且非本意，临时改为 p=quarantine。
2. 确认 SPF 配置正确且对齐：发件 IP 必须在 SPF 允许列表中；Return-Path 域必须与 From 组织域一致（DMARC 宽松对齐）。
3. 确认 DKIM 签名正确且对齐：用 mail-tester.com 发测试邮件检查 DKIM 是否 pass；d= 域（DKIM 签名域）与 From 组织域一致。
4. 用 DMARC 检测工具验证：dmarcian DMARC Inspector 或 MXToolbox DMARC Check 检查整体配置。
5. 多平台多渠道发信：CRM/工单系统/营销平台的 From 域都必须单独纳入 SPF/DKIM 覆盖。

IMAP 迁移是从旧邮件系统（如 Exchange/Microsoft 365）将邮件搬家到昆仑邮件系统时，源服务器 IMAP 认证失败。常见原因：源服务器未启用 IMAP、账号密码错误、TLS/SSL 端口配置不对、启用了双因素认证但未使用应用密码、源服务器有 IP 访问限制。

1. 确认源服务器 IMAP 已启用：邮件系统管理后台 → 用户 → 邮箱设置 → 勾选"启用 IMAP"。Exchange Online：Exchange 管理中心 → 收件人 → 邮箱 → 邮箱功能 → 启用 IMAP。
2. 验证账号密码：使用同一账号密码在 Outlook/网页邮箱中登录确认无误。
3. 检查 TLS/SSL 端口：IMAP SSL 端口 993，STARTTLS 端口 143。昆仑邮件系统搬家工具中填写正确端口和加密方式。
4. 确认未启用双因素认证：如源邮箱开了两步验证，需生成应用专用密码（邮件系统：设置 → 应用密码；Microsoft 365：安全信息 → 应用密码）。
5. openssl 测试连接：
openssl s_client -connect imap.source.com:993 -crlf
a1 LOGIN user@domain.com password → 应返回 a1 OK LOGIN completed

SMTP 发送时，发件或收件 MTA 尝试 TLS 握手，但证书已过期或被吊销，导致 certificate verify failed 错误。SMTP STARTTLS（RFC 3207）依赖 X.509 证书链来建立加密通道——任何一端证书过期都会导致连接中断。Let's Encrypt 证书有效期仅 90 天，遗忘续签是该问题的最常见原因。

1. 检查证书到期时间：
openssl s_client -connect mail.yourdomain.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -dates → 看 notAfter 日期
2. 续签证书（Let's Encrypt）：
certbot renew --force-renewal
或指定域名：certbot certonly --standalone -d mail.yourdomain.com
3. 重启 MTA：
systemctl restart postfix（Postfix）/ systemctl restart dovecot（Dovecot）
昆仑邮件系统管理后台 → 系统 → 服务管理 → 重启邮件服务
4. 配置自动续签 cron：
0 3 * * * certbot renew --quiet --post-hook "systemctl restart postfix dovecot"

554 5.4.14 表示邮件在投递路径上经历了过多的 MTA 跳转（hop），超过了收件方服务器设定的最大跳数限制。RFC 5321 §4.3.7 规定每经过一个 MTA 需在邮件头中添加 Received 行——如果邮件在两个或多个 MTA 之间形成路由循环（loop），Received 行数量会累积到触发阈值。常见触发：DNS MX 记录形成循环指向、邮件转发规则自引用、DNS CNAME 链有环。

1. 检查 MX 记录指向：dig MX yourdomain.com → 确认 MX 优先级最高那条指向的服务器确实能收信，且不存在 A→B→A 的指向循环。
2. 检查邮件转发规则：Postfix 中 postconf virtual_alias_domains、postmap -q user@domain /etc/postfix/virtual 查询是否自引用。昆仑邮件系统管理后台 → 邮件流 → 转发规则。
3. 确认 DNS CNAME 没有循环：MX 记录指向的主机名不应是 CNAME（RFC 2181 §10.3），更不应形成 CNAME 链循环。
4. 查看退信邮件头 Received 链：从下往上逐跳读 Received 头，看是否有重复的 MTA 主机名出现——重复出现 = 循环。找出循环的起点和终点。

MTA-STS（RFC 8461）配置后仍有邮件走明文 SMTP，说明策略未完全生效。常见原因：DNS TXT 记录格式错误、策略文件 HTTPS 不可达或证书无效、mode 仍为 testing 而非 enforce、发件方 MTA 不支持或不查询 MTA-STS 策略、DNS 缓存未过期导致旧策略仍在生效。

1. 验证 MTA-STS DNS TXT 记录：
dig TXT _mta-sts.yourdomain.com → 应返回 v=STSv1; id=20260715083000，id 是递增时间戳。
2. 检查 well-known 策略文件：
curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt → 确认 HTTPS 证书有效、文件状态码 200、内容格式正确。
3. 确认 mode 为 enforce：策略文件中 mode: enforce 而非 mode: testing。testing 模式仅报告不强制。
4. 检查 TLS-RPT 报告：_smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com" → 分析收到的 JSON 报告看哪些发件方未走 TLS。
5. 验证发件方是否支持 MTA-STS：Gmail/Outlook 等主流服务均支持，部分小型或自建 MTA 可能不支持。

BIMI（Brand Indicators for Message Identification，RFC 8686）让支持该标准的邮箱在收件箱中显示品牌 Logo。仅配置 BIMI DNS 记录不足以保证 Logo 显示——需要满足一系列前置条件：DMARC 策略为 p=quarantine 或 p=reject、Logo 文件为合规的 SVG Tiny PS 格式、BIMI TXT 记录格式正确、部分邮箱还需 VMC（Verified Mark Certificate）证书。

1. 确认 DMARC 策略：dig TXT _dmarc.yourdomain.com → p=quarantine 或 p=reject（p=none 不满足 BIMI 最低要求）。
2. 验证 BIMI TXT 记录格式：
dig TXT default._bimi.yourdomain.com → 应返回类似：
v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem
其中 l= 为 Logo URL，a= 为 VMC 证书 URL（可选但推荐）。
3. Logo 格式要求：必须是 SVG Tiny 1.2（SVG P/S）格式，尺寸为正方形（宽高比 1:1），文件托管在 HTTPS 服务器。
4. VMC 证书：Yahoo/Apple Mail 要求 VMC，成本数百美元/年。Gmail 目前不强制要求 VMC。
5. 用 BIMI Inspector 验证：bimigroup.org 的 BIMI Inspector 工具完整检测配置。

邮件发送量或发送速率超过了邮件服务商设定的阈值，触发自动限流。各服务商有每日总量限制和速率限制。RFC 5321 §4.5.3.2 建议 MTA 应实现速率控制以避免被误判为垃圾邮件源。短期超额返回 4xx 临时拒绝可自动重试，持续超额可能被升级为 5xx 永久封禁。

1. 立即停止发信：暂停所有新的发信请求，让现有队列自然消化。
2. 联系邮件系统管理员解封：昆仑邮件系统管理后台 → 安全中心 → 发送限制 → 查看当前 IP/账号封禁状态 → 申请临时解封或提高限额。
3. 配置发信限速：Postfix：
smtp_destination_rate_delay = 1s
default_destination_concurrency_limit = 3
4. 使用邮件队列分摊：将大批量邮件分发到多个发信时间窗口（如每小时 500 封），而非一次性提交全部。
5. 多 IP 轮换：为不同域或不同类型邮件使用独立发信 IP，分摊信誉和速率压力。
6. 预热新 IP：日发量 50→125→310→775 逐步递增，每日增量不超过 25%。

4.4.7 是 临时错误（4xx），不是硬退信。含义：发件 MTA 已多次尝试投递但暂时无法连接到收件方服务器——可能对端宕机、网络不通、DNS 临时无法解析。发件 MTA 会按照预设的重试策略自动重试。4xx 错误不会生成最终 NDR（退信通知），只有重试全部耗尽后才升级为 5xx 硬退信。

1. 默认重试策略：Postfix 默认 maximal_queue_lifetime = 5d（5 天后才退信）。Exchange Online 默认 2 天（48 小时）。昆仑邮件系统默认 3 天。
2. 检查对端 MX 可达性：telnet 对端MX地址 25 看是否超时或拒绝。
3. 检查对端是否启用 greylisting：首次投递返回 4.4.7 是 greylisting（RFC 6647）的典型特征，会自动在几分钟到一小时内重试成功——不需要干预。
4. DNS 查询验证：dig MX recipient-domain.com +short 确认对端 MX 记录正常。
5. 预期时间线：典型场景下 48 小时到 5 天后仍未送达 → 发件 MTA 生成 5.x.x 硬退信。

迁移到信创邮件系统（如昆仑邮件系统信创版）后，Outlook/Foxmail 等传统邮件客户端无法收信。信创环境（国产 CPU + 国产 OS + 国产数据库 + 国产中间件）有独特的连接要求：部分信创邮件系统使用 xcpop/xcimap 协议而非标准 POP3/IMAP、TLS 版本兼容性要求较严、需使用客户端授权码而非登录密码。

1. 确认客户端协议已开启：昆仑邮件系统管理后台 → 用户管理 → 编辑用户 → 客户端设置 → 勾选"POP3 服务"和/或"IMAP 服务" → 保存。
2. 验证 SSL 端口：POP3 SSL 端口 995，IMAP SSL 端口 993。用 telnet/openssl 测试：
openssl s_client -connect mail.server.com:993 -crlf
3. 信创环境特有：确认协议类型：部分信创邮件系统使用 xcpop（信创 POP3）和 xcimap（信创 IMAP）作为服务器地址前缀，而非标准 mail.domain.com。查看昆仑邮件系统管理后台 → 系统信息 → 客户端配置指南。
4. 检查 TLS 版本兼容：信创 OS 可能默认禁用 TLS 1.0/1.1，仅支持 TLS 1.2+。客户端中收信服务器加密方式设为 SSL/TLS（而非 STARTTLS）。
5. 获取客户端授权码：昆仑邮件系统管理后台 → 用户管理 → 客户端授权码 → 生成一组独立密码，在 Foxmail/Outlook 中使用授权码替代网页登录密码。