Microsoft 365 邮件附件大小说明中英

最后更新于：2025-11-21 17:36:36

Microsoft 365 Messaging Architecture: Comprehensive Analysis of Attachment Limitations, Protocol Constraints, and Transport Standards

1. Executive Summary and Architectural Context

1.1 The Duality of Modern Messaging Limits

In the contemporary landscape of digital communication, the administration of email infrastructure requires a nuanced navigation between user expectations for high-capacity file transfer and the rigid, historical constraints of the underlying protocols. Within the Microsoft 365 (Exchange Online) ecosystem, this tension is manifested in a bifurcated set of size limitations. Technically, the platform imposes a default message size limit of approximately 35 MB for transmission and 36 MB for reception. However, administrators possess the latitude to customize this threshold, adjusting the maximum message size within a range extending from 1 MB up to 150 MB.1 This configurability, while seemingly generous, introduces a complex layer of operational risk management, as the theoretical maximums supported by the cloud tenant often diverge significantly from the practical realities of the global internet email system.

在当今的数字通信领域，邮件基础设施的管理需要在用户对大容量文件传输的期望与底层协议严格的历史限制之间进行细致的平衡。在 Microsoft 365（Exchange Online）生态系统中，这种张力体现为一套双重的容量限制标准。从技术角度来看，该平台强制实施了默认的邮件大小限制，发送约为 35 MB，接收约为 36 MB。然而，管理员拥有自定义这一阈值的权限，可以在 1 MB 至 150 MB 的范围内调整最大邮件大小 1。这种配置虽然看似宽裕，却引入了复杂的运营风险管理层面，因为云租户所支持的理论最大值往往与全球互联网邮件系统的实际运行状况存在显著差异。

The architectural dichotomy is explicitly highlighted in Microsoft’s official documentation. When a message remains strictly resident within the Microsoft datacenter environment—traversing only between internal mailboxes within the same tenant or potentially across federated Microsoft 365 tenants—the infrastructure is engineered to support the maximum ceiling of 150 MB robustly. In this controlled environment, proprietary transfer mechanisms and optimized internal routing protocols can bypass some of the inefficiencies inherent in standard internet mail transport. Conversely, once a message is destined for the external internet, it must traverse the public Simple Mail Transfer Protocol (SMTP) relay network. Here, the immutability of legacy standards dictates that binary attachments must undergo encoding, typically Multipurpose Internet Mail Extensions (MIME) Base64, which mathematically necessitates an approximate 33% expansion in file size. Consequently, a message that fits within a 150 MB internal limit may catastrophically fail when subjected to the encoding overhead and the lower acceptance thresholds of external receiving systems.2

微软的官方文档明确强调了这种架构上的二元性。当邮件严格驻留在 Microsoft 数据中心环境内部时——即仅在同一租户内的内部邮箱之间传输，或可能跨越联邦的 Microsoft 365 租户时——该基础设施被设计为能够稳健地支持 150 MB 的最大上限。在这个受控环境中，专有的传输机制和优化的内部路由协议可以绕过标准互联网邮件传输中固有的一些低效问题。相反，一旦邮件注定要发往外部互联网，它必须穿越公共的简单邮件传输协议（SMTP）中继网络。在这里，传统标准的不可变性规定二进制附件必须经过编码，通常是多用途互联网邮件扩展（MIME）Base64，这在数学上必然导致文件大小增加约 33%。因此，一封符合 150 MB 内部限制的邮件，在遭受编码开销和外部接收系统较低的接收阈值限制时，可能会遭遇灾难性的传输失败 2。

1.2 The Reliability Gap in Cross-Organizational Transport

The implications of this architectural reality are profound for enterprise IT strategy. Even if a tenant administrator configures the internal Maximum Send Size and Maximum Receive Size to the highest permissible values using Exchange Management Shell commands like Set-Mailbox, there is absolutely no guarantee that external transmission of equivalent size will succeed. If the recipient's server is configured with traditional limitations—often defaulting to the legacy industry standard of 20 MB to 25 MB—the transmission will be rejected. The sender will typically receive a Non-Delivery Report (NDR) with a descriptive error message indicating that the message size exceeded the administrative limits of the destination system.1 This creates a "reliability gap" where the internal capabilities of the Microsoft 365 platform outpace the interoperability standards of the broader email ecosystem.

这种架构现实对企业 IT 战略具有深远的影响。即使租户管理员使用 Set-Mailbox 等 Exchange 命令行管理程序指令将内部的“最大发送大小”和“最大接收大小”配置为允许的最高值，也绝对无法保证同等大小的外部传输能够成功。如果收件人的服务器配置了传统的限制——通常默认为 20 MB 至 25 MB 的旧行业标准——传输将被拒绝。发件人通常会收到一份未送达报告（NDR），其中包含描述性错误消息，指出邮件大小超过了目标系统的管理限制 1。这造成了一种“可靠性差距”，即 Microsoft 365 平台的内部能力超越了更广泛的电子邮件生态系统的互操作性标准。

Crucially, Microsoft enforces a unified set of Exchange Online limitation rules across all subscription tiers, from Microsoft 365 Business Basic to Enterprise plans. The service description does not position the capability to send large external attachments as a "universally feasible" or "recommended" configuration. Instead, the 150 MB figure serves as a technical hard limit for the platform's storage and processing capabilities, while the actual usable scale for inter-organizational communication is determined by the "lowest common denominator" along the entire transmission path.5 This includes not just the final destination server, but potentially intermediate Mail Transfer Agents (MTAs), security gateways, and spam filters, each of which may enforce its own size constraints to protect against denial-of-service attacks or buffer overflow risks.

至关重要的是，微软在所有订阅层级（从 Microsoft 365 商业基础版到企业版计划）中强制实施一套统一的 Exchange Online 限制规则。服务说明并未将发送大型外部附件的能力定位为一种“普遍可行”或“推荐”的配置。相反，150 MB 的数值仅作为平台存储和处理能力的技术硬性上限，而跨组织通信的实际可用规模则由整个传输路径上的“最小公分母”决定 5。这不仅包括最终的目标服务器，还可能包括中间的邮件传输代理（MTA）、安全网关和垃圾邮件过滤器，其中每一个节点都可能强制执行其自身的大小限制，以防止拒绝服务攻击或缓冲区溢出风险。

2. Technical Deep Dive: Protocol Standards and Encoding Overhead

2.1 Historical Constraints of SMTP (RFC 821 to RFC 5321)

To understand why email remains a suboptimal medium for large file transfer, one must examine the foundational protocols that govern its operation. The Simple Mail Transfer Protocol (SMTP) was originally defined in RFC 821, published in August 1982. At its inception, the internet was a vastly different environment, characterized by low-bandwidth connections and a predominantly academic user base exchanging short, text-based messages. The protocol was designed to be robust and simple, relying on 7-bit ASCII text commands. This design philosophy, while ensuring high compatibility across diverse systems, established a structural limitation: the protocol was not natively designed to handle binary data (such as images, executables, or modern document formats).6

要理解为何电子邮件在传输大文件方面仍然不是理想的媒介，必须审视通过其运作的基础协议。简单邮件传输协议（SMTP）最初定义于 1982 年 8 月发布的 RFC 821 中。在其诞生之初，互联网是一个截然不同的环境，其特点是低带宽连接以及主要交换简短文本消息的学术用户群。该协议的设计初衷是稳健且简单，依赖于 7 位 ASCII 文本命令。这种设计哲学虽然确保了跨不同系统的高度兼容性，但也确立了一个结构性限制：该协议并非原生设计用于处理二进制数据（如图像、可执行文件或现代文档格式）6。

Although RFC 821 was later superseded by RFC 2821 and subsequently updated by RFC 5321 in 2008, the core "store-and-forward" architecture remains largely unchanged. In this model, a message is not streamed directly from sender to recipient like a modern peer-to-peer file transfer. Instead, it is handed off between a series of independent servers (relays). Each server must receive the full message, store it in a local queue, acknowledge receipt, and then attempt to forward it to the next hop. This architecture necessitates that every server in the chain possesses sufficient storage and processing resources to handle the message. If a 100 MB message traverses five relays, it consumes 100 MB of storage and bandwidth at each hop, amplifying the resource cost across the network. This inefficiency is a primary reason why administrators historically enforced conservative size limits—to prevent a single user from clogging the queues of shared infrastructure.8

尽管 RFC 821 后来被 RFC 2821 取代，并随后在 2008 年由 RFC 5321 更新，但核心的“存储转发”架构基本上保持不变。在这个模型中，消息不像现代点对点文件传输那样直接从发送者流向接收者。相反，它在一系列独立的服务器（中继）之间进行传递。每个服务器必须接收完整的消息，将其存储在本地队列中，确认接收，然后尝试将其转发到下一跳。这种架构要求链中的每个服务器都拥有足够的存储和处理资源来处理该消息。如果一条 100 MB 的消息经过五个中继，它将在每一跳消耗 100 MB 的存储和带宽，从而放大了整个网络的资源成本。这种低效性是管理员历来强制实施保守大小限制的主要原因——以防止单个用户堵塞共享基础设施的队列 8。

2.2 The Mechanics of MIME and Base64 Inflation

The integration of binary attachments into the text-based SMTP transport is facilitated by the Multipurpose Internet Mail Extensions (MIME) standards, specifically RFC 2045 and its successors, established around 1996. MIME defines how non-ASCII data should be formatted so that it can be transmitted over the 7-bit clean channels of legacy SMTP. The standard mechanism employed for this purpose is Base64 encoding. Base64 is a binary-to-text encoding scheme that represents binary data in an ASCII string format by translating it into a radix-64 representation. Conceptually, it takes three bytes of binary data (24 bits) and represents them as four 6-bit characters from a printable ASCII subset.10

二进制附件整合进基于文本的 SMTP 传输是通过多用途互联网邮件扩展（MIME）标准实现的，具体而言是 1996 年左右确立的 RFC 2045 及其后续版本。MIME 定义了非 ASCII 数据应如何格式化，以便可以通过传统 SMTP 的 7 位纯净通道进行传输。用于此目的的标准机制是 Base64 编码。Base64 是一种二进制到文本的编码方案，通过将其转换为基数 64 的表示形式，以 ASCII 字符串格式表示二进制数据。从概念上讲，它获取三个字节的二进制数据（24 位），并将其表示为来自可打印 ASCII 子集的四个 6 位字符 10。

The mathematical consequence of this 3-byte to 4-character conversion is a mandatory increase in data size. Specifically, the ratio of 4 characters produced for every 3 bytes consumed results in a 33% increase ($4/3 \approx 1.33$). This is often referred to as the "Base64 overhead" or "encoding tax." For example, a raw file that is 10 MB on a local disk will effectively become approximately 13.3 MB on the wire after encoding. This expansion is critical for administrators to understand because email size limits apply to the encoded size, not the raw file size. Therefore, to allow a user to send a 100 MB file, the transport limit must be set significantly higher than 100 MB—specifically, at least 133 MB, plus additional overhead for headers and MIME boundary markers.2

这种 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 Configuring for the Encoding Factor

Microsoft's guidance on this matter is explicit and requires precise calculation during configuration. When an administrator determines a desired maximum file size for their users, they must multiply this value by 1.33 to determine the correct parameter for the MaxSendSize or MaxReceiveSize. As noted in the support documentation, "Base64 encoding increases the size of the message by approximately 33%, so the value you specify should be approximately 33% larger than the actual message size you want enforced." For instance, if an organization mandates a policy that users should be able to email attachments up to 64 MB, the Exchange administrator must configure the limit to approximately 85 MB or higher. Failing to account for this encoding overhead will result in user frustration, as a file that appears to be within the limit (e.g., 60 MB) will be rejected by the server because its encoded size (~80 MB) exceeds the configured 64 MB threshold.3

微软在此问题上的指导是明确的，并且在配置过程中需要精确的计算。当管理员为用户确定所需的最大文件大小时，他们必须将此数值乘以 1.33，以确定 MaxSendSize 或 MaxReceiveSize 的正确参数。正如支持文档中所述，“Base64 编码使邮件大小增加约 33%，因此您指定的值应比您希望强制执行的实际邮件大小大约 33%。”例如，如果一个组织强制执行一项策略，即用户应能够通过电子邮件发送高达 64 MB 的附件，Exchange 管理员必须将限制配置为大约 85 MB 或更高。未能考虑到这一编码开销将导致用户的挫败感，因为一个看似在限制范围内的文件（例如 60 MB）将被服务器拒绝，因为其编码后的大小（约 80 MB）超过了配置的 64 MB 阈值 3。

3. Detailed Exchange Online Configuration Parameters

3.1 Default Constraints and Customizable Ranges

Within the Exchange Online environment, the default configuration is conservative, reflecting a balance between usability and system performance. The standard defaults are set to a 35 MB maximum send size and a 36 MB maximum receive size. These defaults are applied automatically to new mailboxes unless a global or specific policy overrides them. The slight discrepancy between the send and receive limits is intentional, often designed to allow a margin for header expansion or system-added metadata during the transport process. Administrators have the flexibility to adjust these values downward to 1 MB or upward to 150 MB, depending on organizational needs and compliance requirements.1

在 Exchange Online 环境中，默认配置是保守的，反映了可用性与系统性能之间的平衡。标准默认值设置为 35 MB 的最大发送大小和 36 MB 的最大接收大小。除非有全局或特定策略覆盖，否则这些默认值将自动应用于新邮箱。发送和接收限制之间的细微差异是有意的，通常旨在为传输过程中标头扩展或系统添加的元数据留出余地。管理员可以灵活地将这些值向下调整至 1 MB 或向上调整至 150 MB，具体取决于组织需求和合规性要求 1。

3.2 Client-Specific Limitations and Behaviors

It is critical to recognize that the server-side limit configured in Exchange Online is not the only enforcement point. Different client access protocols and applications enforce their own distinct limitations, which can sometimes override or conflict with the server settings. A granular understanding of these client-specific behaviors is essential for troubleshooting user issues.

Outlook on the Web (OWA): The web-based client enforces a maximum message size limit of 35 MB. This is often hard-coded in the web application logic to prevent browser timeouts and session instability during large uploads.12

Exchange ActiveSync (Mobile Devices): By default, ActiveSync clients are often limited to roughly 10 MB. This lower limit reflects the historical constraints of mobile data networks and the processing power of early smartphones. While this can be adjusted, it represents a significant bottleneck for mobile workforce productivity if not explicitly managed.12

Exchange Web Services (EWS): Clients connecting via EWS, such as Outlook for Mac or third-party integrations, have a default limit of 64 MB. This higher default acknowledges the richer capabilities of desktop applications compared to mobile devices but still falls short of the 150 MB theoretical maximum.12

至关重要的是要认识到，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。

Furthermore, the classic Outlook for Windows client (connecting via MAPI/RPC over HTTP) introduces another layer of complexity. Outlook 2013 and later versions have a default attachment size limit of 20 MB for Internet email accounts (POP3, IMAP, HTTP). This is a client-side check that prevents the user from even attempting to attach a file larger than 20 MB, regardless of the server's capability. For Exchange accounts, the limit typically defaults to 10 MB unless the server policies dictate otherwise. This client-side limit stems from the "Maximum send size" setting configured in the Transport Settings. If a discrepancy exists, users may see an error message stating "Attachment size exceeds the allowable limit" immediately upon trying to attach a file, before any network transmission occurs. This requires registry modifications or Global Policy Object (GPO) updates to align the client behavior with the expanded server limits.4

此外，经典的 Outlook for Windows 客户端（通过 HTTP 上的 MAPI/RPC 连接）引入了另一层复杂性。Outlook 2013 及更高版本对互联网电子邮件帐户（POP3、IMAP、HTTP）默认附件大小限制为 20 MB。这是一个客户端检查，无论服务器的能力如何，都能防止用户甚至尝试附加大于 20 MB 的文件。对于 Exchange 帐户，除非服务器策略另有规定，否则限制通常默认为 10 MB。此客户端限制源于传输设置中配置的“最大发送大小”设置。如果存在差异，用户在尝试附加文件时可能会立即看到一条错误消息，指出“附件大小超过允许的限制”，这发生在任何网络传输之前。这需要修改注册表或更新全局策略对象 (GPO)，以使客户端行为与扩展的服务器限制保持一致 4。

3.3 PowerShell Configuration for Granular Control

For enterprise administrators, the Exchange Management Shell (PowerShell) provides the most robust mechanism for configuring these limits. Unlike the graphical User Interface (EAC), which may obscure certain parameters, PowerShell allows for precise, scriptable control over individual mailboxes or bulk updates across the entire organization. The primary cmdlet used for this purpose is Set-Mailbox. The syntax requires specifying the identity of the user and the desired values for MaxSendSize and MaxReceiveSize.

对于企业管理员而言，Exchange 命令行管理程序 (PowerShell) 提供了配置这些限制的最稳健机制。与可能隐藏某些参数的图形用户界面 (EAC) 不同，PowerShell 允许对单个邮箱进行精确、可编写脚本的控制，或在整个组织范围内进行批量更新。用于此目的的主要 cmdlet 是 Set-Mailbox。该语法要求指定用户的身份以及 MaxSendSize 和 MaxReceiveSize 的所需值。

The following PowerShell example demonstrates how to set the limits for a specific user, "Debra Garcia," to a send limit of 25 MB and a receive limit of 35 MB:

Set-Mailbox -Identity "Debra Garcia" -MaxSendSize 25mb -MaxReceiveSize 35mb

The valid range for these parameters is between 0 KB and 2,097,151 KB (approx 2 GB), although the effective service limit for Exchange Online restricts the functional maximum to 150 MB. Configuring values beyond 150 MB will not result in an error but will be capped by the service's architectural hard limits. This command allows administrators to create tiered service levels—for example, granting "VIP" users higher attachment limits while restricting the general user base to lower values to conserve storage and bandwidth.1

以下 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. High-Volume Scenarios: Distribution Groups

4.1 Scaling Limits and Fan-Out Risks

A critical and often overlooked aspect of message size limits is their application to Distribution Groups. The dynamics of sending a large attachment to a single recipient differ fundamentally from sending the same attachment to a group of 50,000 users. In the latter case, the "fan-out" effect multiplies the storage and I/O load on the system exponentially. To mitigate the risk of system degradation during such events, Exchange Online imposes tiered limits based on the size of the distribution group.

邮件大小限制的一个关键且经常被忽视的方面是其在通讯组中的应用。向单个收件人发送大附件的动态与向 50,000 名用户组成的组发送相同附件的动态有着本质的区别。在后一种情况下，“扇出”效应会呈指数级倍增系统的存储和 I/O 负载。为了减轻此类事件期间系统性能下降的风险，Exchange Online 根据通讯组的规模强制实施分层限制。

According to the service description, distribution groups with 5,000 to 99,999 members have a maximum message size limit of 25 MB. However, for extremely large groups—those with 100,000 members or more—the limit is drastically reduced to 5 MB. This aggressive throttling is a protective measure designed to ensure service availability. A 25 MB message sent to 100,000 users would generate 2.5 Terabytes of data traffic and storage commitment in a single transaction, potentially saturating transport queues and delaying other critical mail flow. Therefore, organizations planning all-hands communications or large-scale newsletters must strictly adhere to these lower thresholds, regardless of the individual sender's mailbox settings.5

根据服务说明，拥有 5,000 到 99,999 名成员的通讯组的最大邮件大小限制为 25 MB。然而，对于极大的组——那些拥有 100,000 名或更多成员的组——该限制被大幅降低至 5 MB。这种激进的限流是一种旨在确保服务可用性的保护措施。向 100,000 名用户发送一条 25 MB 的消息将在单次交易中产生 2.5 TB 的数据流量和存储占用，可能会使传输队列饱和并延迟其他关键邮件流。因此，计划进行全员通信或大规模通讯的组织必须严格遵守这些较低的阈值，无论个人发送者的邮箱设置如何 5。

5. Strategic Recommendations and Modern Alternatives

5.1 The "Best Practice" Size Debate

Given the disparity between the theoretical 150 MB limit and the practical constraints of the internet ecosystem, a common question arises among administrators: "What is the best size setting?" While technically possible to maximize the settings, community consensus and Microsoft's implicit guidance suggest that the default 35 MB range is often the "sweet spot" for external interoperability. Setting the limit to 150 MB creates a false sense of security for users, leading them to believe they can email large project files to external clients, only to face inevitable bounce-backs from receiving servers capped at 20 MB. This negative user experience often generates more helpdesk tickets than a restrictive policy would.15

鉴于 150 MB 的理论限制与互联网生态系统的实际约束之间的差异，管理员中经常出现一个问题：“最佳大小设置是多少？”虽然技术上可以将设置最大化，但社区共识和微软的隐性指导表明，默认的 35 MB 范围通常是外部互操作性的“最佳平衡点”。将限制设置为 150 MB 会给用户造成一种虚假的安全感，导致他们认为可以通过电子邮件将大型项目文件发送给外部客户，结果却面临被限制在 20 MB 的接收服务器不可避免的退信。这种负面的用户体验通常比限制性策略产生的帮助台工单更多 15。

5.2 Transitioning to Modern Attachments

The definitive solution to the large file problem is to decouple the data payload from the messaging transport entirely. Microsoft strongly advocates for the use of "Modern Attachments"—a workflow where files are uploaded to OneDrive for Business or SharePoint Online, and only a secure access link is transmitted via email. This approach circumvents the SMTP size limits entirely, allowing for the sharing of files gigabytes in size. Furthermore, it introduces enterprise-grade capabilities that email lacks:

Version Control: Recipients see the latest version of the file, eliminating the confusion of "File_v1.docx" and "File_v2_final.docx" chains.

Security and Audit: Access to the link can be revoked at any time, and access logs provide an audit trail of who viewed the document—features impossible with a detached MIME attachment.

Co-authoring: Multiple users can edit the document simultaneously, improving collaboration efficiency.

解决大文件问题的根本方案是将数据负载与消息传输完全解耦。微软强烈提倡使用“现代附件”——一种工作流，即将文件上传到 OneDrive for Business 或 SharePoint Online，并通过电子邮件仅传输安全访问链接。这种方法完全绕过了 SMTP 大小限制，允许共享千兆字节大小的文件。此外，它引入了电子邮件所缺乏的企业级功能：

版本控制：收件人可以看到文件的最新版本，消除了“File_v1.docx”和“File_v2_final.docx”链的混淆。

安全和审计：对链接的访问可以随时撤销，访问日志提供了谁查看了文档的审计跟踪——这是分离的 MIME 附件无法实现的功能。

共同创作：多个用户可以同时编辑文档，提高了协作效率。

5.3 Conclusion

In conclusion, while Microsoft 365 possesses the technical architecture to support email messages up to 150 MB internally, this capability should be viewed as a specific utility for internal workflows rather than a general-purpose communication standard. The immutable physics of Base64 encoding, which adds a 33% overhead, combined with the legacy constraints of the global SMTP ecosystem, renders the transmission of ultra-large attachments externally unreliable. Administrators are advised to maintain conservative default limits to align with global standards while educating users on modern file-sharing alternatives. This strategy minimizes delivery failures (NDRs), optimizes transport performance, and aligns with the best practices of secure, collaborative digital work.

综上所述，虽然 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,

Microsoft 365 邮件附件大小说明 中英

Microsoft 365 邮件附件大小说明中英