Email Size Limits

by  Sam C. Chan


First Published: September 20, 2006
Last Updated: April 2, 2011
Last Verified: August 7, 2012
Table with newly revised limits added. Article remain unchanged. Old table (dimmed) kept for reference.

There are many limits in effect from various sources when sending email. This article illustrates the aspect of size limits. Besides size limit, email sending is also subject to content filtering, per-hour and per-day throttling, destination/source blacklists, etc.


It is absolutely necessary to enforce email size limits at various places. There are numerous practical, technical, legal and ethical reasons, beyond our scope of discussion here. Suffice to state that: Without such limitations, worldwide meltdown of The Internet (not just email) would be a daily occurrence. Email is by nature insecure, unaccountable, infinitely recursive, and most significantlycan be leveraged exponentially! Any slightest misstep, be it inadvertent or malicious (both inevitable) could result in catastrophic collapses.

This revised table reflects the current findings in our latest survey

Provider/Plan No. of
Mailbox Storage
Message Size Outbound Throttling
Receiving Sending Per hour per-day Webmail
Frontier 7 50M 25M 25M 250 1000 Ajax
TW RR Lite/Basic 5 20M 30M 30M n/d 1000 HTML
TW RR Standard 10 100M 30M 30M n/d 1000 HTML
TW RR Premium 25 100M 30M 30M n/d 1000 HTML
Earthlink 8 100M 10M 5M/10M* 40 recipients/msg HTML
MS Live/Hotmail 1 2G+*** 25M 25M n/d n/d Ajax
Yahoo 1 unlimited** 25M 25M n/d n/d Ajax
Gmail 1 10G+*** 25M 25M n/d n/d Ajax
Mach 4 FELI plan self-allocated 15M 15M n/d n/d HTML
Mach 4 TUBB plan 2G 2G unlimited** n/d n/d Ajax
Mach 4 LEON plan self-allocated n/d 25M n/d n/d OWA
Mach 4 EGYP 4000 self-allocated n/d n/d n/d n/d OWA

* when sent via webmail, not via email client to smtp server
** of course, the laws of physics apply - that means it's still subject to hidden "soft limits"
*** theoretical, usually not realized in actual usage due to various hidden limits
remember: 1M = 2^20 = 1048576
Did you know? MIME encoding overhead = 37%    10M files = 14M transmission & storage!! is not affected by MIME encoding overhead on their end.


This table is outdated and superseded by the one above

Various Stages of Size Limits An Email Message Is Subject To

Sender Email Client (e.g. Outlook) Typically unlimited (except by disk space)
Sender Exchange Server* Per site administrator policies
Sender SMTP Server per message RR: 5M, Frontier: 10M, Mach-4: 7M, Local: ? 2006
Destination POP Server Quota** Typically no per-message limits, only quota in effect:
: 10M, Frontier: 25M 
Mach-4: Per hosting plan: Site quota & User quota
Destination Exchange Server* Per site administrator policies
Recipient Email Client (e.g. Outlook) Typically unlimited (except by disk space)

Space Usage for Typical Scenarios

Quota Text email
 messages (4K)
High Resolution
Photo (250K)
128Kbps Song
/PDF doc (4M)
5M 1,250 20 1.25
10M 2,500 40 2.50
15M 3,750 60 3.75
20M 5,000 80 5.00

As you can see from the table above, a 10M quota is enough to hold 2,500 email messages. That's 1 full year's worth for the typical user. That same quota will also hold 40 high resolution pictures, or just 2 typical songs or PDF documents.

Due to extremely poor efficiency of the antiquated MIME protocol used to encode attachments into plain text, the resulting email message is typically 1.2x to 1.5x the size of the original attachments. e.g. A 5M message can hold only 3.3M~4.2M worth of file(s)!

Email server is a "holding tank" or buffer. A user requires enough space quota to hold all the email arriving during the interval between retrievals (typically 5 minutes to 24 hours).  For those saving messages on server for retrieval at alternate locations, space is required for all messages received within the retention period (typically 5 to 14 days). Finally, those cumulating message on server permanently and rely on it as primary storage must provide space for the entire set of messages and attachments.

To summarize, there are 3 modes of operations, as related to email server space:

  1. Retrieve and Remove (Standard)

  2. Retrieve and Deferred Removal (Multi-Station)

  3. Retrieve and Retain (Host-based)

For those with hosting plan, it's customary to over-allocate within the organization, anticipating that most users would not actually use up their quotas. For example: 100M total space is obtained, and 10M quota is allocated to each of the 12 users, resulting in a theoretical maximum usage of 120M. It is possible for site quota to be exceeded, even when the user quotas are still  within limits.

Solutions To Mitigate Size Limits:

  • Compress the attachment

  • Send multiple attachments in separate messages

  • Split attachment into multiple files (requires joining at recipient end)

  • Implement and use your own in-house or datacenter-hosted SMTP

  • Upgrade residential ISP line to commercial (avoids port 25 filtering)

  • Upgrade hosting plan (increase quota)

  • Re-allocate user quotas within your hosting plan

  • More frequent mail retrieval

  • Reduce message retention period on server

  • Convert from POP-based to client-/Exchange-based email storage

  • Use webmail:

    • selectively delete unneeded messages to free up space

    • bypass ISP SMTP sending limits (subject to hosting limits)

  • Avoid attachments & use proper alternate file transfer methods

    • dropbox     Bravo has been offering Dropbox Service since 2003!

    • pickup counter

    • point-to-point file transfer

    • web document hosting/retrieval (send only links)

    • FTP server

  • SPAM management (conserve quota for legitimate email)


*Exchange Server (if installed & used) could impose limits per policies set by site administrator. It is not applicable for small offices that do not have it.

**Quota can be exceeded if user is not checking frequently enough, or opt to save message on server. POP server is not applicable for sites directly delivering to their Exchange Servers.


See also:

External Links for email troubleshooting: Yahoo | Roadrunner | AOL |

Copyright @2005-2006   Bravo Technology Center  *  Bravo:GO  *  Contact Us