The Hidden Impact of Message Size on SMTP Throughput

• October 2022
• Engineering Memo · External Release

Message size is rarely considered a deliverability variable — operators focus on IP reputation, domain reputation, authentication, and list quality while treating message size as a content design concern. But message size has a direct operational impact on SMTP throughput: larger messages take longer to transmit, reducing the number of messages that can be delivered per SMTP session per unit time. At high volume, the cumulative throughput impact of message size can be significant — a message that is 3x larger than necessary reduces throughput by up to 30-40% compared to an optimised size, requiring more IP capacity and longer delivery windows to deliver the same campaign volume.

How Message Size Affects Throughput

The throughput impact of message size operates through the DATA transmission phase of the SMTP session. Once the EHLO, MAIL FROM, and RCPT TO handshake is complete, the message body is transmitted as a continuous data stream until the final period line (or BDAT completion for CHUNKING). The time required to transmit the message body is directly proportional to the message size divided by the available network bandwidth. For a 100Kb message on a 100Mbps network connection: 100Kb ÷ 100Mbps = 0.8 milliseconds. For a 1Mb message: 8 milliseconds. For a 10Mb message: 80 milliseconds.

These transmission times appear trivial per message, but the cumulative impact across millions of messages is significant. For a campaign of 1 million messages at 100Kb average size vs 1Mb average size: at a sustained delivery rate of 50,000 messages per hour, the 100Kb campaign completes in 20 hours; the 1Mb campaign requires the same 20 hours of connection time but transmits 10x more data per session, potentially generating more mid-session connection closures (ISPs terminate connections that have transmitted too much data or remained open too long) and reducing the effective messages-per-session rate.

At high volume, the throughput impact of message size also interacts with ISP DATA rate limiting. Some ISPs apply not just per-session message limits (max-msg-per-connection) but per-session data volume limits — closing connections after a specific number of kilobytes or megabytes have been transmitted. A session that can deliver 200 messages at 50Kb average size (10Mb total) may only deliver 100 messages at 100Kb (also 10Mb total) before the ISP's per-session data limit is reached. This data-volume-per-session limit, which most operators do not account for, is the mechanism through which message size reduces effective session efficiency at the ISPs that apply it.

What Drives Message Size in Commercial Email

Embedded images: The most common source of large message sizes. A promotional email with 5 product images embedded at 200Kb each produces a 1Mb+ message. Base64-encoding the images (required for embedding in MIME email) increases image file size by approximately 33% — a 200Kb JPEG becomes 267Kb in the encoded message. Optimising images for email (targeting 50-100Kb per image after Base64 encoding) reduces the per-image contribution to message size by 60-70%.

HTML complexity: Extensively structured HTML with large inline CSS blocks, complex table layouts, and verbose attribute markup can contribute 50-200Kb to message size independently of images. A cleanly written HTML email with external CSS references (or minimal inline CSS) may be 15-30Kb; a complex promotional template with extensive inline styling may be 100-200Kb for the HTML structure alone. Auditing the HTML template's size and eliminating unnecessary markup and inline styling reduces the HTML-structural contribution to message size.

Attachments: PDF and document attachments are the highest-impact message size source. A 2Mb PDF attached to a campaign message creates a 2.7Mb+ email after Base64 encoding, plus the HTML body. Attachment-heavy campaigns have dramatically lower throughput than equivalent text or HTML-only campaigns. The deliverability recommendation: link to hosted documents rather than embedding them as attachments, eliminating the attachment contribution to message size entirely.

Tracking pixels and external resource URLs: Multiple tracking pixels, extensive UTM parameter strings in all links, and high numbers of external resource references contribute marginally to message size individually but can collectively add 5-15Kb to an otherwise lean message. For most programmes, this contribution is minor; for very high-frequency transactional email (millions of messages per day), even small per-message size optimisations produce meaningful cumulative throughput improvement.

Message Size and ISP Reception

ISPs have maximum message size limits that, if exceeded, produce 5xx rejection responses. Gmail's limit is 25Mb (including all attachments and headers); Yahoo's is 25Mb; Microsoft's is 35Mb (for consumer addresses) and 150Mb (for Exchange Online). These hard limits are rarely encountered by typical promotional emails — they become relevant for campaigns with large attachments or emails with many embedded high-resolution images. Staying well below these limits (targeting under 1Mb total message size for campaigns) ensures that message size never triggers ISP rejection.

Below the hard rejection threshold, ISPs may also apply soft filtering based on message size. A 5Mb promotional email may receive higher spam scoring at ISPs that use message size as a spam signal proxy — very large messages are less common among legitimate commercial senders and more common among spam campaigns that embed many images to obscure text-based content signals. Keeping commercial email messages under 500Kb avoids this soft scoring while maintaining sufficient content richness for promotional email purposes.

The message size optimisation target for commercial email: aim for 100-300Kb per campaign message. This range allows for reasonable use of product images (2-3 images optimised to 50-80Kb each), well-structured HTML (30-50Kb), and personalisation tokens without triggering any ISP soft scoring or producing meaningful throughput reduction from message size. Messages above 500Kb should be reviewed for size optimisation opportunities before deployment, particularly for high-volume campaigns where the cumulative throughput impact is most significant.

Message size is a deliverability variable that sits at the intersection of content design and infrastructure operations. The content team controls image quality, HTML complexity, and attachment use; the infrastructure team experiences the throughput consequences in the accounting log's delivery timing data. Making message size optimisation a shared responsibility — with infrastructure-team visibility into average message size per campaign and feedback to the content team when sizes exceed the 300-500Kb range — bridges this divide and keeps message size from silently reducing the throughput capacity that the IP pool provides. The infrastructure is sized for the expected message volume and connection capacity; message size is the variable that determines how much useful work that capacity actually delivers.

Measuring Message Size Impact in the Accounting Log

The accounting log captures message size for each delivery event when PowerMTA is configured to include the msg_size field in the accounting log format. With message size data in the accounting log, the ETL pipeline can calculate per-campaign average message size and correlate it with per-campaign throughput (messages per connection per hour) and delivery window (time from campaign injection to campaign completion). This correlation reveals whether message size is contributing to delivery window extension for specific campaign types.

The analysis query: compare campaigns with average message size below 200Kb vs above 500Kb, controlling for other variables (same ISP, same sending IP, same time of day). If the 500Kb+ campaigns consistently show 20-30% longer delivery windows than equivalent 200Kb campaigns for the same ISP at the same volume, message size is a throughput variable that the content team should address for those campaign types. The accounting log data provides the evidence to make the case for image optimisation and HTML cleanup as operational improvements with measurable throughput benefit, not just content design preferences.

Including average message size in the standard campaign performance report — alongside delivery rate, inbox placement rate, and per-ISP deferral rate — creates the shared visibility between content and infrastructure teams that makes message size optimisation a collaborative practice. Content teams that understand that a 1Mb campaign requires 40% longer to deliver than a 250Kb equivalent will make different image optimisation and attachment decisions. Infrastructure teams that can point to specific campaign delivery window data to support size optimisation requests have a stronger case than those making general best practice arguments without programme-specific evidence.

The Practical Optimisation Checklist

Before deploying any campaign with average message size above 300Kb, a quick optimisation checklist can reduce size to under 200Kb with minimal content impact: (1) Check image sizes: are any product images above 100Kb after Base64 encoding? If so, resize or re-compress to 50-80Kb target. (2) Check HTML structure: is the HTML template generating unnecessary whitespace, redundant tags, or inline CSS that could be consolidated? A 5-minute template audit often reveals 20-40Kb of unnecessary markup. (3) Check for attachments: any PDF or document that can be hosted and linked rather than attached? Linking saves the full attachment size per message. (4) Check for large CSS blocks: if the same CSS is repeated in every message's <style> block rather than being shared across templates, consolidating the CSS reduces per-message size.

These four checks take 15-20 minutes per template review and can typically reduce message size by 30-50% for campaigns above the 300Kb threshold. The throughput improvement from staying below 250Kb average message size — 15-20% faster delivery at high volume — is worth this investment for programmes sending above 500,000 messages per campaign. For smaller campaigns, the absolute throughput difference is small enough that content quality priorities should outweigh size optimisation concerns.

Message size is the hidden throughput variable that content teams control and infrastructure teams experience. Making it visible through accounting log data, shared reporting, and collaborative optimisation practices bridges the content-infrastructure divide and produces email campaigns that are both visually effective and operationally efficient. The infrastructure capacity that size optimisation preserves is capacity that delivers more messages per hour, shortens campaign delivery windows, and reduces the queue depth pressure that large messages at high volume inevitably generate. Small messages, delivered quickly, at volume: that is the throughput ideal that message size optimisation serves.

The Transactional Email Exception

Transactional email has different message size considerations than promotional email. Password reset emails should be minimal (2-5Kb of plain or simple HTML text) — they do not require product images, and adding them increases size without adding value to a time-sensitive functional message. Order confirmation emails may legitimately include a summary table with small product thumbnails, but even these should target under 100Kb. Invoice and receipt emails that include PDF attachments are the most common transactional size concern — a 50Kb receipt PDF adds only moderate size, but attaching multiple-page invoices can push transactional emails above 1Mb.

The throughput consideration is less critical for transactional email (lower volume means smaller absolute throughput impact) but the user experience consideration is more critical: a large transactional email may trigger Gmail's "This message seems too large to display" warning, preventing the recipient from seeing the confirmation immediately. Keeping transactional emails under 100Kb (excluding unavoidable PDF attachments) ensures the fastest possible load time in every recipient's email client and the most reliable inbox display across all email clients and devices.

For PDF-heavy transactional programmes (invoicing, legal documents, insurance policies), hosting the documents as downloadable links rather than attachments reduces per-message size dramatically while improving the user experience (the document is available via a persistent link rather than as an attachment that may be deleted or lost). The infrastructure cost of hosting PDF documents is minimal relative to the per-message size reduction and the improved recipient experience.

Capacity Planning and Message Size

When sizing an IP pool for a new programme, the planned average message size should be an explicit input in the capacity calculation. A programme planning to send 5 million messages per day at 250Kb average size requires different IP pool capacity than one planning the same volume at 50Kb average size — because the DATA transmission time for 5Mb of message content per 20 messages at 250Kb is longer than for 1Mb per 20 messages at 50Kb, reducing the effective messages-per-session rate and therefore requiring more sessions (more concurrent connections) to achieve the same throughput.

Including message size in capacity planning is the operational practice that prevents programmes from discovering after deployment that their planned IP pool capacity is insufficient for their actual message sizes. A pool sized for 50Kb messages may underperform when 250Kb messages are delivered at the same injection rate — not because the pool is too small in terms of IP count, but because the DATA transmission time reduces the effective throughput below the pool's theoretical capacity.

Message size is a throughput variable that is easy to optimise (design decisions), easy to measure (accounting log msg_size field), and easy to overlook (it is not a reputation variable in the traditional sense). Bringing it into the operational visibility framework — tracking it per campaign, including it in capacity planning, and making content teams aware of its infrastructure impact — converts an often-ignored detail into a managed operational parameter. That management produces faster delivery windows, more efficient use of IP pool capacity, and campaigns that arrive in the inbox before their content has lost its time-sensitive relevance. Small messages deliver quickly; that matters for every time-sensitive commercial email the programme ever sends.

Image Hosting as a Message Size Strategy

The most impactful message size optimisation for promotional email is replacing embedded images with hosted images. An embedded image (included as a MIME attachment with a Content-ID reference) adds its full file size to every copy of the message delivered; a hosted image (referenced by URL and loaded by the recipient's email client) adds only the URL string (typically 60-120 characters) to the message. For a campaign with 5 embedded images at 150Kb each, switching to hosted images reduces the message from 750Kb+ to 30-50Kb — a 15-20x size reduction.

The image hosting approach has one significant deliverability consideration: the image loading by the recipient's email client generates an HTTP request to the hosting server, which allows the programme to track image opens (the tracking pixel technique). But email clients that block remote image loading by default (Outlook, Apple Mail with Mail Privacy Protection) will not load the hosted images, which means the message displays without images for these clients unless they enable image loading. For programmes where visual design is critical to conversion, testing the message display with images disabled ensures the text content and layout structure are sufficient to communicate the promotional content even without images.

For programmes serving audiences where a significant percentage use image-blocking clients (B2B audiences often use Outlook with images blocked by default), a hybrid approach — embedding the most critical images (hero image, logo) and hosting supplementary images (product thumbnails) — balances message size with visual experience across different client configurations. The critical images embedded for guaranteed display, the supplementary images hosted for size efficiency: this hybrid approach keeps the message under 200Kb while ensuring the key visual elements display correctly regardless of the recipient's image loading configuration.

Message size management is the operational practice that makes the infrastructure's throughput capacity fully available for delivery rather than partially consumed by excessive DATA transmission overhead. It requires collaboration between content teams (who control image quality, HTML complexity, and attachment decisions) and infrastructure teams (who observe the throughput consequences in the accounting log). When that collaboration is active — with message size tracking in campaign performance reporting and shared ownership of the optimisation target — the messages the programme sends are both visually effective and operationally efficient. That combination is the goal: compelling content, delivered quickly, at scale, without unnecessary infrastructure cost. Message size is the variable that connects content quality to delivery efficiency. Manage it with the same discipline as every other deliverability variable.

The DATA phase is where message size becomes throughput. Every kilobyte the content team saves is a kilobyte the infrastructure does not have to transmit. At scale, those kilobytes add up to campaigns that deliver faster, windows that close sooner, and capacity that serves more volume without additional IP investment. Optimise message size as seriously as any other deliverability variable -- the throughput returns are real and compounding.

Size is a design decision that becomes a throughput outcome. Make it consciously, measure the outcome in the accounting log, and manage the relationship between the two as the operational discipline that keeps content creativity and delivery efficiency working together rather than at cross-purposes.

Summary: The Message Size Management Framework

The message size management framework for commercial email programmes has four components. First, set a per-campaign size target: 100-250Kb for standard promotional emails, under 100Kb for transactional emails, and a maximum of 500Kb for any single-campaign deployment. Second, include average message size in the pre-campaign review checklist — before a campaign is injected into the MTA, its average message size should be calculated and compared against the target. Third, add msg_size to the PowerMTA accounting log field list and include average message size per campaign in the operational reporting dashboard alongside delivery rate and per-ISP deferral rate. Fourth, establish a quarterly message size review — comparing the average message size trend across campaigns over the past quarter and identifying any campaigns or templates that systematically produce above-target sizes.

This framework requires minimal ongoing effort but produces consistent, measurable throughput benefits for programmes that implement it. The 15 minutes per campaign to check message size before deployment, the 5 minutes per week to review the message size trend in the dashboard, and the 30 minutes per quarter to review size across the campaign portfolio are the complete operational investment. The return is campaigns that deliver faster, delivery windows that close earlier, and IP pool capacity that serves more volume without additional infrastructure investment. Message size management is the low-investment, high-compound-return operational discipline that most programmes are not currently applying. Apply it, and the infrastructure's throughput potential will be more fully realised with every campaign the programme sends.

Small messages. Fast delivery. Full throughput. That is the message size management goal in three sentences. Everything else in this note is the detail that supports it.

The hidden impact becomes visible in the accounting log. Make it visible; manage it explicitly; and the throughput the infrastructure provides will fully serve the volume the programme needs to deliver.

Size matters. Manage it.

Every byte delivered is a byte that had to be transmitted. Minimise the unnecessary ones.