email size limit optimization for high volume senders

Every email provider has two limits that matter when you're sending at volume: how many messages you can send per day, and how large each message can be. Most guides focus on the first number. The second one quietly kills your throughput.

A 100 KB email doesn't just take longer to deliver than a 20 KB email. It hits spam filters differently, eats bandwidth on shared IPs, and increases the chance of a timeout mid-delivery. When you multiply that across 10,000 or 50,000 sends per day, the difference between a lean message and a bloated one is the difference between landing in the inbox and getting throttled at the gate.

Email size and sending limits by provider at a glance#

For high volume senders, message size limits and daily send caps interact directly. A provider might allow 10,000 emails per day, but if each message is 25 MB of base64-encoded images, you'll hit bandwidth throttling long before you reach that number.

That max message size column looks generous until you remember how email encoding works. A 7 MB PDF attachment becomes roughly 9.3 MB after base64 encoding adds ~33% overhead. Your "small" attachment just ate most of your headroom.

Why smaller emails land more often#

Email size affects deliverability in ways that aren't obvious. Spam filters from Google and Microsoft analyze the ratio of image content to text content. An email that's 80% images and 20% text looks like a marketing blast, even if it's a transactional notification with a single logo.

Large MIME parts also trigger additional scanning. Some corporate mail servers decompose and scan every attachment, and they enforce their own size limits that are often well below the provider maximum. Microsoft Exchange Online, for instance, defaults to a 35 MB receive limit per mailbox, but many IT admins set it to 10 MB or lower.

If you're running 50 agent inboxes sending outbound messages, each oversized email compounds the problem. One bounced message per hundred might seem harmless. But bounce rates above 2% start damaging your sender reputation, and oversized messages that get rejected at the receiving end count as bounces.

The base64 tax and how to avoid it#

Every file attachment in an email gets base64-encoded for transport over SMTP. This encoding converts binary data into ASCII text, and it inflates file size by about 33%. A 3 MB image becomes 4 MB in transit. A 10 MB PDF becomes 13.3 MB.

Three ways to reduce this overhead:

1. Link instead of attach. Host files on S3, Google Cloud Storage, or any CDN and include a download link. The email stays under 20 KB, the recipient gets the file, and your SMTP connection closes in milliseconds instead of streaming megabytes.

2. Compress before encoding. If you must attach, compress first. PNGs can often be reduced 40-60% with tools like pngquant or sharp. PDFs can be recompressed with Ghostscript. Do this programmatically before your agent queues the send.

3. Strip inline images. Many HTML email templates include logos, banners, and social icons as inline base64 data URIs. Each one bloats the message body. Replace them with hosted image URLs. Your email drops from 500 KB to 15 KB.

For agents handling email programmatically, this is where an API-first approach pays off. Instead of manually checking each template in an ESP dashboard, your agent can run a pre-send audit: measure the MIME size, strip anything over a threshold, and swap attachments for links automatically.

Sender rotation and size: a combined strategy#

Sender rotation distributes your outbound volume across multiple sending accounts so no single account hits its daily cap. It's the standard playbook for cold outreach at scale. But most rotation setups treat every message as identical, routing them round-robin without considering message size.

That's a missed optimization. If you're rotating across five Gmail Workspace accounts (2,000 sends each, 10,000 total), and half your messages carry 5 MB attachments while the other half are plain text, routing the heavy messages to a single account means that account is pushing 5 TB of data while the others handle kilobytes. The heavy account will get throttled first.

A smarter approach: route by message weight. Plain text messages go through accounts with lower bandwidth tolerance. Heavy messages get spread evenly or routed through accounts on dedicated IPs where bandwidth isn't a constraint. This is the kind of optimization that's hard to do manually but straightforward for an agent with API access to its sending infrastructure.

Dedicated IP vs. shared IP for large messages#

If you're sending over 50,000 emails per day, the dedicated IP question comes up fast. On a shared IP, your reputation depends partly on other senders sharing that IP. If someone else on the same IP is sending 25 MB spam blasts, your lean 10 KB transactional emails get caught in the collateral damage.

Dedicated IPs give you full control over reputation, but they require warming up. A fresh IP with no sending history starts with zero reputation. Most providers recommend starting at 50-100 emails per day and doubling every few days until you reach your target volume. The warm-up period typically takes 2-4 weeks for volumes under 100,000/day.

Message size matters during warm-up more than at any other time. ISPs monitor new IPs closely, and large messages from an unknown sender look suspicious. Keep your warm-up emails small (under 50 KB) and text-heavy. Save the attachments and rich HTML for after your IP has established a sending pattern.

Practical size targets#

Based on what actually performs well at scale, here's what I'd recommend:

Transactional emails (receipts, confirmations, password resets): Keep under 30 KB. These should be mostly text with minimal HTML formatting. No images unless absolutely necessary.

Agent-to-human outreach (introductions, follow-ups, notifications): Under 50 KB. One small inline image at most. If your agent needs to share documents, link to them.

Reports and data exports: Don't send these as attachments if they exceed 2 MB. Generate a download link with a 24-48 hour expiry. The email itself stays tiny, the recipient gets the file, and you avoid the base64 tax entirely.

Bulk marketing (newsletters, announcements): Under 100 KB. This is where most senders go wrong. Marketing emails with hero images, multiple product shots, and embedded fonts routinely hit 500 KB or more. Strip it down. Use hosted images with explicit width/height attributes so the email renders correctly even before images load.

How LobsterMail handles size and rate limits#

LobsterMail's approach is to handle this at the infrastructure layer so your agent doesn't have to think about it. When your agent calls inbox.send(), the platform enforces a 10 MB total message size limit. Attachments over that threshold get rejected with a clear error before the message ever hits the queue.

The daily sending limits are tiered: verified free accounts get 10 emails per day, Builder accounts at $9/month get 500 per day. The limits reset at midnight UTC. If your agent exceeds the limit, it gets a 429 Too Many Requests response with a clear indication of when it can send again. No silent failures, no deferred messages that vanish into a retry queue.

For deliverability, the platform handles SPF, DKIM, and DMARC automatically for every inbox your agent creates. Your agent doesn't configure DNS records or manage authentication. It creates an inbox and sends. The infrastructure handles the rest.

This matters more than it sounds. One of the most common reasons emails get rejected at volume isn't size or rate limits. It's missing or misconfigured authentication. A message from an IP with valid SPF that's signed with DKIM and backed by a DMARC policy is treated fundamentally differently than one without.

What to do right now#

If you're sending more than 1,000 emails per day, audit your average message size. Pull a sample of 100 sent messages and check the MIME size. If the average is over 75 KB, you have room to optimize. If any messages exceed 5 MB, fix those first since they're the ones most likely to bounce or get throttled.

Set up a pre-send check in your pipeline. Before any message gets queued, validate that total size (body plus attachments after base64 encoding) is under your target threshold. Swap oversized attachments for hosted links automatically. This single change will improve your throughput and deliverability more than any sender rotation strategy.

If you're building agents that need to send email without you babysitting the infrastructure, LobsterMail handles inbox creation, authentication, and size enforcement through a single API call. Your agent creates an inbox, sends messages, and the platform manages the limits.