Users receiving Winmail.dat instead of real attachments

winmail.dat attachmentIt seems that some non – Exchange or Office 365 users are getting winmail.dat attachments in emails rather than the actual attachments. I cannot take the credit for this solution as I found it on a technet forum, but I wanted to add my two cents to the topic.

I have a client that previously had an Office 365 account. This user since retired and no longer needs the full Office 365 account however the user would like any email forwarded to his AOL account. When an email is sent it hits the Office 365 servers and is then forwarded to a Contact set up n Exchange.  When the email is received in AOL any attachments are gone and replaced with the winmail.dat attachments.

Information from Technet (Thanks Kent)

The problem: Some email recipients receive winmail.dat attachments in place of correctly-encoded MIME attachments from users running Outlook 2016/Windows 10/Office 365 hosted mail. They can’t open the faulty attachments and (in our case) the result is grumpy clients.

The cause: The issue is that Exchange can still encode attachments as RTF rather than MIME. There’s no need for this in a hosted SaaS email service in 2016 – it’s a legacy piece of Exchange functionality that’s probably kept around in the code-base for reasons known only to Microsoft. But it’s definitely a pain in the neck for those of us who don’t need backwards-compatibility to dinosaur-era Exchange servers.

The solution: You’ll undoubtedly come across various articles and suggestions that you need to indulge in a whole bunch of PowerShell jiu jitsu in order to fix the problem. In our case this didn’t work – or at least not for any length of time. Thankfully, there is an (apparent) fix lurking in the Office 365 Admin GUI. It goes like this:

  1. Login to your Office 365 Portal (portal.office.com) using your Admin credentials.
  2. Click the Admin icon.
  3. Flip down the Admin sub-menu from the left-hand menu, and click Exchange. This will take you to your hosted Exchange admin page.
  4. Click Mail Flow from the left hand menu.
  5. Click Remote Domains from the top menu line. This will allow you to configure a specific set of rules for the offending recipient domains.
  6. Click the Plus icon above the name field. This brings up a separate page that allows you to start the process of configuring the rules for the recipient domain(s).
  7. Give the configuration a suitable name for the rule you’re adding.
  8. Add the fully-qualified domain name for the recipient that’s having the problem with the winmail.dat attachments. As far as I can tell, the configuration should support wildcards – YMMV.
  9. About two-thirds of the way down the page, you’ll find the “use rich text” setting – it will default to “Follow user settings”. Change this to “Never”.
  10. For extra credit, you can change the default MIME encodings to Unicode (UTF-8) instead of Western (ISO), as in my experience it seems to transition through foreign mail servers better – but again, YMMV.
  11. Hit the Save button.

Of course, you’ll need to add each domain individually if you have lots of recipients with the winmail.dat problem. The obvious fix is to use the “default” rule to set “use rich text” to “Never” – although in our case our Exchange instance already had this setting, but the problem persisted. Go figure.

This may not work for everyone or for everyone but It Fixed it for me.