附件发不出去：先分清是编码后超限还是对方拒收

一封标着 10 MB 的邮件，走出网关的时候已经不是 10 MB 了。邮件协议只认纯文本，二进制附件必须先做一次编码，体积按 4/3 放大，10 MB 变成约 13.3 MB。很多人卡在这一步：文件本身没超，编码之后超了。

站上 退信与报错码对照 那篇把 550、554、451 这整套码过了一遍，552 只占一行。本篇不再重复那张总表，只算体积这笔账：为什么看着没超、到底卡在哪一段、三条绕路各自要付什么代价。

先说一个判断，能省掉一半无用功——先看退信是谁发的，再决定要不要压缩附件。如果退信来自对方，压得再小也可能没用；如果压根没收到退信，那问题不在体积。

先换算：编码之后，体积涨三成

编码方式叫 Base64。它把每 3 个字节的数据拆成 4 个可打印字符，所以体积固定变成原来的 4/3。附件的原始大小和出门时的大小，是两个数。下面这张表以 20 MB 的上限为例，只用来对比换算关系，实际上限以服务商后台公示为准。

这张表解释了一个反复出现的困惑：网盘显示文件 15 MB，后台写着单个附件上限 20 MB，按理说该过，结果还是退。因为 15 MB 过一遍编码就是 20 MB，再加上邮件头、正文、签名图，实际已经越过上限。

把上限乘 0.75 当经验值用，大致够。但还有一层：一封邮件里通常不止一个附件，上限管的是整封信，不是单个文件。

限制不止一处，先看是谁拒的

同一封信要过大大小小好几个关卡，每一关的上限由不同的人设，改法完全不同。判断依据是退信里的 Reporting-MTA 那一行，它写着拒收方的域名。

第二行和第四行的区别值得记住。都是"发不出去"，但一个是你的信太大，一个是对方的箱子满了。看清这一点，才不会在半夜压缩一堆本来没问题的附件。

552 只是一个数，真正的信息在增强状态码里

在邮件协议的标准定义里，552 的原意是"存储分配超出"，落到各家实现上，既可能指体积超限，也可能指配额不足。所以要往后看三位增强码。

5.2.3：邮件长度超过管理方设定的上限。这是最典型的体积问题，减小附件就有效。

5.3.4：邮件对接收系统来说太大。多见于把信转进另一个邮件系统的场景，比如企业内部还有一套老系统，两边上限不一致。这种要改的是中间那一跳，不是发件人这边。

4.2.2：收件人邮箱超出配额。跟你的附件一点关系没有，对方清理完空间，重发就能过。

再补一条容易搞错的：4xx 是临时失败，5xx 是永久失败。452 属于前者，对方恢复后系统会自己重投；552 属于后者，重发一百次结果一样。看到 5xx 还在反复点重发，是把时间花在没有出口的地方。

四种"看起来没超"的情况

第一，多个附件加起来。上限写的是整封信的体积。三个 8 MB 的文件，单个都没超，合起来 24 MB，编码后 32 MB，必退。发之前把附件总大小加一遍，比看单个文件靠谱。

第二，粘贴进正文的截图。截图不是"文字"，它走的是内嵌附件，同样计入体积。一封正文只有一句话、带三张流程图的邮件，可能就是 4 MB。做方案汇报的人最容易在这里踩坑，一页一张图，二十页就是二十张。

第三，签名档里的 logo 和二维码。单张几十 KB，看着不多，但它是每封信都带的固定成本。有人签名里塞了三张图，每封信凭空多出 200 KB。

第四，压缩之后反而更大。jpg、png、pdf、docx、mp4，这些格式本身已经是压缩过的，再套一层 zip 几乎不变，有时因为多了压缩包的文件头，反而比原文件更大一点。压缩只对 bmp、wav、未压缩的 tif、纯文本日志这类原始数据有效。给客户的报价单是 PDF，压不压都一样。

三条绕路，各自要付什么代价

体积确实超了，无非三种处理。三种都能用，但没有一种是无代价的。

第三条被推荐得最多，坑也最多。对方公司的邮件网关会把带短链的信判成推广邮件，直接进垃圾箱，你这边显示已送达，对方说没收到。另一种情况是内网封了外部下载站，链接点开是空白页。

还有一个场景要考虑：金融、医疗、律所这类行业，附件外发本身要走审批。链接形式发出去的文件不经过审批流，事后查不到发了什么，反而不合规。这种单位宁可拆成几封走审批，也别图省事发链接。

用大附件功能之前，先确认四件事

企业邮箱普遍提供"超大附件"或"云附件"，原理是把文件先传到服务商侧存储，邮件正文里只放一个下载链接。它确实能绕开体积限制，但下面四条得先想清楚。

一，有效期。存在服务商侧的文件不是永久的，多数按天计，到期链接失效，收件人再点就是找不到页面。合同、投标文件、验收资料这类要留档的东西，不能只发链接。

二，归档收不收得到。企业开了邮件归档，或者行业要求做长期留存，归档系统抓的是邮件本体。链接背后的那个文件不在归档范围内。真要留证，文件本身必须进邮件。

三，对方能不能打开。有些单位的内网只放行邮件端口，浏览器出不去。链接发过去，等于没发。

四，一两年后还找不找得到。这是最容易被忽略的一条。翻两年前的旧邮件找一份图纸，发现附件全是失效链接，那时候原文件在谁手上已经说不清了。

发不出去时，按这个顺序查

顺序错了会白忙。下面五步，前三步只花两分钟。

1. 看退信里的 Reporting-MTA。是自己域名，说明信没出网，问题在自家网关；是对方域名，往下走。
2. 把整封信的附件体积加总，再乘 1.33。这一步能排除掉八成的"明明不大却发不出"。
3. 看增强状态码是 5.2.3、5.3.4 还是 4.2.2。前两个减体积，第三个让对方清空间。
4. 换一种发送方式试一封：去掉签名图、只留一个附件，发给自己的另一个邮箱。能过，说明就是体积；不能过，问题在账号或网络，跟附件无关。
5. 长期每天都要发大文件的，别在客户端上折腾。把流程改成"文件放共享位置，邮件只发说明和权限"，或者让 IT 评估提高网关上限。

最后提醒一句：如果你用的是客户端而不是网页版，客户端的超时设置也会伪装成"附件发不出去"。表现是进度条卡在 90% 然后报错，退信里什么都没有。这种情况跟体积无关，参数与端口排查见 企业邮箱 IMAP 服务器地址，那里有端口连通性的自测办法；客户端侧发送失败的分类，见 Outlook 只能收不能发。

还有一种更隐蔽的：信发出去了，对方也收到了，但附件打不开。那是编码或文件本身损坏，不是体积问题，方向完全不同。