What is a Winmail.dat File And Why Only the Sender Can Stop It

A winmail.dat is not a file anybody meant to send. It is what a mail client shows when a message arrives wrapped in Microsoft packaging that the client cannot open. The attachments the sender chose are usually inside it. Nothing the recipient does will stop the next one arriving.

Almost everybody who searches for an answer here is on the receiving end. The cause sits entirely on the sending side. So there are two jobs rather than one. Getting your attachments out is available to you. Making it stop is not. Knowing which is which saves a great deal of time. Unlike the formats people are usually handed, this one arrives without anybody choosing to create it.

What Is Actually in the File

Outlook has features that ordinary internet mail has no field for. Voting buttons, meeting request details, embedded objects, Rich Text formatting that goes beyond what HTML carries. Underneath they are MAPI properties, the same kind Outlook stores against every message it holds. Rather than drop them, Outlook packages the whole lot into one binary block and attaches it.

Microsoft calls that packaging Transport Neutral Encapsulation Format. The same thing appears in Microsoft documentation as Outlook Rich Text Format and as Exchange Rich Text Format, which is worth knowing when a support article seems to be discussing something else. The file it produces is named winmail.dat, occasionally win.dat. It travels alongside a plain text version of the message, inside what is otherwise an ordinary EML that any client can parse.

Nobody inside the Microsoft world sees any of this. Every version of Outlook unpacks the package on arrival. Outlook on the web, which people still call Outlook Web App, goes further and translates it back into MAPI properties before rendering the message properly. Gmail, Apple Mail and Thunderbird have no idea what to do with it. That split is why a sender can produce these for months without knowing. Nobody inside the organisation sees a problem and nobody outside it mentions one.

Why It Happens to One Person And Not Another

Nothing about this feels predictable from the outside. It becomes predictable the moment you know where Outlook looks.

Outlook does not pick a message format per message. It picks per recipient, checking more than one place as it goes. Microsoft sets out the order plainly. The general setting everybody adjusts first is the one that loses.

Meeting invitations have a setting of their own. An invitation can arrive as winmail.dat even when everything above is set correctly, because calendar items follow a separate rule. File then Options then Calendar has an option to use iCalendar format for external recipients. It needs turning on separately.

Replying can reintroduce it on its own. A reply to a message that came in as Rich Text tends to go back out the same way, whatever the default says. So a thread can run cleanly for weeks and then produce the file the moment somebody replies to the wrong message in it.

Why the Recipient Cannot Fix It

Every decision described above is made before the message leaves the sending organisation. By the time it reaches an inbox the packaging is already applied.

The default was supposed to prevent this. Microsoft documents Exchange as converting these messages to HTML for external recipients unless told otherwise. So a winmail.dat arriving is not the ordinary outcome of Rich Text. It means something overrode a setting that exists precisely to stop it, which is why the fix is a search for what overrode it rather than a single switch.

The middle column and the right column belong to different people. That is the whole difficulty. It also explains why the search everybody runs returns advice written for somebody else.

The mail server is not the cause. Standards compliant servers relay what they are handed and change nothing about it. Hosting providers spend a fair amount of time explaining this, because the recipient blames their own provider and the provider had no part in it.

How to Prove Where the Problem Is

One check settles it in less time than the conversation about whose fault it is.

Open the original source of the message rather than the message itself. Every mail client offers this somewhere, usually as view source or show original.

Content-Type: multipart/mixed;
  boundary="----_=_NextPart_001_01D8"

Content-Type: text/plain; charset="us-ascii"
  [the message, stripped of formatting]

Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="winmail.dat"

The part typed application/ms-tnef is the answer. Where that appears, the packaging was applied upstream. No configuration at the receiving end put it there.

What Each Side Should Actually Do

The two jobs are different, so it helps to know which one you are doing.

read the file with a
  TNEF capable tool
extract the attachments
keep the plain text body
tell the sender, once

set the default to HTML
clear the autocomplete
  entry for that person
check their contact record
ask the mail admin about
  the domain policy

For a whole organisation there is one switch. An administrator can set rich text to never for external domains, which stops the file regardless of what any individual saved against a contact. That is the fix that holds when hundreds of contact records cannot be audited one by one.

Set-RemoteDomain -Identity Default -TNEFEnabled $false

Get-RemoteDomain -Identity Default | Select TNEFEnabled
  confirms it applied

Set-MailContact -Identity "name" -UseMapiRichTextFormat Never
  for one stubborn contact rather than the whole domain

The same thing is available without PowerShell. Exchange Admin Center, then Mail flow, then Remote domains, then Default, where the rich text setting offers Never.

Why the Problem Is Slowly Solving Itself

The format is on its way out at the client end. New Outlook for Windows offers no Rich Text option at all. Neither does Outlook on the web, so anybody composing in either one cannot produce this however their contacts are stored.

What remains is classic Outlook, where the option is still present and still the default for anyone whose settings were carried forward from an older install. That is a shrinking population rather than a stable one, which means the volume of these files is falling on its own.

Shrinking is not the same as gone. The senders still producing them are the ones on long lived installs with contact records dating back years, which is exactly the profile of an established business writing to its customers. The problem is getting rarer and more concentrated at the same time.

How It Compares With MSG

TNEF is a wrapper rather than a storage format, which puts it in a different category from the files people usually mean by a mail format.

Both exist because Outlook holds more about a message than internet mail was built to carry. Both solve that by packaging the surplus in a Microsoft specific form. The difference in the last row is what makes MSG an inconvenience and TNEF an argument between two organisations.

Reading the contents without Outlook is a parsing problem rather than a mail problem. Our viewers handle it on your own machine, which matters when the file arrived from outside and nobody wants to upload it anywhere. Where the attachments then have to end up somewhere organised, the converters take that leg.