In Exchange 2013 there are a series of probes that monitor the health of the different components of the servers. One of these probes monitors the health of each Frontend Transport server and its ability to proxy messages to each of the 2013 mailbox databases in the Exchange organization.
The monitoring happens by sending emails to a specific mailbox on each mailbox database in the organization. This mailbox is called HealthMailboxguid The guid matches the guid of the mailbox database that the mailbox is located in.
Get-Mailbox HealthMailbox* –Monitoring | FT Name,Database
Get-MailboxDatabase | FT Name,GUID
If you have a problem with the configuration of any of these mailboxes then you will get Non-Deliverable messages generated, and these messages will get sent out the most appropriate send connector as the Exchange probe emails “come from” firstname.lastname@example.org. At the time of writing, the inboundproxy.com domain is registered, but the MX record does not exist – so the messages queue on your Exchange Servers or on any smart host device that you use.
To work out what you need to fix to stop these messages queuing (or worse, have them sent to the inboundproxy.com domain if the owners of that domain publish an MX record to the internet) then you need to suspend some of the messages in the queue and export the messages to a file on the disk. You can then open the message and see what the error is and fix it.
Get-Queue server\idForInboundProxy.comQueue Get-Message -Queue server\idForInboundProxy.comQueue | Suspend-Message -Confirm:$false Export-Message server\idForInboundProxy.comQueue\MessageID | AssembleMessage -Path c:\temp\Health1.eml
Repeat the above for a random selection of the messages in the queue (as you might have more than one issue to fix) changing the .eml file name and MessageID each time.
Once you have a few .eml files exported, open them up and see what the reason for the NDR i and fix it.
In my Exchange organization I had some of my HealthMailboxes with the wrong SMTP proxy address (@domain.local) rather than the only accepted domain I had (@domain.com), so I just ran Update-EmailAddressPolicy again and the problem went away once the HealthMailboxes had their SMTP proxy address changed to a valid address.