Microsoft 365 邮件附件大小说明 (中文版)
Microsoft 365 邮件通信架构：附件限制、协议约束与传输标准深度解析
1. 执行摘要与架构背景
1.1 现代消息限制的二元性
在当今的数字通信领域，邮件基础设施的管理需要在用户对大容量文件传输的期望与底层协议严格的历史限制之间进行细致的平衡。在 Microsoft 365（Exchange Online）生态系统中，这种张力体现为一套双重的容量限制标准。从技术角度来看，该平台强制实施了默认的邮件大小限制，发送约为 35 MB，接收约为 36 MB。然而，管理员拥有自定义这一阈值的权限，可以在 1 MB 至 150 MB 的范围内调整最大邮件大小 1。这种配置虽然看似宽裕，却引入了复杂的运营风险管理层面，因为云租户所支持的理论最大值往往与全球互联网邮件系统的实际运行状况存在显著差异。
微软的官方文档明确强调了这种架构上的二元性。当邮件严格驻留在 Microsoft 数据中心环境内部时——即仅在同一租户内的内部邮箱之间传输，或可能跨越联邦的 Microsoft 365 租户时——该基础设施被设计为能够稳健地支持 150 MB 的最大上限。在这个受控环境中，专有的传输机制和优化的内部路由协议可以绕过标准互联网邮件传输中固有的一些低效问题。相反，一旦邮件注定要发往外部互联网，它必须穿越公共的简单邮件传输协议（SMTP）中继网络。在这里，传统标准的不可变性规定二进制附件必须经过编码，通常是多用途互联网邮件扩展（MIME）Base64，这在数学上必然导致文件大小增加约 33%。因此，一封符合 150 MB 内部限制的邮件，在遭受编码开销和外部接收系统较低的接收阈值限制时，可能会遭遇灾难性的传输失败 2。
1.2 跨组织传输的可靠性差距
这种架构现实对企业 IT 战略具有深远的影响。即使租户管理员使用 Set-Mailbox 等 Exchange 命令行管理程序指令将内部的“最大发送大小”和“最大接收大小”配置为允许的最高值，也绝对无法保证同等大小的外部传输能够成功。如果收件人的服务器配置了传统的限制——通常默认为 20 MB 至 25 MB 的旧行业标准——传输将被拒绝。发件人通常会收到一份未送达报告（NDR），其中包含描述性错误消息，指出邮件大小超过了目标系统的管理限制 1。这造成了一种“可靠性差距”，即 Microsoft 365 平台的内部能力超越了更广泛的电子邮件生态系统的互操作性标准。
至关重要的是，微软在所有订阅层级（从 Microsoft 365 商业基础版到企业版计划）中强制实施一套统一的 Exchange Online 限制规则。服务说明并未将发送大型外部附件的能力定位为一种“普遍可行”或“推荐”的配置。相反，150 MB 的数值仅作为平台存储和处理能力的技术硬性上限，而跨组织通信的实际可用规模则由整个传输路径上的“最小公分母”决定 5。这不仅包括最终的目标服务器，还可能包括中间的邮件传输代理（MTA）、安全网关和垃圾邮件过滤器，其中每一个节点都可能强制执行其自身的大小限制，以防止拒绝服务攻击或缓冲区溢出风险。
2. 技术深度解析：协议标准与编码开销
2.1 SMTP 的历史局限 (RFC 821 至 RFC 5321)
要理解为何电子邮件在传输大文件方面仍然不是理想的媒介，必须审视通过其运作的基础协议。简单邮件传输协议（SMTP）最初定义于 1982 年 8 月发布的 RFC 821 中。在其诞生之初，互联网是一个截然不同的环境，其特点是低带宽连接以及主要交换简短文本消息的学术用户群。该协议的设计初衷是稳健且简单，依赖于 7 位 ASCII 文本命令。这种设计哲学虽然确保了跨不同系统的高度兼容性，但也确立了一个结构性限制：该协议并非原生设计用于处理二进制数据（如图像、可执行文件或现代文档格式）6。
尽管 RFC 821 后来被 RFC 2821 取代，并随后在 2008 年由 RFC 5321 更新，但核心的“存储转发”架构基本上保持不变。在这个模型中，消息不像现代点对点文件传输那样直接从发送者流向接收者。相反，它在一系列独立的服务器（中继）之间进行传递。每个服务器必须接收完整的消息，将其存储在本地队列中，确认接收，然后尝试将其转发到下一跳。这种架构要求链中的每个服务器都拥有足够的存储和处理资源来处理该消息。如果一条 100 MB 的消息经过五个中继，它将在每一跳消耗 100 MB 的存储和带宽，从而放大了整个网络的资源成本。这种低效性是管理员历来强制实施保守大小限制的主要原因——以防止单个用户堵塞共享基础设施的队列 8。
2.2 MIME 机制与 Base64 膨胀
二进制附件整合进基于文本的 SMTP 传输是通过多用途互联网邮件扩展（MIME）标准实现的，具体而言是 1996 年左右确立的 RFC 2045 及其后续版本。MIME 定义了非 ASCII 数据应如何格式化，以便可以通过传统 SMTP 的 7 位纯净通道进行传输。用于此目的的标准机制是 Base64 编码。Base64 是一种二进制到文本的编码方案，通过将其转换为基数 64 的表示形式，以 ASCII 字符串格式表示二进制数据。从概念上讲，它获取三个字节的二进制数据（24 位），并将其表示为来自可打印 ASCII 子集的四个 6 位字符 10。
这种 3 字节到 4 字符转换的数学后果是数据大小的强制增加。具体来说，每消耗 3 个字节产生 4 个字符的比率导致了 33% 的增长（$4/3 \approx 1.33$）。这通常被称为“Base64 开销”或“编码税”。例如，本地磁盘上 10 MB 的原始文件在编码后，在线路上传输时将实际变为大约 13.3 MB。这种扩展对于管理员的理解至关重要，因为邮件大小限制适用于已编码的大小，而非原始文件大小。因此，为了允许用户发送 100 MB 的文件，传输限制必须设置得明显高于 100 MB——具体来说，至少为 133 MB，外加用于标头和 MIME 边界标记的额外开销 2。
2.3 针对编码因素的配置
微软在此问题上的指导是明确的，并且在配置过程中需要精确的计算。当管理员为用户确定所需的最大文件大小时，他们必须将此数值乘以 1.33，以确定 MaxSendSize 或 MaxReceiveSize 的正确参数。正如支持文档中所述，“Base64 编码使邮件大小增加约 33%，因此您指定的值应比您希望强制执行的实际邮件大小大约 33%。”例如，如果一个组织强制执行一项策略，即用户应能够通过电子邮件发送高达 64 MB 的附件，Exchange 管理员必须将限制配置为大约 85 MB 或更高。未能考虑到这一编码开销将导致用户的挫败感，因为一个看似在限制范围内的文件（例如 60 MB）将被服务器拒绝，因为其编码后的大小（约 80 MB）超过了配置的 64 MB 阈值 3。
3. Exchange Online 详细配置参数
3.1 默认限制与可自定义范围
在 Exchange Online 环境中，默认配置是保守的，反映了可用性与系统性能之间的平衡。标准默认值设置为 35 MB 的最大发送大小和 36 MB 的最大接收大小。除非有全局或特定策略覆盖，否则这些默认值将自动应用于新邮箱。发送和接收限制之间的细微差异是有意的，通常旨在为传输过程中标头扩展或系统添加的元数据留出余地。管理员可以灵活地将这些值向下调整至 1 MB 或向上调整至 150 MB，具体取决于组织需求和合规性要求 1。
3.2 特定于客户端的限制与行为
至关重要的是要认识到，Exchange Online 中配置的服务器端限制并非唯一的执行点。不同的客户端访问协议和应用程序强制执行其独特的限制，这些限制有时可能会覆盖服务器设置或与之冲突。对这些特定于客户端的行为的细粒度理解对于排查用户问题至关重要。
Outlook 网页版 (OWA)： 基于 Web 的客户端强制执行 35 MB 的最大邮件大小限制。这通常硬编码在 Web 应用程序逻辑中，以防止在大文件上传期间发生浏览器超时和会话不稳定 12。
Exchange ActiveSync（移动设备）： 默认情况下，ActiveSync 客户端通常被限制在大约 10 MB。这个较低的限制反映了移动数据网络和早期智能手机处理能力的历史限制。虽然可以对此进行调整，但如果未明确管理，这将成为移动办公人员生产力的显著瓶颈 12。
Exchange Web Services (EWS)： 通过 EWS 连接的客户端，如 Outlook for Mac 或第三方集成，默认限制为 64 MB。这一较高的默认值承认了桌面应用程序相对于移动设备具有更丰富的功能，但仍低于 150 MB 的理论最大值 12。
此外，经典的 Outlook for Windows 客户端（通过 HTTP 上的 MAPI/RPC 连接）引入了另一层复杂性。Outlook 2013 及更高版本对互联网电子邮件帐户（POP3、IMAP、HTTP）默认附件大小限制为 20 MB。这是一个客户端检查，无论服务器的能力如何，都能防止用户甚至尝试附加大于 20 MB 的文件。对于 Exchange 帐户，除非服务器策略另有规定，否则限制通常默认为 10 MB。此客户端限制源于传输设置中配置的“最大发送大小”设置。如果存在差异，用户在尝试附加文件时可能会立即看到一条错误消息，指出“附件大小超过允许的限制”，这发生在任何网络传输之前。这需要修改注册表或更新全局策略对象 (GPO)，以使客户端行为与扩展的服务器限制保持一致 4。
3.3 用于精细控制的 PowerShell 配置
对于企业管理员而言，Exchange 命令行管理程序 (PowerShell) 提供了配置这些限制的最稳健机制。与可能隐藏某些参数的图形用户界面 (EAC) 不同，PowerShell 允许对单个邮箱进行精确、可编写脚本的控制，或在整个组织范围内进行批量更新。用于此目的的主要 cmdlet 是 Set-Mailbox。该语法要求指定用户的身份以及 MaxSendSize 和 MaxReceiveSize 的所需值。
以下 PowerShell 示例演示了如何将特定用户“Debra Garcia”的限制设置为发送限制 25 MB 和接收限制 35 MB：
Set-Mailbox -Identity "Debra Garcia" -MaxSendSize 25mb -MaxReceiveSize 35mb
这些参数的有效范围在 0 KB 到 2,097,151 KB（约 2 GB）之间，尽管 Exchange Online 的有效服务限制将功能最大值限制为 150 MB。配置超过 150 MB 的值不会导致错误，但会受到服务架构硬性限制的约束。此命令允许管理员创建分层服务级别——例如，授予“VIP”用户更高的附件限制，同时将普通用户群限制在较低的值，以节省存储和带宽 1。
4. 高容量场景：通讯组
4.1 扩展限制与扇出风险
邮件大小限制的一个关键且经常被忽视的方面是其在通讯组中的应用。向单个收件人发送大附件的动态与向 50,000 名用户组成的组发送相同附件的动态有着本质的区别。在后一种情况下，“扇出”效应会呈指数级倍增系统的存储和 I/O 负载。为了减轻此类事件期间系统性能下降的风险，Exchange Online 根据通讯组的规模强制实施分层限制。
根据服务说明，拥有 5,000 到 99,999 名成员的通讯组的最大邮件大小限制为 25 MB。然而，对于极大的组——那些拥有 100,000 名或更多成员的组——该限制被大幅降低至 5 MB。这种激进的限流是一种旨在确保服务可用性的保护措施。向 100,000 名用户发送一条 25 MB 的消息将在单次交易中产生 2.5 TB 的数据流量和存储占用，可能会使传输队列饱和并延迟其他关键邮件流。因此，计划进行全员通信或大规模通讯的组织必须严格遵守这些较低的阈值，无论个人发送者的邮箱设置如何 5。
5. 战略建议与现代替代方案
5.1 “最佳实践”大小的争论
鉴于 150 MB 的理论限制与互联网生态系统的实际约束之间的差异，管理员中经常出现一个问题：“最佳大小设置是多少？”虽然技术上可以将设置最大化，但社区共识和微软的隐性指导表明，默认的 35 MB 范围通常是外部互操作性的“最佳平衡点”。将限制设置为 150 MB 会给用户造成一种虚假的安全感，导致他们认为可以通过电子邮件将大型项目文件发送给外部客户，结果却面临被限制在 20 MB 的接收服务器不可避免的退信。这种负面的用户体验通常比限制性策略产生的帮助台工单更多 15。
5.2 向现代附件过渡
解决大文件问题的根本方案是将数据负载与消息传输完全解耦。微软强烈提倡使用“现代附件”——一种工作流，即将文件上传到 OneDrive for Business 或 SharePoint Online，并通过电子邮件仅传输安全访问链接。这种方法完全绕过了 SMTP 大小限制，允许共享千兆字节大小的文件。此外，它引入了电子邮件所缺乏的企业级功能：
版本控制： 收件人可以看到文件的最新版本，消除了“File_v1.docx”和“File_v2_final.docx”链的混淆。
安全和审计： 对链接的访问可以随时撤销，访问日志提供了谁查看了文档的审计跟踪——这是分离的 MIME 附件无法实现的功能。
共同创作： 多个用户可以同时编辑文档，提高了协作效率。
5.3 结论
综上所述，虽然 Microsoft 365 拥有在内部支持高达 150 MB 电子邮件的技术架构，但这种能力应被视为内部工作流的特定工具，而非通用通信标准。Base64 编码增加 33% 开销的不可变物理特性，结合全球 SMTP 生态系统的传统限制，使得超大附件的对外传输变得不可靠。建议管理员维持保守的默认限制以与全球标准保持一致，同时教育用户使用现代文件共享替代方案。这一策略能够最大限度地减少投递失败（NDR），优化传输性能，并符合安全、协作式数字工作的最佳实践。
Works cited
Configure message size limits for a mailbox in Exchange Server - Microsoft Learn, accessed November 21, 2025,
Service limits for Azure Communication Services - Microsoft Learn, accessed November 21, 2025,
Configure client-specific message size limits in Exchange Server - Microsoft Learn, accessed November 21, 2025,
Attachment size exceeds the allowable limit error - Outlook - Microsoft Learn, accessed November 21, 2025,
Exchange Online limits - Service Descriptions | Microsoft Learn, accessed November 21, 2025,
Simple Mail Transfer Protocol - Wikipedia, accessed November 21, 2025,
RFC 821 - Simple Mail Transfer Protocol - IETF Datatracker, accessed November 21, 2025,
RFC 5321 - Simple Mail Transfer Protocol - IETF Datatracker, accessed November 21, 2025,
draft-ietf-emailcore-rfc5321bis-44 - Simple Mail Transfer Protocol, accessed November 21, 2025,
RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One - IETF Datatracker, accessed November 21, 2025,
Information on RFC 2045 - » RFC Editor, accessed November 21, 2025,
Message size and recipient limits in Exchange Server | Microsoft Learn, accessed November 21, 2025,
Graph API returns wrong size for email attachments - Microsoft Q&A, accessed November 21, 2025,
Message size issue - Microsoft Q&A, accessed November 21, 2025,
Best size for sending and receiving emails - Microsoft Q&A, accessed November 21, 2025,