An email attachment is a file sent as a separate part of an email message, such as a PDF invoice, spreadsheet, image, calendar file, or document. Email systems use MIME (Multipurpose Internet Mail Extensions) headers and encoding to describe the file, carry it safely through mail servers, and tell the recipient’s email client to display it as a downloadable attachment.

Why email attachments matter

Attachments make email useful for many high-value workflows. A transactional email may include an invoice, receipt, shipping label, policy document, ticket, or report. A sales or account-management email may include a proposal, statement of work, or product specification. In a campaign context, an attachment can offer a resource that is genuinely useful to a narrowly defined audience.

But an attachment also changes the technical and risk profile of a message. It makes the message larger, gives security systems more content to inspect, and asks the recipient to take an additional action: download and open a file. Those factors do not mean that attachments are inherently bad for deliverability. A legitimate, expected PDF receipt is normal email behavior. The problem is that attachments are frequently used in phishing and malware campaigns, so mailbox providers and enterprise security tools inspect them carefully.

For senders, the important question is not simply, “Can we attach this file?” It is: Is a file attached to the email the safest, clearest, and most reliable way to help this recipient complete the task?

That question has practical consequences:

A large file can push the total message over a sending or receiving limit.
A risky file type can be blocked before delivery or stripped from the message.
A broken MIME structure can cause an attachment to disappear, download with the wrong name, or render incorrectly.
An unexpected attachment can make a legitimate email look like a phishing attempt.
A public link may be better than an attachment for large files, frequently updated files, or resources that need access control.

In short, attachments are a delivery design decision as well as a content decision.

How an email attachment works under the hood

Email was designed around text messages, not arbitrary binary files. MIME extends email so one message can contain several pieces of content with their own headers, media types, and transfer encodings. A message with both a plain-text body, an HTML body, and a PDF attachment is therefore not one undifferentiated blob. It is a structured collection of MIME parts.

The role of multipart messages

A typical message with an attachment uses the MIME media type multipart/mixed. “Mixed” means the message contains different parts that should be handled as separate items, such as the email body and a file.

A simplified structure looks like this:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="message-boundary-42"

--message-boundary-42
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Your invoice is attached.

--message-boundary-42
Content-Type: application/pdf; name="invoice-1042.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="invoice-1042.pdf"

JVBERi0xLjQKJcTl8uXr...

--message-boundary-42--

The boundary is a delimiter that separates each part. Every opening boundary must match the boundary value declared in the parent Content-Type header, and the final boundary ends with --. If the boundary is malformed, duplicated within content, or omitted at the end, email clients and filtering systems may fail to parse the message correctly.

When an email has both HTML and plain-text versions, the usual pattern is more deeply nested: a multipart/alternative section for the two body formats sits inside an outer multipart/mixed container, alongside the attachment. The recipient’s email client selects the most suitable body representation and then exposes the file as a separate attachment.

Content type tells clients what the file is

The Content-Type header identifies the media type of an attachment. Common examples include:

application/pdf for PDF documents
text/csv for CSV exports
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet for modern Excel workbooks
image/jpeg for JPEG images
image/png for PNG images
text/calendar for calendar invitations or .ics files

A correct content type helps clients choose the right handling behavior and helps security tools understand what they are scanning. Do not label an arbitrary binary file as application/pdf just because you want it to look safer or more familiar. A mismatch between a declared type, a filename extension, and the file’s actual bytes can create compatibility problems and may trigger security scrutiny.

Content disposition tells clients how to present it

Content-Disposition supplies presentation guidance. The two values most relevant to senders are attachment and inline.

Content-Disposition: attachment tells the recipient’s email client to present the part as a file that normally requires a deliberate download or open action. It is the appropriate default for documents, exports, statements, and files the recipient should save.

Content-Disposition: inline is generally used for content intended to appear automatically within the email, such as a logo or explanatory image. Inline is not a cosmetic replacement for an ordinary attachment. It changes the recipient experience and often requires a related MIME structure plus a Content-ID reference from the HTML body.

A filename parameter is also important. It is what many clients show to recipients and what gets suggested during download. Use a short, descriptive, trustworthy filename such as acme-invoice-1042.pdf, not a vague or intimidating filename such as document_final_NEW_urgent.pdf.

MIME encoding and the real size of an attachment

The file size on your server is not necessarily the size that travels through email. This is one of the most important details in attachment delivery.

Binary data, such as a PDF or spreadsheet, is commonly transferred with Base64 encoding. Base64 represents every three bytes of source data with four printable characters. Before line breaks and message headers, that means an encoded file is roughly one-third larger than the original binary file.

MIME Base64 also wraps encoded output into lines, traditionally no longer than 76 characters. Those line endings add a small additional overhead. As a practical rule, budget roughly 37% more than the original file size for a Base64-encoded attachment, then leave room for the message body, headers, MIME boundaries, and any inline images.

Worked size example

Assume you want to send a PDF that is exactly 10,000,000 bytes.

Base64 expands the binary data to 4 × ceil(10,000,000 ÷ 3) characters.
That produces 13,333,336 Base64 characters.
MIME line wrapping adds approximately 350,000 more bytes of line endings at 76-character intervals.
Before adding attachment headers, boundaries, and the email body, the encoded attachment is about 13.68 MB.

So a 10 MB PDF does not behave like a 10 MB email attachment in transit. It behaves more like a 13.7 MB MIME payload, plus the rest of the message.

This is why a file that appears to be safely below a mailbox provider’s message-size limit can still cause a rejection. Limits usually apply to the complete message, not just the original file sitting on disk.

Message-size limits are end-to-end limits

Every hop can impose a different maximum. Your sending platform may accept a message that the receiving server later rejects. An intermediary security gateway may enforce a smaller limit than the recipient’s mailbox provider. A recipient’s organization can also set its own rules.

For example, personal Gmail accounts have a 25 MB attachment sending limit, while Google Workspace limits can be configured by an administrator. That does not create a universal 25 MB deliverability guarantee for application email. Your application still needs to account for Base64 expansion, total message size, recipient-side policies, and the limits of the infrastructure used to send the message.

As a conservative operating practice, do not design a recurring email workflow around attachments that are close to common message caps. If a document may grow over time, the workflow may work during testing and then fail unexpectedly when a month-end report, image-rich PDF, or combined export becomes larger.

Attachments and email deliverability

An attachment does not automatically send a message to spam. Mailbox providers evaluate many signals, including sender authentication, sending reputation, recipient engagement, content, links, message construction, and security risk. Still, attachments can affect several of those signals indirectly.

Security scanning is more intensive

Attachments are a major malware and phishing vector. Providers and enterprise email gateways scan file types, archive contents, macros, file signatures, URLs embedded in documents, and suspicious relationships between the message and the attachment.

A message that contains a PDF invoice from a recognized sender, sent after a recipient makes a purchase, is easy to explain. A message with an unexpected archive, a password-protected document, or a vague file named Payment_Update.exe is much harder to trust. Security controls can block it, quarantine it, show a warning, or deliver it with reduced confidence.

Google explicitly blocks many potentially dangerous file types and can block certain files even when they are included inside compressed archives. Gmail also identifies password-protected archives with archived content as a security concern. The lesson for legitimate senders is simple: do not try to work around attachment security controls through file renaming, compression, or password-protected archives. Use a secure download experience instead.

Larger messages create more opportunities for failure

A larger message takes longer to upload, scan, relay, download, and render. That does not necessarily mean it will land in spam, but it increases operational fragility. Mobile recipients may postpone downloading it. Corporate gateways may scan it asynchronously. A recipient may see a notification but not get the value of the message until they have a suitable connection and device.

For transactional email, that can damage the user experience. A customer who needs a receipt immediately may be better served by a compact email with a clearly labeled link to a secure invoice page, plus an attached PDF only when the file is expected or legally useful.

Unexpected attachments can suppress engagement

Campaign performance is affected by trust and friction. Recipients often hesitate to open files from unfamiliar senders, especially when the message does not explain why the file is included. Even if the email reaches the inbox, an attachment can make the call to action less clear than a button leading to a landing page or hosted document.

Consider the difference between these two messages:

“Your November usage report is attached.”
“Your November usage report is ready. Review highlights in this email, then download the complete CSV from your account.”

The first is appropriate if the recipient explicitly expects a recurring report by email. The second can be better when the resource is large, sensitive, refreshed regularly, or useful only after authentication.

Authentication still matters

A technically perfect attachment cannot compensate for weak sender identity. Use a properly authenticated sending domain and align the visible sender with the business and workflow the recipient expects. SPF, DKIM, and DMARC do not make an attachment safe by themselves, but they help receiving systems evaluate whether the message is authorized to use your domain.

This is particularly important for invoice, payroll, legal, account, and security-related messages. Those categories are frequently impersonated. A recognizable From address, consistent domain, clear explanation, and predictable timing make a legitimate file-based email easier for recipients and filtering systems to assess.

When to attach a file and when to send a link

There is no universal rule that links are always better than attachments. A PDF receipt attached to an order-confirmation email can be practical, expected, and easy to archive. An .ics calendar attachment can be the normal way to add an event. A small report for a customer who opted into emailed reports may be the most convenient format.

The decision should depend on the file’s purpose, size, sensitivity, lifespan, and recipient expectation.

Attach a file when the attachment is the product

An attachment is often the right choice when all of the following are true:

The recipient expects the file as part of the workflow.
The file is small enough to leave substantial room below likely message-size limits.
The format is common and safe, such as PDF, CSV, PNG, JPEG, or ICS.
The file is final rather than frequently updated.
The recipient benefits from saving, printing, forwarding, or retaining it offline.
The email clearly states what the file is and why it is included.

Examples include an invoice PDF after purchase, a boarding pass, a signed copy of an agreement, a customer-requested export, or a calendar invitation.

Prefer a secure link when the file is large or sensitive

A hosted download is usually the better choice when a file is large, dynamically generated, frequently changed, access-controlled, or potentially risky to deliver directly. It is also appropriate when you need revocation, audit logging, expiration, or the ability to correct a document after sending.

A good download-link flow has a few characteristics:

The email explains exactly what the link leads to.
The link uses your recognizable domain or a clearly associated download domain.
Access is authenticated or protected with a time-limited token when the content is sensitive.
The destination page is mobile-friendly and says what will be downloaded.
The sender can revoke the link if it is shared accidentally or the document is replaced.

Avoid turning a link into a disguised attachment. A vague button labeled “Download” in an unexpected email can create the same trust problem as a vague file. Use precise language such as “Download your March invoice PDF” or “View the secure tax document in your account.”

Common attachment delivery problems and their causes

An attachment-related failure can occur at several stages: your application may not construct the message correctly, the sending provider may reject it, a receiving server may refuse it, a security system may quarantine it, or the recipient’s client may display it poorly.

The total message is too large

This is the most common technical problem. Teams calculate only the source file size and forget encoding overhead, message headers, body content, and other parts. Multiple small attachments can also become one large message.

Fix: calculate against the encoded total, not the source files alone. Establish a conservative maximum source-file size for your application. If your files are close to that threshold, generate a secure link instead of attaching them.

The file type is prohibited or suspicious

Executable files, scripts, disk images, certain installers, and archives containing blocked files are often rejected. Password-protected archives can also raise security concerns because they prevent ordinary content inspection.

Fix: do not attempt to bypass the block by changing a filename extension or nesting the file inside an archive. Provide the software, installer, or sensitive resource through an authenticated download page with appropriate malware scanning and user guidance.

MIME boundaries or headers are malformed

A missing closing boundary, a mismatched boundary value, invalid line endings, or an incorrectly encoded body part can make the attachment unreadable. The recipient may see an attachment of zero bytes, a file with garbled contents, raw Base64 text, or no attachment at all.

Fix: use a proven MIME library or an email API that builds attachment MIME parts for you. If you send raw SMTP messages, test the exact raw source in multiple clients before production. Do not hand-roll MIME parsing or Base64 formatting unless you have a specific reason and strong test coverage.

The content type is wrong

If a spreadsheet is labeled as a generic binary stream, some clients may still open it, but the recipient experience is less predictable. If an attachment claims to be a PDF but contains other data, scanners and clients may distrust it.

Fix: derive the content type from trusted file inspection or a controlled allowlist, not solely from user-provided filename extensions. Keep the actual file type, Content-Type, and filename extension consistent.

The filename creates confusion

Long, ambiguous, duplicated, or alarming names can reduce confidence. Names with strange Unicode characters, multiple extensions, or claims of urgency resemble patterns users are trained to avoid.

Fix: use stable, human-readable filenames. Include the document type and a useful identifier, such as receipt-order-87342.pdf or usage-report-2026-03.csv. Avoid special characters that may be replaced or mishandled by older clients.

The attachment is legitimate but unexpected

A recipient may report or delete an email simply because they do not remember requesting the document. That hurts engagement and can contribute to future filtering problems if similar messages are frequently marked as spam.

Fix: set the expectation before sending. On the relevant product page, preference center, or workflow screen, say that the user will receive a PDF, CSV, or calendar file by email. In the email itself, state why the attachment is present in the first visible lines.

Building reliable attachment sending into an application

Reliable attachment delivery starts before an email API call. Your application needs a deliberate policy for file intake, storage, validation, encoding, sending, and observability.

Validate files before they reach the mail layer

Do not trust only the name supplied by a browser upload or upstream system. Validate the file’s actual type, size, and source. If users upload documents that you later email to someone else, add malware scanning and content controls appropriate to the risk of the workflow.

A practical intake policy may include:

An allowlist of accepted content types.
A maximum original-file size below the email delivery threshold.
File-signature validation where applicable.
Malware scanning before the file becomes available for sending.
Filename normalization and removal of unsafe path elements.
Clear retention and deletion rules for stored files.

This is not only a deliverability concern. It is also basic application-security hygiene.

Separate message creation from file storage

For recurring reports and customer documents, store the authoritative file in your application or document system first. Then decide at send time whether to attach it, link to it, or do both. That design gives you options when a file grows too large, a provider rejects it, or a customer asks for a replacement copy.

It also improves incident response. If a document is sent in error, a secure link can be revoked. An attachment already delivered to a recipient’s mailbox cannot be recalled reliably.

Use an email provider’s supported attachment mechanism

If your email provider offers a structured attachment field in its API, use its documented method instead of manually assembling multipart MIME. If you use SMTP or a raw-message endpoint, use a mature library that creates correct headers, boundaries, and transfer encodings.

For implementation details, review the platform’s email API reference and setup guides before choosing between structured API attachments and raw MIME generation. The right path depends on whether you need simple files, inline images, custom headers, signed messages, or exact control over message construction.

Keep the main email useful without the file

An attachment should add value, not contain the only meaningful explanation. Include a concise summary in the email body: what happened, which account or order it concerns, what the file contains, and what the recipient should do next.

For example, do not send a blank email with only report.pdf. Instead, write: “Your weekly inventory export for Warehouse 4 is attached. It includes 1,842 active SKUs and reflects data through March 31. You can also generate a fresh export from your dashboard.”

That context reduces suspicion, helps recipients who cannot download the file immediately, and makes support issues easier to resolve.

Measuring attachment performance and reliability

“Attachment rate” is not a universal deliverability metric in the way that bounce rate or complaint rate is. Different teams may use the phrase to mean different things: the percentage of messages that include files, the percentage of recipients who download a file, or the percentage of attachment messages that fail.

Define the measurement precisely before acting on it.

Useful attachment metrics

For an application that sends attachments, track at least these measurements:

Attachment send rate: messages with one or more attachments divided by total messages sent.
Attachment rejection rate: messages rejected for size, content, or policy reasons divided by attempted attachment messages.
Attachment-related bounce rate: hard or soft bounces tied to message-size or content-policy responses divided by attachment messages sent.
Hosted-download completion rate: completed file downloads divided by delivered emails containing a download link.
Median and 95th-percentile message size: useful for spotting unexpectedly large exports or image-heavy files.
Support-contact rate: attachment-related support tickets divided by attachment messages delivered.

Do not assume that open rate proves an attachment was useful. Email open tracking is inherently imperfect, and a recipient can read an email without downloading a file. If you use secure hosted links, download events give a more direct signal of whether recipients obtained the document.

A worked rejection-rate example

Suppose your system attempts to send 8,000 monthly statements with PDF attachments. Of those, 120 are rejected before delivery because the encoded message exceeds an enforced size limit.

The attachment rejection rate is:

120 ÷ 8,000 × 100 = 1.5%

A 1.5% rejection rate is not just a number to report. It means 120 customers did not receive a statement through the intended channel. Investigate whether the issue is concentrated in a template version, an image-heavy statement design, a specific customer segment, or a sudden increase in source-file size.

A more useful follow-up metric is the recovery rate: how many of those 120 recipients successfully receive a replacement message with a secure download link? That ties operational monitoring to the customer outcome.

Testing attachments before a full send

Testing needs to cover more than “the file appears in my inbox.” Different clients, gateways, and recipient environments handle attachments differently.

Start with a test matrix that includes common mailbox providers, a corporate Microsoft 365 or Google Workspace account if available, desktop and mobile clients, and a message source inspection tool. Test using realistic production-sized files, not only a tiny sample PDF.

What to check in every test

Confirm the following:

The email body renders correctly in plain text and HTML.
The attachment is visible and has the expected filename.
The attachment opens successfully and its contents are intact.
The declared media type matches the file’s actual type.
The total message stays below your operational threshold.
Inline images display as intended and do not appear as unwanted downloadable files.
The message remains understandable if images or the attachment are unavailable.
Security tools do not flag a legitimate test file unexpectedly.
Delivery events and failures are captured by your sending system.
A fallback link or retry path works when attachment delivery fails.

Test filename edge cases too. Try spaces, long but reasonable names, non-ASCII characters if your audience needs them, and names generated from customer data. A filename that works in one client may display poorly in another if it is not encoded and sanitized correctly.

For campaigns, run a small controlled send before sending to the full audience. Attachments add a variable that preview tools cannot fully replicate, especially when enterprise security gateways are involved.

Practical attachment checklist

Before shipping an attachment-based email flow, use this checklist:

Is an attachment genuinely better than a secure hosted download?
Will the recipient expect this exact file from this sender at this time?
Is the original source file comfortably below your maximum safe size?
Have you budgeted for Base64 expansion, line breaks, headers, and other MIME parts?
Is the file type common, safe, and allowed by your product policy?
Does the real file type match the filename extension and declared Content-Type?
Is the filename concise, descriptive, and free of confusing multiple extensions?
Is the message authenticated and sent from a recognizable domain?
Does the email body explain why the file is attached?
Have you tested the raw message and file behavior across representative clients?
Can you detect attachment-specific rejections and recover with a link-based fallback?
If the document is sensitive, do you have a safer authenticated delivery option?

An attachment that passes this checklist is much more likely to be useful, trustworthy, and operationally reliable.

Conclusion

An email attachment is a MIME message part that carries a file alongside the body of an email. The fundamentals are straightforward, but reliable implementation requires attention to MIME structure, content types, Base64 overhead, recipient limits, security scanning, sender identity, and recipient expectation.

The best attachment strategy is usually conservative. Send small, familiar, expected files with clear context. Use correct MIME metadata and a tested sending workflow. Measure size-related and policy-related failures separately from general delivery metrics. For large, sensitive, or changeable documents, use a secure, clearly explained download link instead of forcing the file through email.

When an attachment is the right delivery format, make it feel intentional: the recipient should know what it is, why it arrived, and why it is safe to open.

FAQ

What is the difference between an attachment and an inline image in email?

An attachment is normally presented as a separate downloadable file, often with Content-Disposition: attachment. An inline image is intended to display inside the email content, typically with Content-Disposition: inline and, in HTML email, a content ID reference. A file can technically be sent either way, but the presentation should match the recipient’s expected experience.

Do attachments hurt email deliverability?

Not automatically. Legitimate, expected files can deliver normally. However, attachments increase message size and security scrutiny, and suspicious or prohibited file types can be blocked or quarantined. Strong authentication, clear context, safe file formats, correct MIME construction, and conservative file sizes reduce risk.

How large can an email attachment be?

There is no single internet-wide limit. The maximum depends on the sender, sending provider, intermediate gateways, and recipient server, and it applies to the total encoded message rather than only the original file. Because Base64 commonly adds about 37% after MIME line wrapping, keep original files well below any hard limit.

Why does a 10 MB file create a much larger email?

Binary files are commonly Base64 encoded so they can travel safely through email systems. Base64 converts each three bytes of source data into four characters, increasing size by about one-third before line wrapping and MIME overhead. A 10 MB source file can become roughly a 13.7 MB attachment payload in transit.

Should I zip an attachment to improve deliverability?

Usually no. Compression may reduce the size of some files, but archives can look riskier to recipients and security filters. Archives containing blocked file types may still be blocked, and password-protected archives can prevent normal inspection. Use a secure hosted download for risky, large, or sensitive material instead.

What Is an Email Attachment? MIME, Size Limits, and Delivery