Preserve the original privately, identify whether the expected part exists, and investigate its packaging, presentation and filename separately before requesting a scoped repair.
An email arriving successfully does not establish that its attachment is present, usable or the file the sender intended. Before asking someone to change mail settings, identify the failure: nothing attached, an unexpected package, an inline image, an unreadable document, or only an unfamiliar filename. These observations lead to different investigations.
Consider a fictional workshop sending a harmless one-page schedule. One recipient sees the schedule; another sees winmail.dat; a third sees a document with a damaged name. This guide proposes a controlled diagnosis for that situation. It does not describe a real mail test or recommend opening an unsolicited file.
Preserve the original and describe the symptom
Keep the original message in the existing protected mailbox. If your organisation permits exporting an original, store it in an approved location with limited access. Work from a copy when making notes. A screenshot can document the display, but it cannot replace the underlying message for a qualified investigation.
Record the sender and recipient client names and versions, approximate send time, which message was selected and the expected document. Ask the sender what they actually attached, rather than assuming every paperclip represents the schedule. Distinguish an original transmission from a later forward that may have a different structure.
| Observed symptom | Next question | Keep separate |
|---|---|---|
| No expected file offered | Does the received original contain a corresponding part? | File size limits or a sender forgetting the attachment |
| winmail.dat offered | Is the sender using a package the receiving client cannot interpret? | A claim that the schedule is definitely recoverable |
| Image appears inside the message | Was this intended as body content or a separate document? | A missing PDF |
| Expected document will not open | Does the saved file match a known good original? | A filename that merely looks odd |
Keep one sample per agreed test and label its outcome immediately. Replacing the evidence with a later successful resend would hide which change mattered and make a recurring problem harder to explain.
For the workshop, the useful incident description is “recipient B receives a package instead of the schedule from the fresh message sent at the recorded time.” “Email is broken” is too broad to assign an owner or recognise a successful repair.
Read packaging separately from the file itself
RFC 2045 separates Content-Type, which describes a part’s media type, from Content-Transfer-Encoding, which describes its transport representation. Parts can have their own headers. Base64 represents data; it does not encrypt the attachment or certify that it is safe.
An authorised mail administrator can inspect the structure with a maintained, approved viewer. Ask for a finding tied to the original: the expected part was present, absent, or could not be interpreted. Avoid copying long encoded content into a public forum or assuming a successful manual conversion establishes the sender’s intent.
RFC 2046 defines multipart boundaries. The mixed subtype can group independent parts; alternative represents different versions of the same information. Therefore, a multipart message is not automatically a message with a downloadable attachment. Count the intended documents, not every structural component.
For a website-generated notification, ask its maintainer to compare the prepared document, the outgoing message and the received original within the approved support process. Keep those stages distinct. A composer preview displaying an attachment is evidence about the preview, not sufficient evidence about the recipient’s copy.
Separate presentation from filename problems
RFC 2183 describes inline and attachment presentation and an advisory filename. Receivers must handle names safely rather than trust directory suggestions or overwrite existing files. The supplied name does not authenticate the file or prove its content type.
Record whether the failure affects display, saving, or opening after saving. A recipient may be able to save the intended document even when the message preview is unhelpful. Conversely, a familiar-looking extension does not justify opening an unexpected file. Verify sensitive or surprising deliveries through an already trusted contact route.
RFC 2231 provides MIME parameter mechanisms for character sets, language and continuations. A malformed-looking name can therefore require a parameter-encoding investigation. Do not transplant a website download-header example into an email generator and assume the two contexts use the same rules.
In the fictional schedule case, compare a simple neutral filename with the original accented name in an authorised test. Keep the document unchanged so the observation isolates naming. If both fail identically, the evidence points away from the name as the only issue; it does not yet identify the cause.
Treat winmail.dat as a compatibility clue
Microsoft’s TNEF documentation describes packaging of MAPI properties that unsupported clients may expose as Winmail.dat or Win.dat. Its cited page covers Exchange Server 2016, 2019 and Subscription Edition. That scope matters: do not apply its server instructions automatically to a cloud tenant.
Ask the sender for a new message using a recipient-compatible format with the intended document attached separately. Use an agreed, harmless sample first if the organisation’s process requires it. A fresh message is easier to compare than a chain of repeated forwards with uncertain transformations.
Do not upload a private message to an unfamiliar “winmail decoder” as a shortcut. It may contain more than the visible schedule. If recovery is necessary, let the authorised support team choose an assessed tool and handling process. Compatibility trouble does not justify disabling attachment scanning.
Keep a recurring repair narrow
Exchange Online remote-domain guidance explains that organisation settings can govern outbound formats despite sender preferences. A change to a default can affect many destinations. Have the responsible administrator identify the actual scope before changing policy, and retain the previous configuration for an approved recovery.
Prepare a support note containing client versions, the symptom, agreed test recipients, a protected original reference and the exact outcome required. Redact unnecessary addresses and message content in any wider copy. Give the administrator access to the unmodified evidence through the approved route if needed; a heavily edited header may be unsuitable for diagnosis.
Accept the recipient’s outcome
- Confirm that the intended recipient receives a fresh, authorised sample.
- Check that the document is identifiable, can be saved when intended and opens in the supported viewer.
- Compare the content with the known source, not just the attachment label.
- Retest an unaffected recipient before accepting a format-policy change.
- Record the scope, remaining unsupported clients and fallback delivery route.
For genuinely large documents, review attachment limits and controlled share links separately. Use the mail-client setup guide when the whole mailbox fails to synchronise, and file checksums when a trustworthy source supplies a comparison value. Each addresses a different boundary from MIME packaging.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RFC 2045: MIME message bodiesChecked Part media types and transfer encoding.
Limits: Encoding is not encryption or a safety assessment. - RFC 2046: MIME media typesChecked Multipart structure and the mixed/alternative distinction.
Limits: A multipart message does not necessarily contain a separate attachment. - RFC 2183: Content-DispositionChecked Presentation and advisory filenames.
Limits: A name does not establish file authenticity; directory suggestions must not be trusted. - RFC 2231: MIME parameter extensionsChecked Character sets and continuations in parameters.
Limits: This is MIME guidance, not an HTTP header recipe. - Microsoft: TNEF conversion optionsChecked TNEF packaging and unsupported-client symptoms.
Limits: The documented server scope is Exchange Server 2016, 2019 and Subscription Edition. - Microsoft: Remote domains in Exchange OnlineChecked Organisation-controlled outbound format policy.
Limits: A broad default change can affect unrelated recipients; no administrative commands are prescribed.