Establish whether the message exists
Leave a short test voicemail containing a unique spoken identifier and note the time, extension and intended email recipient. Retrieve it through the normal authenticated mailbox interface. If the recording is absent there, investigate voicemail routing or storage first. An email repair cannot recover a message that was never saved.
If the message plays correctly, keep it in the mailbox while tracing notification delivery. The phone’s message-waiting indicator and email notification are separate paths, so one can work while the other fails.
A message-waiting or email fault can occur even when the recording was saved correctly.
Check the mailbox notification policy
Verify the email address and attachment policy on the actual mailbox. Compare with a working mailbox rather than assuming the person’s portal account supplies every voicemail setting. Preserve a local copy during testing; an email handoff should not be treated as proof that the recipient has received the audio.
Use a test message without confidential customer information. If attachments are disabled intentionally, a notification without audio may be correct. Distinguish that policy from a corrupted or rejected attachment before changing codecs or mailbox formats.
Identify the active mail transport
Find which mail submission service the installation actually uses and how FreePBX hands a message to it. Sangoma’s System Admin Email Setup documents SMTP settings when that feature is available, but module edition and installation method affect the interface. Older CentOS and provider-specific recipes are not a Debian 12 configuration baseline.
Record the relay hostname, connection mode, sender identity and authentication method without copying credentials into the incident report. Use the relay operator’s current requirements; do not disable certificate verification to make an authentication or trust failure disappear.
Follow the message across the boundary
Correlate the test time with the local mail submission result and, where available, the relay’s message or queue identifier. No submission points toward notification generation or the local handoff. A rejected submission points toward the explicit SMTP error, such as authentication, recipient or sender policy.
If the relay accepted the message, inspect its delivery trace, deferred queue and the recipient’s quarantine or filtering. Acceptance by one SMTP hop is not confirmation of inbox delivery. Compare a notification-only test with a small attachment test when attachment handling appears to be the boundary.
Verify recovery and monitoring
After the narrow correction, send another voicemail through the full external-call path. Confirm mailbox playback, notification arrival, correct recipient and readable attachment if enabled. Then repeat with a second mailbox to distinguish a per-user fix from a system-wide repair.
Document a regular delivery check and an owner for expiring relay credentials or changed mail policies. Retain enough log context to diagnose a recurrence while following message-retention rules. Restore any temporary recipient or attachment settings and remove the test recordings when they are no longer needed.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma: System Admin Email Setup ↗
- Sangoma: Bulk Handler voicemail fields ↗
- Asterisk: voicemail and authenticated retrieval ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.