(If there is a better place to ask this, let me know.)

A lot of email servers limit the combined size of files attached to incoming emails. Like, for example, maybe some email server disallows messages larger than 20MB; it would fail if an attachment is 22MB, and it would also fail if one attachment is 10MB and a second attachment is 12MB. Most email servers implement some sort of limit like this example, but the total allowed size varies depending on which.

Here's the part I don't understand though - does that size limit only apply to attachments? or does it apply to the total size of the email? Like, lets say that a hypothetical email has an attachment that is exactly 19.98MB. But, the body of the email message is 0.03MB. Assuming that the receiving email server has a limit of 20MB, would that arrive? or fail to arrive? Or maybe whether that particular example succeeds or fails depending on which email server is hypothetically receiving it?

  • 3
    The Answer by user @Esa Jokinen covers the Server case, which is what you are asking about. Worth mentioning that Web Email Clients (eg Gmail & Yahoo) can reject based on (1) Individual Attachment Size (2) Attachment Count (3) Total Attachment Size & (4) Attachment Type, not even allowing the Attachment Upload to go through in case these Criteria are violated !!
    – Prem
    Commented Jun 25, 2022 at 8:03
  • And in the event you are managing a webmail server, you will have the various limitations on the web-related applications (e.g., HTTP server, PHP configuration, etc.).
    – Paul
    Commented Jun 29, 2022 at 11:54

2 Answers 2


Technically, there is no difference between the message body and the attachments. Both the body and the attachments are equally parts of a multipart or multipurpose email message, as defined in RFC 2045.

The message size limits are typically against the total length of the message including all the parts and the headers. Such limit can also be advertised with a Message Size Declaration reply to the EHLO command, and the RFC 1870 also provides a definition for the size limit in section 5:

The message size is defined as the number of octets, including CR-LF pairs, but not the SMTP DATA command's terminating dot or doubled quoting dots, to be transmitted by the SMTP client after receiving reply code 354 to the DATA command.

The fixed maximum message size is defined as the message size of the largest message that a server is ever willing to accept. An attempt to transfer any message larger than the fixed maximum message size will always fail.

This is, e.g., implemented in both Postfix and Exim with message_size_limit configuration parameter; Microsoft Exchange has multiple types of message size limits.

Also notice that binary attachments must be converted to 7-bit ASCII text. Base64 encoding is used for this, causing 37% overhead (33% by the encoding itself; 4% more by the inserted line breaks; RFC 2045, 6.8). For this reason you may not be able to send attachments despite they are smaller than the limit.

  • 1
    I cannot estimate how common those are, but additional anti-DoS-motivated limitations on number and inflated size of nested & compressed attachments will further complicate a simple description of an effective "size limit".
    – anx
    Commented Jun 24, 2022 at 21:35
  • 3
    That's true, but also a bit far from the original question which is about sending legitimate mail with more typical attachments. Commented Jun 25, 2022 at 6:00
  • MIME requires line breaks at-least every 76 characters so 37% (21÷57) is the minimum size expansion
    – Jasen
    Commented Jun 26, 2022 at 1:11
  • 1
    @Jasen: According to RFC 5322, 2.3 "Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF." Therefore, 76 characters is not a hard requirement, making the overhead more varying than that. Commented Jun 26, 2022 at 10:02
  • 1
    @EsaJokinen read the section toy pointed me to againt, then check out datatracker.ietf.org/doc/html/rfc2045#section-6.8 - and search for the string 76 on page 24
    – Jasen
    Commented Jun 29, 2022 at 8:13

I'm not sure this is necessarily universal, some service somewhere could very well implement their limits differently.

But I think what makes sense is to simply look at the size of the email as a whole; it doesn't really matter if there are any attachments or what it is about the email that makes it "too large", it's easier and more useful for the mail service to look at the size of the whole email.

Also worth noting regarding attachments is that attached files are typically base64-encoded, in which case they will grow just over a third compared to the original file size.

  • 2
    RFC1870 defines size as "the number of octets, including CR-LF pairs, but not the SMTP DATA command's terminating dot or doubled quoting dots, to be transmitted by the SMTP client after receiving reply code 354 to the DATA command." but yeah, non standard implementations can use other definitions.
    – Jasen
    Commented Jun 26, 2022 at 1:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .