Winmail.dat attachments: cause, impact, and fixes (Microsoft TNEF) Print

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/Exchange. This is not a problem with our mail servers or any standards-compliant MTA. The fix must be applied on the sender’s Microsoft side (Outlook/Exchange settings or policy). Senders should contact Microsoft Support or their IT service provider to implement the changes below.

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, etc.) relay what they receive and do not generate or convert TNEF. If Outlook/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 DKIM.

Why it can happen even when Outlook says “HTML”

Outlook’s “Compose in HTML” does not guarantee that the final wire format is MIME/HTML. TNEF can still be forced by:

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

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/Outlook.

How to confirm it’s 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 references to winmail.dat.
3. If present, the message was sent using TNEF upstream (Microsoft side).

Definitive fixes (sender’s Microsoft side)

Outlook (per-user)

1. 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 Outlook’s Contacts or from the autocomplete card) and ensure it is not set to “Send using Outlook Rich Text Format”. Clear cached entries if needed.

Microsoft 365 / Exchange Online (tenant-wide)

Run in Exchange Online PowerShell (admin):

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

Optionally enforce per partner domain:

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

Review transport rules to ensure none force RTF/TNEF, and verify any third-party connectors aren’t rewriting content types.

Exchange Server (on-premises)

1. Exchange Admin Center → Mail flow → Remote domains → Default: set Use rich-text format to Never.
2. Or via EMS:

Set-RemoteDomain Default -TNEFEnabled $false

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

Group Policy / Legacy Outlook enforcement (optional)

For older fleets, you can enforce TNEF off via policy/registry (example for Office 2016–2021/365):

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

What Noiz can and cannot do

• We can confirm the presence of TNEF in received messages, validate DKIM/DMARC alignment, and show that the message arrived already encoded as TNEF from the Microsoft environment.
• We cannot “convert” or “strip” TNEF safely at the MTA without risking message/attachment damage or signature failures. The correct, standards-compliant fix is to stop TNEF at the source (Outlook/Exchange).

Next steps for senders

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

FAQ

Can Noiz “fix” existing winmail.dat messages?

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

Why do some recipients see attachments fine?

Recipients using Microsoft Outlook/Exchange may parse TNEF correctly, masking the issue. Non-Microsoft clients typically cannot.

Can enabling or disabling TLS/filters on our server help?

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

References (for sender IT teams)

• Microsoft documentation on TNEF and winmail.dat behavior and mitigation in Outlook/Exchange.
• Remote Domain settings (TNEFEnabled) in Exchange Online and Exchange Server.
• Outlook contact property “Send using Outlook Rich Text Format”.

Note: Microsoft has documented this behavior in various support resources for decades; the recommended mitigation is to disable TNEF for Internet recipients and ensure HTML/Plain Text is used on outbound mail.