Gmail、Outlook、iCloud Mail 的附件上限到底多大?这篇指南讲清 2026 年各大邮件服务商真实容量、Apple Mail 内置尺寸调整以及 Zipic 邮件预设工作流。
发邮件附图看起来很简单,直到出现「附件大小超过限制」的退信,或者收件人抱怨内嵌图加载消耗了一整个流量包。邮件是图片传递最嘈杂的渠道之一:每家服务商都设了不同的大小上限,移动端会裁剪过大的 HTML 邮件,你电脑能发出去的附件,对方在 iPhone 上可能直接打不开。
这篇指南聚焦如何在 Mac 上为邮件压缩图片。涵盖 2026 年各大邮件服务商真实的容量上限、Apple Mail 内置的尺寸调整与 Zipic 预设工作流的对比,以及什么情况下应该放弃直接附件、改用 Mail Drop 或 Drive 链接。
每条「附件过大」的报错背后,是这些限制之一:
| 服务商 | 单封邮件上限 | 说明 |
|---|---|---|
| Gmail | 25 MB | 超出会自动转为 Google Drive 链接插入邮件正文 |
| Outlook.com(消费版) | 20 MB | 总和 = 所有附件 + 内嵌图 |
| Microsoft 365(Outlook + Exchange Online) | 默认 35 MB;管理员可调至最高 150 MB | OWA 上限 = 配置值的 75%(默认 ≈ 26 MB,上限 150 MB 时 = 112 MB);新版 Outlook for Mac 和 Outlook 移动端封顶 33 MB |
| Yahoo Mail | 25 MB | 单封总量 |
| iCloud Mail(直接附件) | 20 MB | 超出会提示使用 Mail Drop |
| iCloud Mail Drop | 单附件最大 5 GB,账户 1 TB 总额 | 收件人 30 天下载期;不占 iCloud 存储 |
(数据来源见文末。)
几个实用结论。第一,跨平台发送的最低公约数大约是 20 MB,不是 25。如果对方用的是你无法掌控的 Microsoft 365 邮箱,最多只能假设 35 MB,实际经常更少。第二,限制覆盖整封 MIME 编码后的邮件——正文、内嵌图、附件共享同一个预算,而 base64 编码会带来约 33% 的体积膨胀,原始 20 MB 文件实际传输时大约 27 MB。Finder 里看到的数字不是邮件服务器称重的那个数字。
即便附件刚好过线,过大的图片仍会带来一连串后续问题。
Gmail 的网页端会在 HTML 正文代码超过 102 KB 时裁断邮件,超出部分用「[Message clipped]」折叠。这条 102 KB 上限只针对 HTML 代码本身——外链图片(<img src="https://...">)不计入;但臃肿的内联 CSS、base64 内嵌的 data-URI 图片、追踪像素会快速把这条线撞穿。普通发照片邮件几乎遇不到这个问题,但简报式群发邮件经常因此让读者看不到 CTA。
带宽侧的限制由移动端决定。iOS Mail、Outlook Mobile 默认在蜂窝网络下推迟下载图片;6 MB 的封面图要么在慢速连接下让邮件加载多卡几秒,要么干脆等到对方接 Wi-Fi 才显示。用户会怪你的发件信誉,而不是运营商。
最后,附件偏重的邮件在送达评分中分数偏低。垃圾邮件过滤器把过大图片视作信号——不是图本身有问题,而是垃圾邮件惯用大体积图。轻一点确实更好。
没有标准答案,但下面这些目标覆盖大多数常见场景:
| 场景 | 目标尺寸 | 目标文件大小 |
|---|---|---|
| 给同事发个内嵌截图 | 长边 1200–1600 px | 150–300 KB |
| 邮件简报封面图 | 宽度 600–650 px | 100–200 KB |
| 给亲友的生活照 | 长边 1600–2400 px | 300–800 KB |
| 多图相册(5+ 张) | 长边 1280 px 每张 | 每张约 150 KB |
| 文件扫描件 / 票据 | 长边 1500 px | 200–400 KB |
针对邮件简报,Mailjet、Moosend、Litmus 三家给出的建议是一致的:单张图控制在 200 KB 以下、宽度 600 px,整封 HTML 控制在 102 KB 以内,避免 Gmail 截断。
把图片拖进 Mac Mail 撰写窗口时,邮件右上角会出现一个 Image Size(图片大小)下拉菜单,提供四个选项:
应付临时一封邮件够用,但有两个重要前提。这个下拉只对 JPEG 和 GIF 生效;PNG 附件无论你选哪个,都会按原始尺寸发出。而且选项会跨会话保持——如果上次为某次重要交付选了「Actual Size」,下次随手发张照片,没改回去就会按原始尺寸发出。
所以 Apple Mail 内置的方案能解决最简单的场景(一张 JPEG,发小一点)。它解决不了 PNG、不能换格式、不做尺寸以外的压缩、不能按收件人/场景设置默认值。任何稍微复杂一点的需求,都值得在 Mail 之前加一道压缩步骤——速度更快,产出更好。
Zipic 是预设驱动的工作流:先配好压缩设置,再把图片加进来,自动开始处理。没有「开始」按钮——加文件本身就是触发条件。
我有一个**「邮件」**预设,覆盖大约 90% 的外发图片附件:
~/Desktop/Email Images/,便于挑选附件点 Zipic 主窗口左下角的压缩设置,按上述配置编辑或新建预设,然后把照片拖进来。Zipic 一次性完成尺寸调整、格式转换和压缩。
处理完后,直接从结果列表把文件拖到 Mail 撰写窗口——Image Size 下拉菜单里选什么都不重要了,因为源文件本身就已经是最优体积。
预设系统的更详细介绍见 Mac 批量压缩图片完整教程;如果需要命中具体 KB 目标,参考把图片压缩到指定大小。预设基础参考 Zipic 图像压缩基础。
压缩一直管用,直到它不管用。20 张印刷分辨率的产品图、30 秒的录屏、给客户的整文件夹 RAW——这些不是邮件问题,是「伪装成邮件的文件传输问题」。
我的判断标准:
典型场景——几张截图、几张照片、一个 PDF——压缩一下,邮件还是邮件。其他场景,链接才是对的答案。
压缩图片会让邮件里看起来变差吗? Zipic 默认的等级 2 或 3,收件人基本看不出来。等级 4–5 开始软化照片细节,缩略图尺寸的内嵌图无所谓,但封面图会能看出。
邮件里发 PNG 还是 JPEG? 照片以及任何文件大小比像素无损更重要的场景用 JPEG。只有 UI 文字截图、硬边缘 logo、需要透明背景的图才用 PNG。WebP 是更好的默认值,前提是确认收件人的邮件客户端能渲染——经典 Outlook 桌面端(2019/2021/2024 经典版)仍然不支持。
为什么收件人看到「Message clipped」? Gmail 在 HTML 代码超过 102 KB 时会裁断邮件。外链图片不计入;但 data-URI 内嵌图和臃肿的内联 CSS 会被算入。精简 HTML、去掉无用追踪像素、用 CDN 托管图片即可。
邮件能发 WebP 附件吗? 能——较新的 Apple Mail、Gmail 网页端、新版 Outlook for Windows/Mac、Outlook 移动端都能内联渲染 WebP。经典 Outlook 桌面端(2019/2021/2024 经典版)和浏览器本身不支持 WebP 时打开的 Outlook 网页版会回退到「使用默认应用打开」。不确定就用 JPEG。
不要再被 25 MB 邮件附件上限卡住。下载 Zipic,建一个邮件预设,把照片一次性压到适合附件的大小。查看价格方案。