Winmail.dat Attachments: Cause, Impact and Fixes (Microsoft TNEF)

Summary: If your recipients see a single winmail.dat file instead of normal attachments, the message was sent in Microsoft's proprietary TNEF format by Outlook or Exchange. This is not a problem with the Noiz mail servers or any standards-compliant MTA. The fix must be applied on the sender's Microsoft side (Outlook or Exchange settings or policy). If you are the sender, or are helping the sender, apply the changes below; if the changes do not resolve it, contact Microsoft Support or the sender's IT provider.

Last reviewed: 27 July 2026, against Microsoft Exchange Online and current classic Outlook for Windows. This guide is written for Noiz hosting and is kept current against Microsoft's TNEF and remote-domain behaviour. It complements, and does not replace, the official Microsoft documentation linked below.

Official Documentation Reference

• Remote domains in Exchange Online (message format and RTF/TNEF behaviour)
• Manage remote domains in Exchange Online (admin centre and PowerShell steps)
• Set-RemoteDomain (the TNEFEnabled parameter)

What is winmail.dat?

winmail.dat appears when Microsoft Outlook or Exchange encapsulates rich text formatting and attachments using Transport Neutral Encapsulation Format (TNEF). Most non-Microsoft mail clients (Apple Mail, Gmail, Thunderbird, webmail, many mobiles) cannot interpret TNEF, so they display a single opaque file named winmail.dat instead of the intended attachments.

Is this a server or MTA issue?

No. Standards-compliant MTAs (Postfix, Exim, Sendmail and others) relay what they receive and do not generate or convert TNEF. If Outlook or Exchange emits TNEF, the message leaves the Microsoft environment already incompatible with many recipients. There is nothing a downstream server can change without risking message corruption or breaking the message's DKIM signature.

Why it can happen even when Outlook says "HTML"

Outlook's "Compose in HTML" setting does not guarantee that the final wire format is MIME or HTML. TNEF can still be forced by:

• Outlook or Exchange contact records flagged to send using Rich Text Format (RTF).
• Exchange Remote Domain policies that allow or force RTF/TNEF.
• Transport rules (mail flow rules), shared mailboxes, or cached address properties overriding user preferences.
• Legacy compatibility modes or add-ins that trigger RTF/TNEF on certain messages.

Good to know: TNEF is a behaviour of classic Outlook for Windows (the Win32 desktop app). The new Outlook for Windows and Outlook on the web do not send RTF/TNEF, so if a sender can reproduce the problem, it is almost always coming from the classic desktop client, a contact flag, or a tenant-level Remote Domain policy.

Who is affected

• Recipients using non-Microsoft clients (Apple Mail, Gmail web, Thunderbird, most mobile apps).
• Mixed environments where only some recipients use Microsoft 365 or Outlook.

How to confirm it is TNEF

1. View the original message source of an affected email at the recipient end.
2. Look for MIME parts with content types like application/ms-tnef, or a part named winmail.dat.
3. If either is present, the message was sent using TNEF upstream, on the Microsoft side.

Definitive fixes (on the sender's Microsoft side)

Classic Outlook for Windows (per user)

1. Go to File → Options → Mail.
2. Under Compose messages, set Compose messages in this format to HTML (or Plain Text).
3. Under Message format, set When sending messages in Rich Text format to Internet recipients to Convert to HTML format (or Plain Text).
4. Open the contact properties for any frequently emailed recipient (in Contacts, or from the recipient's card) and make sure the email address is not set to Send using Outlook Rich Text Format.
5. Clear the cached recipient entry. The auto-complete (nickname) cache can retain the old RTF flag even after you fix the contact. Delete the recipient from the auto-complete list (highlight it in the address suggestions and press Delete) and re-add them, then send a fresh test message.

Microsoft 365 / Exchange Online (tenant-wide)

Run in Exchange Online PowerShell as an administrator:

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

Setting TNEFEnabled to $false is the equivalent of Never use Rich Text Format for that remote domain. To target a single partner domain instead of everything, create or edit a remote domain for it:

Set-RemoteDomain "partnerdomain.com" -TNEFEnabled $false

You can also do this in the Exchange admin centre: Mail flow → Remote domains, open Default (or the partner domain), and under the message format options set Rich Text Format (RTF) to Never. Then review your mail flow rules (transport rules) to make sure none force RTF/TNEF, and verify any third-party connectors are not rewriting content types.

Exchange Server (on-premises)

1. In the Exchange admin centre, go to Mail flow → Remote domains, open Default, and set Rich Text Format (RTF) to Never.
2. Or run the equivalent in the Exchange Management Shell:

Set-RemoteDomain Default -TNEFEnabled $false

Audit transport rules and any address policies that could re-enable RTF/TNEF.

Group Policy or registry enforcement (optional, older fleets)

For managed desktop fleets, you can enforce TNEF off via policy or the registry. The example below covers Office 2016 through Microsoft 365 Apps (all use branch 16.0):

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Preferences]
"DisableTNEF"=dword:00000001

What Noiz can and cannot do

• Noiz can confirm the presence of TNEF in received messages, validate DKIM and DMARC alignment, and show that the message arrived already encoded as TNEF from the Microsoft environment.
• Noiz cannot convert or strip TNEF safely at the mail server without risking damage to the message or attachments, or breaking the sender's signature. The correct, standards-compliant fix is to stop TNEF at the source, in Outlook or Exchange.

Next steps for senders

1. Apply the Outlook or Exchange changes above.
2. Retest by sending a fresh message with a simple attachment (for example a PDF) to an external, non-Microsoft mailbox.
3. If TNEF continues, contact Microsoft Support or your IT provider to audit Remote Domain policies, transport rules, address book and contact flags, and connectors that may still be forcing TNEF.

Troubleshooting

Symptom: one recipient keeps getting winmail.dat after the fix. The recipient's address is almost certainly still cached with the RTF flag in the sender's auto-complete list. Delete it from the suggestions and re-add the contact, then send a fresh test.

Symptom: only some external recipients are affected. The default Remote Domain is likely set to Follow user settings for RTF. Set it to Never (-TNEFEnabled $false) so it no longer depends on each user's Outlook configuration.

Symptom: the sender uses the new Outlook or webmail and still sees the problem. The new clients do not emit TNEF, so the RTF/TNEF is being applied by a tenant policy, a contact flag, or a transport rule. Focus the investigation on Exchange, not the desktop client.

FAQ

Can Noiz fix existing winmail.dat messages?

No. Noiz can confirm the cause, but the only correct resolution is to stop TNEF at the sender. Some third-party tools can extract the content from a winmail.dat file, but that is a workaround, not a fix.

Why do some recipients see the attachments fine?

Recipients using Microsoft Outlook or Exchange can parse TNEF correctly, which masks the issue. Non-Microsoft clients typically cannot.

Can enabling or disabling TLS or filters on the Noiz server help?

No. TLS and standard content filters do not convert Microsoft's TNEF to MIME. Attempting to rewrite the content on the server side risks corruption and signature failures.

Need a hand?

If you receive winmail.dat files on a Noiz mailbox and need help confirming the cause before you go back to the sender, contact Noiz support with a copy of an affected message (including full headers) and Noiz will verify whether it arrived as TNEF and confirm that the fix belongs on the sender's Microsoft side.