Audio.mp3 is not displaying in Classic Outlook for desktop

Question

Voicemails are received, it has a paperclip icon so an audio file is attached, but it is not visible when opening the email.

The attached Audio.mp3 shows up in Outlook Web. also the attachment only shows up when you try to forward the email

How can I make the attached audio file display on the email by default?

Here are some details and troubleshooting done.

1 Verified message displays correctly in OWA

2 Confirmed paperclip present on message

3 Disabled Cached Exchange Mode / tested OST

4 Ran outlook.exe /cleanviews

5 Started Outlook in Safe Mode

6 Office Quick / online Repair

7 Updated Microsoft 365 Apps to latest build

8 Confirmed Attachment Preview is NOT disabled (Trust Center)

9 Checked Disabled Items list

10 Verified Microsoft Exchange Add-in (UmOutlookAddin.dll)

11 Enabled Reading Pane (View > Reading Pane > Right)

Answer 1

Found the root cause and a working fix.

Confirming first that I hit both dead ends already reported in this thread: AllowVoicemailForm=1 gives a play control and still hides the attachment, and forwarding to self works. Our source is Avaya IP Office Voicemail Pro rather than Teams, same symptom, which points at the message class rather than the phone system.

Root cause

The voicemail email carries a Content-Class: voice header. Exchange Online's MIME-to-MAPI conversion reads that and stamps PR_MESSAGE_CLASS as IPM.Note.Microsoft.Voicemail.UM. Outlook Classic routes that class to Microsoft's native voicemail handling, which claims the audio part and does not list it in the attachment well. It fails silently, with no error and no banner.

New Outlook and OWA do not use that rendering path, which is why they display correctly. Forwarding works because the forwarded copy is created as a plain IPM.Note.

Worth noting that the Microsoft known-issue article "VoiceMail forms do not work in Outlook Desktop" is the inverse problem. Its symptom is "users no longer see the form, instead they see a raw MP3 attachment," and its fix restores the form. Its "Fixed" status does not apply to us, so waiting on a newer Outlook build will not help.

Fix

Strip the header in transport so the items land as ordinary mail. This is the rule I verified in production:

New-TransportRule -Name "Strip_Content_Class_Voicemail" `
    -HeaderMatchesMessageHeader "X-Mailer" `
    -HeaderMatchesPatterns "Voicemail Pro" `
    -RemoveHeader "Content-Class" `
    -Priority 24 `
    -Mode Enforce

X-Mailer: Voicemail Pro Server is Avaya-specific. For Teams voicemail you would match on the Content-Class header itself instead, which is portable across any voicemail source:

-HeaderMatchesMessageHeader "Content-Class" -HeaderMatchesPatterns "voice"

I have not tested that variant, only the Avaya one.

Three cautions before deploying

1. Pilot it first with -SentTo ******@domain.com, then clear that condition to widen. Rule changes take up to 30 minutes to replicate, so an immediate test can look like a failure when it is just propagation.
2. Check your retention and discovery scope. Run Get-RetentionPolicyTag | Where-Object {$_.MessageClass -ne "*"}, Get-JournalRule, and look for any eDiscovery or content search scoped by kind:voicemail. Reclassifying to IPM.Note moves those items onto your default mail tag. In regulated or public-records environments that matters.
3. Teams-specific risk. The Teams client's voicemail view and transcription may key off this message class. I am on Avaya so I cannot test that. Verify before widening.

Limitations

This only affects new mail. Already-delivered voicemail is already converted and stays broken in Classic Outlook. Forward-to-self remains the workaround for those.

One transport rule gotcha

Use -HeaderMatchesMessageHeader with -HeaderMatchesPatterns rather than -HeaderContainsMessageHeader with -HeaderContainsWords. My first attempt used the ContainsWords form and silently never fired, never even appearing in message trace, because those predicates are word-tokenized. A value with a trailing @ and a multi-word phrase against a whole-word matcher both fail to match. Regex bypasses the tokenizer entirely.

Answer 2

Hi Jeff,

Thank you for providing the detailed information and outlining the troubleshooting steps already performed.

Based on what you've shared, it appears that the common Outlook troubleshooting steps have been thoroughly covered. As the voicemail message and audio attachment display correctly in Outlook on the web, the issue seems to be specific to how the message is being rendered in Classic Outlook.

Given the troubleshooting completed so far, this may require further investigation from the Microsoft side to determine the underlying cause and identify any available resolution.

I would recommend engaging Microsoft Support for further analysis and assistance. You can consider having your IT administrator open a support case with Microsoft so that the issue can be reviewed in greater detail and investigated further.

For guidance on how to request support in the admin center, share this link with your admin: Get support - Microsoft 365 admin. 

If you are unsure who your IT administrator is, you can refer to this official Microsoft guide for assistance: How do I find my Microsoft 365 admin? - Microsoft Support.

Wishing you a quick resolution. Feel free to let me know if there are any updates.

Answer 3

We had the same issue

Please add this reg key in the HKey current user close and reopen outlook

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\Addins]
"AllowVoicemailForm"=dword:00000001 

worked like a charm after the change you have the voice mail loaded in the form