Email Attachments: Size, File Safety and Link-Based Alternatives

TL;DR

• Check both the provider's attachment limits and the recipient system's total-message limits before sending large files.
• Encoding, message bodies and headers add overhead, so the file's size on disk is not the final email size.
• MailBlastr accepts up to 25 MB per attachment and 40 MB of decoded attachment bytes in total, but those acceptance caps do not guarantee downstream delivery.
• Use a controlled download link when it better fits file size, access control or revocation needs, and test the recipient's actual experience.

Understand which size is being limited

An attachment passes through several representations: the original file, an API request, a MIME email and the receiving mailbox's processing system. Each can have its own limit. A file that passes one check may fail a later one.

MailBlastr documents a 25 MB per-file cap and a 40 MB total attachment cap measured on decoded bytes. Base64 increases the request representation by roughly one third. These are provider acceptance rules, not a promise that a mailbox accepts a message containing that much material. See MailBlastr attachments.

The distinction also exists in underlying transport systems. Amazon SES documents a 40 MB maximum for messages through its v2 API or SMTP after encoding, while other API variants have different limits. Its quota applies to the complete message representation, not just the original files. See SES service quotas.

Budget for the complete message

Suppose a report contains several images and a large PDF. Adding their file sizes gives only a starting point. Encoding, HTML, plain text, inline assets and headers also occupy space. Leave a practical margin instead of designing every send to sit at a documented maximum.

Treat file size as a validation step before enqueueing the message. That lets the application give a useful explanation immediately rather than discovering the problem inside a background worker after the user has left.

Store the measured size and file identity with the notification. If the file changes between validation and sending, validate the actual bytes again. A URL pointing to “latest-report.pdf” is not a stable attachment identity when its contents can be replaced.

Choose attachment or link according to the task

Attachments can be convenient for small documents people need to keep, such as a simple receipt. A download link may be better for a large report, a frequently updated file or a document whose access should remain controlled by the application.

Links create their own responsibilities. Decide whether the recipient must sign in, how long access lasts and whether the link can be revoked. Explain that behavior in the message. A user should not discover that a promised report expired before they had a reasonable chance to retrieve it.

For sensitive documents, avoid assuming that an unguessable URL provides the same control as authenticated access. Consider forwarding, browser history, logs and shared inboxes. Select the access model that fits the document and the recipient, then test it with the intended account.

Validate files as well as names

A filename extension is not enough to establish a file's type or safety. Validate the content according to your upload and document-handling policy, restrict unnecessary formats and scan files where your workflow requires it. Preserve a clear filename that helps the recipient understand what they are opening.

Do not automatically fetch arbitrary user-supplied attachment URLs from privileged servers. Restrict allowed storage locations and apply network protections in the application. A convenient “attach this URL” feature should not become a way to request internal network resources.

MailBlastr supports file content and URL-based attachment workflows, but the application still owns the decision about which file is appropriate to send. Avoid including confidential information just because a background job has access to it.

Handle rejection without repeated oversized sends

An invalid or oversized attachment needs a changed payload, not an endless retry. Record the error against the notification and decide whether the product should offer a smaller export, a secure link or a clear failure message.

If a provider accepted the message but a receiving system later rejected it, preserve the bounce evidence. The receiving system may impose a stricter policy or reject a file type. A provider-side success response alone cannot establish recipient acceptance.

Do not silently substitute a public link for a private attachment. If you provide a fallback, it should preserve the intended access requirements and explain the change to the user. Keep the revised notification's identity and payload history clear so support can understand what was actually sent.

Test representative files before release

Test a small valid attachment, a file near your application's own limit, several attachments whose combined size exceeds that limit and an unsupported format. Include filenames with spaces and non-ASCII characters, and verify the received filename and content type.

For links, test expired access, the wrong signed-in account and a recipient opening the message on another device. For attachments, inspect the actual received message in the clients your audience uses.

Add these checks to your email testing checklist. A dependable document email delivers a usable file through an appropriate access path; passing a byte-count validation is only one part of that result.