How to test message size and attachment limits?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
You've crafted the perfect email, attached that important PDF, and hit send. Then a bounce comes back: 552 Message size exceeded. Frustrating, right? Knowing how to test for size limits before it happens to a real message is a skill worth having.
Here's how to test message size and attachment limits properly.
Check the EHLO SIZE parameter first
When your sending server connects to a receiving server, it says hello with an EHLO command. The receiving server often responds with a SIZE extension that tells you its maximum message size. If you see SIZE=26214400 in that response, that's a 25MB limit (26,214,400 bytes divided by 1,048,576 bytes per megabyte). Not every server advertises this, but when they do, it's the most reliable signal you'll get. You can learn how to read a full SMTP exchange in the guide on reading SMTP transcripts.
Test progressively with real messages
If the server doesn't advertise a SIZE parameter, you can find the limit by sending test messages of increasing size to a test account at that provider. Start small, then work up in increments (5MB, 10MB, 15MB, 20MB, 25MB). Note exactly where the rejection happens. Do this with a few different attachment types too, since some servers scan attachments differently.
And one thing that trips people up: attachments get Base64-encoded when they travel over email, which adds roughly 33% to the raw file size. A 15MB PDF attachment actually becomes around 20MB in transit. So if a server has a 25MB message limit, your practical attachment ceiling is closer to 18MB before you add in the email body and headers.
Know the common limits going in
- Gmail and Google Workspace: 25MB total message size
- Outlook and Microsoft 365: 25MB by default (admins can lower this)
- Yahoo Mail: 25MB
- Corporate mail servers: often 10MB or less, sometimes as low as 5MB
Read the error codes when a rejection happens
Size-related rejections come with predictable error codes. 552 means the message exceeded the server's size limit. 5.3.4 is the enhanced status code for a message that's too big. You'll often see plain text like "message size exceeds limit" in the bounce body too. These are hard bounces, so don't retry them with the same oversized message.
The practical rule
Keep messages under 10MB if you need wide compatibility across corporate mail servers. If you're sharing large files, put them in Google Drive or Dropbox and link to them. Don't embed download URLs directly in the message body either. Security gateways flag those and they'll hurt your deliverability. A clean link to a cloud folder is the better move every time.
If you're doing deeper SMTP diagnostics and want to test message delivery end to end, Mailtrap gives you a safe sandbox to inspect everything without hitting real inboxes.
Stuck on a specific bounce or delivery failure? Our SOS hotline is free and we actually pick up.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
