Winmail.dat Attachments: Why They Appear and How to Stop Them

A client sends a signed contract as a PDF, and the lawyer on the other end gets a file called winmail.dat instead. The PDF is still in there, wrapped in a format that only Outlook reads, and a handful of settings on the sender's side decide whether it happens again tomorrow. This guide explains what a winmail.dat file is, how to open one when you're on the receiving end, and the four places to switch it off, from one Outlook profile to a whole Exchange Online tenant.

What a Winmail.dat File Is

Outlook sends mail in one of three formats: HTML, plain text and Rich Text. The first two travel as ordinary MIME. Rich Text is the odd one out. When Outlook sends it, Exchange packs the message properties into Transport Neutral Encapsulation Format, or TNEF, a Microsoft-specific container that Outlook and Exchange understand and almost nothing else does.

A TNEF message has two parts: a plain text copy of the body, and one binary attachment holding everything else. Microsoft's content conversion reference (updated April 2025) lists what goes in: the formatted version of the message, embedded pictures and Office objects, Outlook-only features such as voting buttons and meeting requests, and the regular file attachments that were on the original message. That binary attachment is usually named winmail.dat. Clients that can't even read the name show it as ATT00008.DAT or ATT00005.eml.

Outlook, Outlook on the web and Exchange unpack TNEF without ever showing it. Gmail, Apple Mail, Thunderbird, most phone clients and most ticketing systems don't. The recipient sees a plain text body and a winmail.dat they can't open, while the PDF they were promised sits inside it.

One more thing sits inside it. Microsoft's message format reference (updated December 2024) notes that the path to the sender's .pst file and their sign-in name are embedded in winmail.dat. Not the password, and not shown on screen, but readable in a text editor. That alone is a reason to stop sending TNEF outside the organisation.

Why Winmail.dat Attachments Appear

TNEF only leaves the tenant when something tells Exchange to keep it. Three settings decide, and Exchange checks them in a fixed order, highest first, per Microsoft's TNEF conversion reference (updated April 2025).

A higher level overrides a lower one. If the remote domain says never, the user's Outlook setting doesn't matter. The defaults are sensible all the way down: follow user settings at the domain, UseDefaultSettings on contacts, and Outlook converting Rich Text to HTML on the way out. Winmail.dat shows up when one of the three has been changed, and the job is finding which.

The case that eats the most tickets is the smallest one. Classic Outlook can hold a format preference against an individual recipient, and Outlook 2010 and earlier exposed it as "Send using Outlook Rich Text format" on the contact. The symptom is specific: one sender, one recipient, winmail.dat every time, while the same PDF reaches everyone else fine. The r/Office365 thread below is that case exactly. The admin had already set the remote domain to never use Rich Text and the problem survived, because the fix was clearing the cached recipient entry, not a server setting.

How to Open a Winmail.dat File

When you're the recipient and can't change the sender, you have three routes.

Open it in Outlook. Any Outlook, including Outlook on the web, reads TNEF natively, so the attachments appear as normal. Forwarding the message to yourself from Outlook re-sends it in HTML, which is why the r/sysadmin thread below ends with a technician discovering that "forward it to yourself" made the PDF reappear. It works. It's also a sign that the sender's settings never got fixed.

Use a TNEF reader. On Windows, several free winmail.dat opener apps in the Microsoft Store unpack the file and hand you the attachments. On a Mac, TNEF's Enough has done the same job for years and gets recommended in the thread. Online decoders exist too, but a winmail.dat can hold a confidential contract, so uploading one to a third-party website is a data-handling decision, not a convenience. Keep that route for files you'd be happy to email to a stranger.

Ask the sender for HTML. Every reader is a workaround. The fix lives on their side, and the next section is the one to send them.

How to Stop Sending Winmail.dat

Four fixes, from the smallest blast radius to the widest. Start where the symptom points.

1. Fix the sender's Outlook. In classic Outlook, File > Options > Mail, set Compose messages in this format to HTML, and set the Internet message format option to Convert to HTML format. Microsoft's own support page now calls Rich Text a legacy format it doesn't plan to improve, and HTML has been the default compose format for years. To do the same without visiting the desk, Microsoft documents a registry value: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences, DisableTNEF = 1 (DWORD), then restart Outlook. With it set, Outlook only uses TNEF when a feature needs it, such as a meeting request. That value is easy to push with Group Policy Preferences or any tool that runs a script per device, and it's the kind of thing useful PowerShell commands cover for a fleet.

2. Clear the recipient. If exactly one recipient gets winmail.dat from exactly one sender, delete that address from the sender's Contacts and from the autocomplete list, then type it fresh. Per the r/sysadmin replies, that clears the stored Rich Text preference, and it matched the r/Office365 outcome too.

3. Fix the contact server-side. If your tenant holds the external address as a mail contact or mail user, set it once for everyone:

powershell
Set-MailContact "jane@partner.example" -UseMapiRichTextFormat Never

The cmdlet reference says Never converts TNEF messages to that recipient to plain text, so pair it with fix 1 where the formatting matters.

4. Fix the tenant. This is the standing answer for a managed tenant, and the one an MSP applies to every client:

powershell
Set-RemoteDomain Default -TNEFEnabled $false
Get-RemoteDomain | Format-Table Name, DomainName, TNEFEnabled

The Default remote domain covers every external domain that doesn't have its own entry, and the remote domain level wins the precedence check, so a stray Rich Text setting in someone's Outlook can no longer leak. If a partner runs Exchange and wants voting buttons and Rich Text intact, add a remote domain for them with -TNEFEnabled $true. Internal mail is untouched: TNEF conversion only applies to recipients outside the organisation. Outlook already converts meeting requests to iCalendar for outside recipients, so calendar invites keep working. Across a client base, OpenFrame can run that Get-RemoteDomain check or the registry read as a script across a client's devices and collect the output, so the audit is a list, not a round of desk visits.

The same precedence logic is worth knowing when you tune the rest of outbound mail, which our guide to email security best practices covers from the DMARC side.

The Short Version

Winmail.dat is Outlook's Rich Text wrapped as TNEF, and it only appears when a sender's setting, a contact's setting or a remote domain tells Exchange to keep TNEF on the way out. Open it with Outlook or a TNEF reader if you're receiving. If you're sending, set Outlook to HTML, clear the cached recipient when it's a single pair, and set the Default remote domain to never use TNEF so the tenant stops caring what any one Outlook says. Then close the ticket for good instead of forwarding the PDF to yourself.

Next, see how the rest of the mail path is locked down in our guide to DMARC records and enforcement.