We noticed during the last days multiple CRM emails were not sent and they bounced back as undelivered.
This was a CRM Online 2016 implementation using the CRM Email router.
The SMTP error messages were like 550 5.XXX.YYY (e.g. 550 5.1.8; 550 5.0.350) from different providers (Gmail, Outlook, Yahoo, etc).
Using the following online tool mxtoolbox.com, we could quickly confirm the server was blacklisted.
As Microsoft recommendation (see the following article), we had to raise a support ticket to delist it (please see below new update).
Unfortunately, the other challenge was to recover the emails, as Microsoft CRM Online 2016 doesn’t report soft or hard bounces, and all emails are marked as Sent. Some interesting ideas came around this to resolve it, I’ll try to share it in a future post 🙂
***More updates (12/01/2017):
Bounces carried on happening and after more investigation, we noticed some of the new IP’s were not added into the SPF (Sender Policy Framework) records. See the following article for more information:
After updating the SPF records, bounces carried on coming. More IP’s needed to be delisted again, but this time the Microsoft engineer pointed us to a new online tool:
This online tool allows you to delist IP’s in 3 easy steps.
But the challenge didn’t come to an end. It looks like the number of sent emails may be too high… This is where you should check the following recommendations:
We noticed incoming emails stopped getting in and we saw a 401 Authentication Error in the CRM Email Router server logs. Nothing has changed in the system account used for this Forwarded Mailbox and the password is still valid.
Deployment: CRM Online + CRM Email Router + Exchange Online
CRM Email Router Configuration: Forward mailbox is used for incoming emails.
After a few tests using the next utilities (very useful!):
We noticed that system account cannot access its own mailbox. Very weird, like if you don’t have access to your own home suddenly.
Finally, we just had to force an update on this system account to make it work again using the next PowerShell command:
set-msoluser -blockcredential $true -userprincipalname [userAccountName]
set-msoluser -blockcredential $false -userprincipalname [userAccountName]
It looks like the system account was desynchronised between our internal AD and Microsoft Online AD, causing this issue.