locked
winmail.dat rears its ugly head - Office 365/Outlook 2016/Win10 RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    2
    Sign in to vote

    Hi,

    I've been bounced to this forum from the Office 365 forum, to try and get a resolution to this persistent winmail.dat issue. This has now persisted for more than two months, and our company is increasingly looking like clowns in front of our customers.

    Here's the original issue:

    We're getting persistent problems with one of our users sending attachments from Outlook 2016/Win 10 to a client on Gmail/Mac OS10.10/Apple Mail, where all attachments appear as the dreaded winmail.dat files.

    I've run the (I can't insert the link because of yet another Microsoft account mess-up) fix twice to no avail on the Microsoft-hosted Exchange instance.

    Also of note:

    - We only have one PC running Outlook 2016 (all other users are on Mac)

    - The PC user is able to send attachments to other internal Exchange-based accounts without problems, and no errors occur when internal Mac users read the messages using Apple Mail

    - There are no problems reported from any external recipients using PCs, irrespective of mail server platform (including Gmail)

    - There are no problems sending attachments from Outlook 2016/Mac to the problematic Gmail/AppleMail account

    - There are no problems sending attachments from the offending account using OWA

    The version number of Outlook is 16.0.6366.2056, and a check reveals that it's the latest version - no newer updates are available.

    It would be nice to actually get some forward progress on this - so far, this is the third Microsoft forum I've logged the issue with, and there have been two separate tickets raised on two Help Desks. 

    Thanks .... Kent

    Monday, January 18, 2016 10:06 PM

Answers

  • Question
    Sign in to vote
    20
    Sign in to vote

    We appear to have found the solution - which I'm posting here to (hopefully) save some other poor b*stard from having to wade through weeks of poor documentation, support calls and forum posts.

    The problem: Some email recipients on Mac OS X using Apple Mail and Gmail 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.

    In my view, the likely cause is that the Office 365 Exchange instance isn't respecting the encoding preferences in the Outlook 2016 client - in which case it's a Microsoft bug. Feel free to fix it, guys.

    Hope this helps someone.

    Cheers ..... Kent

    • Marked as answer by Steve Fan Tuesday, February 2, 2016 8:22 AM
    Monday, January 25, 2016 1:10 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Kent

    The issue is due to is due to Office365 setting the default attachment format to TNEF.

    The following article should help you fix the issue.  Its old but been updated recently
    http://blog.powerbiz.net.au/office-365/fixing-the-winmail-dat-attachment-problem-in-office365

    Regards

    Matthew


    Matthew Kaye

    Monday, January 18, 2016 10:36 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Kent,

    The Winmail.dat file is used to preserve Rich Text formatting. Outlook uses it when sending a Rich Text-formatted message. During transport, the content of the message may be changed, preventing the receiving client from being able to read the formatting instructions. In other cases, the receiving client (Apple Mail) does not use or recognize the winmail.dat file.

    To resolve this issue, the sender needs to re-send the message in plain text format. See a detailed description in the following articles:

    https://support.microsoft.com/en-us/kb/278061

    https://support.apple.com/en-in/HT201773

    http://www.slipstick.com/problems/outlook-is-sending-winmail-dat-attachments/

    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Regards,

    Steve Fan
    TechNet Community Support

    Please mark the reply as an answer if you find it is helpful.

    If you have feedback for TechNet Support, contact tnmff@microsoft.com.
    Tuesday, January 19, 2016 6:40 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Matthew,

    Thanks for the reply. I've walked through the Powershell settings on the Office 365 server on two occasions now, once with Microsoft support looking over my shoulder, and the TNEF flag is set correctly ... but the problem persists. Any ideas?

    Regards ..... Kent

    Tuesday, January 19, 2016 9:13 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Steve,

    I'm aware of the unfortunate role of RTF and the TNEF problem ... I last had to deal with it more than a decade ago, so it's disappointing that Microsoft have not successfully solved it on what should be their flagship SaaS service.

    However, the suggestion that the user move to plain text is simply unworkable in today's business world - nobody wants to revert to the functionality of AOL circa 1997. This is clearly an interaction between a Microsoft app running on a Microsoft OS connected to a Microsoft mail service, so in my view the obligation is on Microsoft to sort out the issue - given that we are paying good money for every single component of the chain.

    Moving to plain text isn't a solution - it's an excuse. All solutions will, however, be welcomed.

    Regards ..... Kent

    Tuesday, January 19, 2016 9:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Sorry Kent

    This is has worked for us.

    Not sure what else to suggest other than turning other than toggling it on and off.

    Regards

    Matthew

    Matthew Kaye

    Tuesday, January 19, 2016 9:56 PM
  • Question
    Sign in to vote
    20
    Sign in to vote

    We appear to have found the solution - which I'm posting here to (hopefully) save some other poor b*stard from having to wade through weeks of poor documentation, support calls and forum posts.

    The problem: Some email recipients on Mac OS X using Apple Mail and Gmail 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.

    In my view, the likely cause is that the Office 365 Exchange instance isn't respecting the encoding preferences in the Outlook 2016 client - in which case it's a Microsoft bug. Feel free to fix it, guys.

    Hope this helps someone.

    Cheers ..... Kent

    • Marked as answer by Steve Fan Tuesday, February 2, 2016 8:22 AM
    Monday, January 25, 2016 1:10 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Glad to hear that you have found the solution. Thank you for sharing your experience here.

    Regards,

    Steve Fan
    TechNet Community Support

    Please mark the reply as an answer if you find it is helpful.

    If you have feedback for TechNet Support, contact tnmff@microsoft.com.
    Tuesday, February 2, 2016 8:22 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hey Kent,

    Thanks for sharing mate, I've used your instructions and have a very happy client now! - You're was the only solution which I could find online which explained the issue and nailed the solution.

    Cheers!
    Jay from NZ. (Welly being Wellington I hope :) )

    Tuesday, April 12, 2016 3:27 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Guys,

    Could this be a problem with Microsoft's own server as well? I have a Hotmail account that was recently migrated to Microsoft Exchange and now gmail/mac recipients get a winmail.dat file attached. This happens even with no sent attachment and just 'Test' in the body. Tried the suggestions on my Outlook 2016/Win 10 client to compose/format in plain text and HTML, checked recipient's properties and reg entry for DisableTNEF. None seem to work.

    If it is the server that's overriding my client settings and needs changing as per Kent, how do I get that done?

    Thanks, Mike.

    Monday, August 1, 2016 2:38 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    So far, this has worked for me!  I've been plagued with this problem for years with my Office 365 account.  And my wife has a Gmail account so it's been a pain in the butt.  Thanks again!
    Wednesday, September 7, 2016 6:52 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Kent,

    Thank you so much for posting this!  I've also tried all the fixes I could find and nothing would work until I saw this.  I had checked the default remote domain rule and it looked good, so I passed it up.  I never considered it wasn't working properly.  Thank you so much!

    Isaac

    Thursday, September 15, 2016 3:22 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Didn't work for me :(
    Tuesday, September 20, 2016 2:28 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    This does not solve the issue at all. The properties in Outlook application is ignored.
    Tuesday, October 25, 2016 6:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    None of these options worked for me.

    I am an Outlook 2016 user connected to outlook.com.

    Tuesday, November 22, 2016 2:52 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I have the exact same problem, but my situation (like others in this thread) is that I am running Outlook 2016 as my client connected to my outlook.com account.

    Interestingly, this issue did not exist before my outlook.com account was migrated to Office 365.

    Once I detached my Outlook 2016 instance, created a new profile, and re-attached to the Exchange server, that's when everything went to hell.

    The problem is that as outlook.com users, we have zero control over the server and its behavior.

    Can someone from Microsoft resolve this issue? I have many friends and colleagues who are going ballistic due to this issue.

    Tuesday, November 22, 2016 2:55 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I contacted Microsoft Support on this specific issue and opened a case.
    Tuesday, November 22, 2016 5:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    If you get a solution post it here please. I know someone with the same issue and it has been going on since the migration to O365 for outlook.com (account is setup as MAPI was using EAS on old system).
    Saturday, November 26, 2016 5:15 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I will certainly stay posted to this thread. I started dealing with this issue only within the last couple of weeks. Even wasted an hour with some pathetic excuse of a support call. I'm running Outlook 2016 and have been using since the earliest version.....Hope we get a resolve soon.
    Wednesday, November 30, 2016 8:25 AM
  • Question
    Sign in to vote
    1
    Sign in to vote

    Kent,

    I have implemented your workaround discussed above for the past couple of months. While I agree with others that this is not a solution, it has worked up to this point; However, I recently had a customer complain that the winmail.dat file has reared its ugly head once again. I will provide the settings that are applied to their domain in the "Remote Domain" section in the mail flow section of the exchange site.

    *.thisisadomain.com

    Allow only external Out of office replies

    Allow automatic replies

    allow automatic forwarding

    allow delivery reports

    allow non-delivery reports

    user rich-text format: never

    Unicode (UTF-8)

    Unicode (UTF-8)

    Please let me know if anything above is wrong or if there is something else that you know about that we could try!

    Thank you!

    Tuesday, December 13, 2016 8:13 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi everybody,

    We use EOL in my company.

    One user, who usually sends emails to a recipient at me.com (an Apple domain), told me the destination had the winmail.dat issue.

    It happended from Outlook client, not from OWA. A new profile created in a different computer did
    the same.

    On the other hand, several workmates who send emails to the very same destination, had no problem at all.

    I compared with PS hand to hand the user with trouble to another one. I couldn't find any differences.

    I found this thread and applied Kent's and Cliff's workaround successfully.

    Thank you all!

    Best regards,

    Daniel


    Friday, January 27, 2017 2:14 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello All,

    Yep! It is the transfer from Outlook.com to Outlook Mail - and why the heck MS had to perform that little circus trick is a question for the ages - and the creating of a new profile that is the problem.

    My husband just changed me over today and now every email he gets from me has the winmail.dat attachment! 

    Microsoft, on their page that explains the process of the changeover says they are "aware of the problem" and are looking for a solution.  This has been ongoing for months.  Remind me again just how many employees MS has, and how many billions they earn?  And the problem is not yet fixed?

    Well, I am aware of the problem now too - and I can fix it really easily.  By using another mail service.  I don't have to use Outlook.com/Mail or whatever MS want to call it this week.  And I won't, either.  Gmail, here I come!

    I wish you all luck.

    Thursday, February 9, 2017 7:29 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello, we maybe encounter similar issue. Some of our customers using Office 365 start see after last builds Office 2016 strange things about sending e-mails with PDF attachments.

    Outside world complain, that they receive winmail.dat instead of original e-mail. I know, there are programs how to read this type of attachment and recover message but, it is not good for users and experience.

    What is strange in this issue, is that at Office 365 side, the TNEF format is disabled (set to "Never") in all Remote Domains. Also registry key to disable TNEF on Outlook 2016 side are set correctly. All name cache was deleted and records in address book check for settings. All of them are correct. But other side still receive winmail.dat.

    The combination, which we tracked are:

    • Sender: Outlook 2016 with PDF attachment, at Windows 10 from Office 365
    • Recipient: Outlook, every version, iOS and macOS and Windows, on Office 365 or different mail server

    Do you see some other things to look at?

    • Edited by KazzanMVP Thursday, February 9, 2017 10:22 PM Formatting
    Thursday, February 9, 2017 10:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Same Problem here... any solutions jet? At the moment i have to use the Windows 10 integrated "Mail" Programm to send attachments to "non outlook users". I have the feeling that Microsoft wants to force users to upgrade to a business office 365 contract...

    regards, fabian
    Wednesday, February 22, 2017 10:53 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Kent, you are a legend.  Thank you for coming back to report this.  The only thing I did differently was disable RTF in all domains.  I'll report back if that's a bad idea but honestly... why RTF in 2016.

    Friday, February 24, 2017 4:50 PM
  • Question
    Sign in to vote
    2
    Sign in to vote

    As you say, this seems to have just reared it's head again.  I have been happily sending normal emails to people with word and pdf attachments, now all the apple users (phone and macs) are getting DAT files.

    Really is ridiculous.

    Monday, March 6, 2017 2:20 AM
  • Question
    Sign in to vote
    1
    Sign in to vote
    Same here, just started this month.  The fix might work for office365 but not for a @live.com account.  such a pain in the butt, moving to gmail looks like the better option.
    Friday, March 24, 2017 8:28 PM
  • Question
    Sign in to vote
    1
    Sign in to vote
    I registered for a free "@outlook.com" user name/email account years ago, several weeks before Microsoft had even activated the outlook.com service. That free account has proven extremely functional and valuable. It's worked flawlessly across many platforms: Windows 2000, XP, 7, and 10; not to mention my iPhone 4S and 5, my iPad Mini, my Nokia 9300 Communicator, Nokia N900, and Nokia E7-00 (all pre-Microsoft Windows phones), and even my old HTC mobile phone running Windows Mobile 6.5 Professional.(which fortunately was NOTHING LIKE Windows Phone 7 or 8) .The great thing was that the account worked perfectly in EAS mode to sync my email, contacts and calendar across all my devices, including the Apple and Nokia phones. Last week I took on a project requiring me to enroll for a paid Office 365 ProPlus account, and I began using the desktop version of Outlook 2016 provided with that account. Nothing but problems with attachments! It's all due to the settings on the outlook.com accounts, and MS is well aware of the problem. In the meantime, I have reverted to using Thunderbird as my desktop mail client (which performs actions a little slower than Outlook 2016, I believe, but JUST WORKS). I can send attachments using Thunderbird, which all my recipients that were receiving only winmail.dat files from Outlook 2016, now receive perfectly. So my solution has been to vote with my feet and my cash. I planned to use Office 365 Pro Pus mostly for the Outlook desktop client. IBut Thunderbird works much better for email, and (SURPRISE!) my email, contacts and calendar have always sync'd perfectly on (sorry to say but true) my APPLE products. Having close to 800 contacts with extensive embedded data including long text notes, and maintaining an off-line mirror of my on-line mailbox which has something like 1500 Mail folders and nested sub-folders totaling many GB, I was really looking forward to using Outlook 2016, since I have missed using Outlook since some years back, when I had stopped using Outlook 2007. Oh well...
    Monday, April 17, 2017 10:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    ATTN: MICROSOFT - Please fix this issue, we are all sick & tired of having bad experiences with your product. 
    Monday, May 29, 2017 7:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Can I add my request in here for a fix for this problem from Microsoft. I'm using a Hotmail.com account (and have been for many, many years) - I'm using it with the Office Outlook client (and its a personal account, not a business one) - I hesitate to say which version because Microsoft seems to make it almost impossible to find out but as far as I know its the latest most up to date version - it says Office 365 Version 1705 (Build 8201.2102). I haver been using the Office 365 Outlook Client for a year now and this problem has arisen in the last 3 months. Please Microsoft can you fix the issue?

    Windows 7 Home Premium SP1 64 Bit - Dell XPS420 6GB

    Monday, June 19, 2017 10:15 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yes, the issue is listed from January 2017 so it is high time it was resolved. We all regularly use attachments and it is very frustrating for recipients not to be able to open the winmail.dat.

    The issue was recorded here https://support.office.com/en-us/article/Fixes-or-workarounds-for-recent-issues-in-Outlook-for-Windows-ecf61305-f84f-4e13-bb73-95a214ac1230     

    Recipient receives a winmail.dat attachment when sending email from Outlook with Outlook.com account

    Tuesday, June 20, 2017 11:44 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    The winmail.dat issue should be fixed in the next update for Current Channel Click to Run.  If you want to test it the fix is already in Insider Slow builds, https://products.office.com/en-us/office-insider.  We are not sure yet when it will get to MSI builds.  I suspect July or August and lean more towards August.  The change to address it was really big and the Outlook Team wants to make sure it does not introduce new issues.  Because of that it has been rolling out more slowly than other fixes.
    Monday, June 26, 2017 4:44 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    What's the projection of when this would roll out to non-insider  (office365 small business) builds assuming all goes well?
    Monday, August 7, 2017 8:33 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Gabriel, Any new information on the Windat attachment issues in Outlook?  I'm having the problem with a few clients. Not good customer service. I tried Ken's fix and I cannot find an Admin Submenu to click Exchange, so didn't get through step 3.

    What's our quick fix?  Send everything with an attachment to the troublesome emails in plain text? Or send through a private gmail account on a browser instead of through Outlook?  That's what I've had to do.

    Maitri

    Tuesday, September 5, 2017 2:17 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Just want to make sure MS knows the problem is still active.   I have three machines running Outlook 2016 client SW through OUTLOOK.COM and have the same problem with all three going to one Apple machine and one PC machine.  One domain is yahoo.com and the other is AOL.COM.  Have sent attachments as HTML and they still come across as windmail.dat.  I hope they do something soon....
    Friday, September 22, 2017 10:54 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    In my case, disabling rich text setting was not working, because I had contact with same email in my company Address Book. There is a setting in Address Book that enforce rich text as it is known email. I manage to solve my problem by re-creating contact and unlink all Linked Contacts in Outlook properties. Hope that helps. 
    Sunday, October 1, 2017 2:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    This just started happening to me.  I have office 365 (version 1708 Build 8431.2107) on a windows 8 machine.

    It started as soon as office updated itself.  I also upgraded my iPhone to ios 11 at the same time, that's when I noticed that I can no longer send any kind of attachments to any apple device.  I have never had Rich Text turned on in my outlook it is set to HTML.  Nothing changes if I set it to plain text.  Office 365 is a subscription service so they can keep giving you updates to make a better product.  I have seen 0 evidence of that, it just bug fixes no add features and just more problems with every update.  Thinks it's time to dump MS.

    Friday, October 20, 2017 11:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thank you so much for this posting.  I have struggled with this for months and tried all sorts of things.  This is the first time I've found a working solution for the winmail.dat problem!
    Friday, January 5, 2018 10:25 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    The following solution (at the bottom of this post) from Dennis at Office 365 Support solved the winmail.dat problem for me. Note that I was able to narrow the symptoms down to:

    • If the message was sent from Outlook.exe and auto-complete was used to fill in the recipient's email address, the recipient would not see a jpeg that was part of the Signature AND would receive a winmail.dat attachment in place of the actual attachments included.
    • In some instances the above would happen only when the message was viewed using the IOS Mail app but not when opening the message using Windows Chrome browser to see it in Gmail. 
    • If the sender manually typed the recipient's email address the above problem would not occur. The recipient would see the jpeg in the signature and receive the actual attachments.

    And now the solution:

    "There may be something else we can try. In his Outlook client, please go to File => Options => Mail => Sending Messages Section => Empty Auto Complete List. Also, please check again if Message Format is saying Convert to HTML Format. Please close and re-open Outlook and see if the issue persists."

    • Proposed as answer by KathiC Wednesday, March 14, 2018 5:31 AM
    Tuesday, March 13, 2018 5:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Interesting and annoying that the solution for me was:

    "There may be something else we can try. In his Outlook client, please go to File => Options => Mail => Sending Messages Section => Empty Auto Complete List. Also, please check again if Message Format is saying Convert to HTML Format. Please close and re-open Outlook and see if the issue persists."

    I was using auto complete to the recipients that received the winmail.dat attachment instead of the .docx or .pdf.  I am not using a signature of any kind so it was just the auto complete that was the contributing factor for me.  

    Thanks for posting this solution TinySenor. 

    PS - I'm sending from Outlook 2016 (16.0.9029.2106) 32-bit 

    Wednesday, March 14, 2018 5:39 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Kent.... I had the problem with sending to AOL users, but the pictures is the settings I used..  It seems to work.
    • Proposed as answer by gusmuh Thursday, August 9, 2018 11:19 PM
    • Unproposed as answer by gusmuh Thursday, August 9, 2018 11:19 PM
    Saturday, March 24, 2018 12:05 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    For me to resolve this, I had to go to File, Options, Mail, under 'Message Format' category, I changed 'When sending Rich Text Format messages to internet recipients' to 'Send using Outlook Rich Text Format' from the dropdown menu. 

    I am using Office 365 Outlook on desktop early August 2018.

    ps- Under 'Compose Messages' category I have the format set to HTML.


    Thursday, August 9, 2018 11:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    For anyone that happens to have Exchange server 2016 on premises, here's the powershell behind it....

    New-RemoteDomain -Name Gmail.com -DomainName Gmail.com
    Set-RemoteDomain -Identity Gmail.com -TNEFEnabled $false

    Get-RemoteDomain -Identity Gmail.com |fl

    …

    TNEFEnabled     False

    …

    You can set all remote domains with 

    Set-RemoteDomain Default -TNEDEnabled $false

    Tuesday, September 4, 2018 1:30 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    This issue has came up out of nowhere for us sending payroll pay stubs. This issue took care of it. I followed so many tutorials online to fix it. But none worked.

    Thank you Kent!

    Thursday, February 21, 2019 8:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Kent,

    This worked for us, thank you for posting your solution!!!

    John

    Tuesday, March 12, 2019 9:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Great piece of work. Been trying to fix this for several years with just one recipient. The other stuff just didn't work.

    "it's a Microsoft bug. Feel free to fix it, guys." Seems to have had little effect. I suspect your conclusion is correct - "Office 365 Exchange instance isn't respecting the encoding preferences in the Outlook 2016 client"

    The other conclusion might be that the code base is so convoluted that no one can work out why.

     

     
    Friday, March 22, 2019 8:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thanks a million to TinySenor.  I was having the problem that JPEG attachments from Outlook were being received as WinDat attachments on my iPhone.  Outlook was set to use HTML and it was still not working.  I switched to using Plain Text and this allowed the attachment to be received correctly.  Unfortunately, Plain Text meant that no formatting was possible in the e-mails.  

    Thanks to the TinySenor suggestion to clear the Auto complete List, I cleared the list and set Outlook back to HTML.  Everything then worked as expected.  Of course, I still cannot imagine why auto complete could cause this problem.  
    Thursday, May 30, 2019 1:38 PM