Introduction

Recently, I encountered an interesting case where a customer received a non-delivery report (NDR) after attempting to send an email to a large list of recipients (over 100 email addresses).

The scenario was somewhat complex: the email had been sent from another user’s mailbox via OWA (Outlook on the Web), so one of our first tasks was to determine whether that detail was relevant to reproducing the issue. As it turned out, it wasn’t critical in this case, so I’ll skip that part and focus on the core issue.

The customer had already performed some initial investigation and shared the following information:

1. The non-delivery report (NDR) generated by the Exchange server:

Unfortunately, the NDR didn’t contain any meaningful details and couldn’t be used to reproduce or analyze the issue further.

2. A message tracking log entry indicating the specific error and the reason the message wasn’t delivered: “554 5.3.4” Content Conversion error:

💡Note: This error occurs at the stage when the Store Driver attempts to submit the message to the Transport service. As a result, you won’t see any details such as the message subject, recipients, etc., in the usual tracking data.

To identify the relevant event, you’ll need to apply careful filtering based on a specific time range and sender address. In this example, there’s only one server involved, but in a real-world scenario, you’d typically search for events on the server that hosts the sender’s mailbox database.

3. The list of recipients couldn’t be reused for testing purposes, as the test environment does not contain corresponding mail-enabled objects.

📌What is Content Conversion in Exchange?

Content Conversion is the process by which Exchange Server transforms the structure and format of an email message to ensure compatibility with the recipient’s environment — especially when messages cross organizational boundaries.

This typically involves converting between internal formats like Transport Neutral Encapsulation Format (TNEF) and external formats like MIME, depending on:

• the message direction (internal vs. external),
• recipient settings,
• during submission from storedriver to transport service,
• organizational transport configuration.

🔄When Content Conversion Occurs:

• Inbound: From the Internet to internal users.
• Outbound: From internal users to the Internet.
• Cross-forest or cross-organization scenarios.
• When messages are scanned or re-routed by transport rules, connectors, or appliances (e.g., antivirus, anti-spam, encryption).

⚠️Common Causes of Errors During Content Conversion:

1. Malformed or corrupted MIME content
   → Exchange may fail to parse or render it correctly.
2. Large or unusual attachments
   → Content conversion may fail when handling embedded objects or proprietary formats.
3. Invalid TNEF encoding
   → Especially if the recipient doesn’t support TNEF (Winmail.dat issues).
4. Memory or timeout issues
   → On heavily loaded servers or with large messages, conversion may time out.
5. Antivirus / transport agents interference
   → Third-party agents that manipulate message content may disrupt the conversion process.
6. Conversion loops or reprocessing
   → Messages being repeatedly converted back and forth can cause corruption or failures.

📌Gather additional Information

First, it’s important to collect more details about the message itself:
Was it a forwarded message or a new one? Were there any unusual attachments? How many recipients were involved?

In this particular case, the message was newly composed, which makes the Content Conversion error even more unusual — especially considering it was sent via OWA (Outlook on the Web).

Also, the error description is quite generic and doesn’t provide detailed insight — unlike more specific scenarios such as hitting recipient limits. This suggests that we’re dealing with a common exception that results in a generic error message.

🔍In some scenarios, it may be helpful to check:

• Mailbox Transport Submission and Transport Connectivity logs
• Application logs in Event Viewer

However, in this case, those sources didn’t reveal any additional information.

Next Step: Investigating the Message Itself

If you don’t have direct access to the production environment, you can ask the customer to export the problematic message (from Sent Items) using MFCMAPI:
🔗 https://github.com/microsoft/mfcmapi/releases

Be sure to download the 32- or 64-bit version that matches the installed version of Outlook.

To use MFCMAPI:

1. Extract the tool on a machine where Outlook is installed.
2. Ensure the Outlook profile has Full Access to the required mailbox.
3. If needed, you can assign Full Access permissions without enabling automapping using this PowerShell command:

Add-MailboxPermission support -User administrator -AccessRights FullAccess -AutoMapping $false

4. In this case, you’ll need to manually add the mailbox as an additional account in the Outlook profile. Once that’s done, launch MFCMAPI and follow the steps below:

5. In the MFCMAPI start window, double-click the profile that contains the mailbox you want to access:

6. Expand the mailbox folder tree and locate the Sent Items folder.

7. Find the problematic message in the list, then right-click the message to open the context menu:

8. From the context menu, select Export Message → MSG file (UNICODE).

Use the default export settings and save the file to a convenient location.

💡Note. If you plan to send the exported message via email, it's recommended to compress it into a ZIP archive first. This helps preserve all message properties, as certain attributes may be altered or stripped during transmission.

🛠️Troubleshooting this issue

At this point, you can open the exported message in MFCMAPI to examine its properties.

In some cases, content conversion issues are caused by problematic message formatting from clients that don’t fully comply with RFC standards. Therefore, it’s a good idea to check properties like:

• PR_INTERNET_CPID (character set)
• Attachment-related properties such as PR_HASATTACH, PR_ATTACH_FILENAME, etc.

That said, issues like this are not typically expected when the message originates from OWA.

Unfortunately, there is no automated tool (at least that I’m aware of) that can verify RFC compliance or detect formatting anomalies in the message. So, for now, manual inspection is necessary. You’ll find a list of useful reference resources at the end of this post.

You can also export the message content to a text file if needed for further analysis.

While you can’t resend a message via OWA directly, there are a few alternative ways to test:

• Drag and drop the message into Outlook and try resending it.
• Save the message as a draft, then resend it via OWA.

Of course, this isn’t a perfectly clean test, but in this particular scenario, I was able to reproduce the issue using this method.

🔎Observations:

• The message itself looked normal — plain text with a signature image, nothing unusual.

• While resending the message, I noticed that some email addresses didn’t appear to be formatted correctly:

• When the message is sent from Outlook, in addition to the non-delivery report (NDR) generated by the Exchange server, you may also receive notifications about invalid recipients directly in the Outlook interface.

• If you export the message to a text file and examine the recipient list, you’ll see something like the following:
  
  dwBitmask: 0x80010000 = MAPI_UNICODE | MAPI_SEND_NO_RICH_INFO
  szDisplayName = Annelie Zubery,
  szAddressType = 15.04.2025 13
  szEmailAddress = 32]]></SmartView>
  Address type is incorrect (presented by date) and address itself also.

• I reviewed the original recipient list provided by the customer and, as suspected, one of the addresses appeared to be copied from an instant messaging chat – it wasn’t in a valid email format.

It seems that the sender simply pasted the recipient directly into the message as-is.

This issue can be reproduced in both OWA and Outlook, in Exchange and EXO. For example, if you insert a recipient in the following format:

Test Testov, [06.03.2025 13:32]; The client attempts to interpret it and includes the recipient in that exact form within the message. This results in what’s known as a One-Off Recipient — a special type of recipient in Exchange/Outlook that isn’t linked to an address book object. Instead, all the recipient’s information (display name, email address, and type) is embedded directly in the message. These entries can also end up in the auto-complete cache, further propagating the issue.

✅ Recommendations

• Clear the auto-complete cache for the problematic recipient in both OWA and Outlook (where applicable).
• Check for outdated templates or drafts that may already contain an incorrectly formatted recipient (e.g., email templates, saved responses, or copy-pasted contact lists).
• Encourage users to verify recipient addresses before sending, ideally by selecting them from the address book rather than pasting them manually.
• If mass mailing is involved, consider providing users with a pre-validated distribution list or a trusted address source to minimize formatting errors.

🧰 Tools and Resources for Analyzing MAPI Message Properties

🧪 Official Microsoft Documentation

MS-OXPROPS: Exchange Server Protocols Documentation
The primary official reference for MAPI properties. It includes:
– Property names (e.g., PR_HASATTACH, PR_INTERNET_CPID, PidTagMimeSkeleton)
– Hex codes (e.g., 0x3701, 0x3FDE)
– Data types (PT_BOOLEAN, PT_LONG, PT_BINARY)
– Usage notes and descriptions
🔗 MS-OXPROPS on Microsoft Learn

MAPI Property Reference
A comprehensive listing of MAPI properties, with detailed descriptions of each property’s type, identifier, and purpose.🔗 MAPI Properties Overview

MAPI Objects and Properties
General information about how MAPI organizes data and how properties relate to message and folder objects.
🔗 MAPI Objects and Properties

Mapping MAPI Names to Canonical Property Names
Useful when you want to translate MAPI names into canonical names to find deeper documentation.
🔗 MAPI Name Mapping

🧪 Tools for Manual Inspection

MFCMAPI
A low-level tool for exploring MAPI message properties. It allows you to:
– Open any mailbox or item and inspect all MAPI-level properties
– Explore attachments, flags, headers, and other internal structures
– It’s an open-source utility maintained by a Microsoft engineer.
🔗 MFCMAPI on GitHub

OutlookSpy
An Outlook add-in that integrates directly with the Outlook interface, allowing you to:
– View all MAPI properties of selected items (emails, calendar entries, etc.)
– Run MAPI queries and inspect folder structures
– Access and analyze hidden or non-standard fields
– Commercial license (free trial available with limitations).
🔗 OutlookSpy Website

End.