认证与内容

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. 提醒：你调大了自己服务器限制，但收件方服务器的限制你改不了——超大邮件到对方照样被拒。

收件方反垃圾系统拒绝接收。常见触发：主题含促销敏感词、正文全图片/文字极少、发件 IP 信誉低或被列入公共黑名单。

1. 修改主题去掉夸张营销词汇。
2. 正文确保有足够文字（建议 ≥100 字），不要只发一张图片。
3. 正常内容仍被拦：请收件人将你的发件地址加入白名单后重试。
4. 多人报告同类问题：在 MXToolbox 查询发件 IP 是否在黑名单中。

收件方管理员设置了自定义安全策略，明确拒绝你的发件地址或域名。这和你 SPF/DKIM 配置无关——验证通过不代表对方一定接收。

1. 通过其他渠道联系收件人，请其通知邮箱管理员将你的发件地址或域名移出拒绝列表。
2. 对方用 Google Workspace：管理员 → 应用 → Gmail → 高级设置 → 被拒绝的发件人列表中添加白名单。
3. 对方用 Microsoft 365：管理员在 Exchange 管理中心 → 邮件流 → 规则中查找针对你发件域的拦截规则。

Gmail 禁止接收可执行文件类型（.exe、.bat、.scr、.vbs、.msi 等）和部分脚本文件。即使打包在 .zip 中也会被扫描拦截。

1. 将文件打包为 .rar 或 .7z 格式（Gmail 不扫描这两种压缩包内部）。
2. 用 WinRAR / 7-Zip 对压缩包设置密码保护后发送。
3. 最稳妥：上传至云盘后分享链接代替附件。

发件人用 Outlook 以"RTF 格式"发送，RTF 将附件打包为微软私有的 TNEF 格式 winmail.dat。非 Outlook 客户端无法解析该格式。

1. 发件人：新建邮件 → "设置文本格式" → 改为 HTML 或 纯文本 后重新发送。
2. 一次性修复：文件 → 选项 → 邮件 → "以该格式撰写邮件"下拉选 HTML。
3. 已收到且不想麻烦对方重发：用在线 TNEF 解码工具提取附件。

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 生效后重新测试。

发件客户端使用的字符编码与收件人不兼容。常见场景：(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'。

主流邮箱的反垃圾系统有"学习"机制：收件人手动标记垃圾会训练个性化过滤器，后续来自同一发件地址的邮件可能自动归入垃圾箱。

1. 请收件人在垃圾箱中找到你的最新一封邮件，点击"这不是垃圾邮件"或"移动到收件箱"。
2. 同时请收件人将你的发件地址加入通讯录/联系人。
3. 注意：已在垃圾箱中的旧邮件不会自动移回，需逐个手动操作。
4. Gmail 用户：还可创建过滤器 → 发件人=你的地址 → "永不将其发送至垃圾邮件"。

邮件转发会破坏原发件域的 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（仅报告不拦截），但这会降低域名安全性。

最常见原因：(1) 图片是网络链接（URL 引用）而非嵌入到邮件中，常见邮箱默认阻止外部图片；(2) 图片托管服务器不可访问或链接已过期；(3) Outlook 自身的 CID 图片引用 bug（微软2026年5月确认的已知问题）。

1. 发件人侧：在邮件中直接粘贴图片（Ctrl+V）而非插入图片链接。嵌入到邮件中的图片不会被阻止。
2. 如必须使用链接：确认图片 URL 可公网访问且未过期。
3. 收件人侧：右键图片位置 → 下载图片；或在 Outlook 信任中心中允许自动下载图片。
4. Outlook 图片红叉 bug：检查图片的 cid 内容 ID 是否异常，微软已发布补丁，更新 Office 到最新版本。

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 渐进式部署。