Modern groups were introduced an year ago and are Microsoft’s vision for the way collaboration between small teams should work. In general, they are loved by the customers as they are easy to use and do offer a lot of value. That being said, they are not without issues – support in desktop or mobile clients is lacking, administrative tools leave a lot to be desired, etc.
One such issue caught my attention recently on the Yammer Office 365 network. The problem revolved around external people not being able to send messages to the Group, while at the same time all the correct settings were in place. As a refresher, this functionality is controlled by the RequireSenderAuthenticationEnabled attribute, but other attributes can play a role as well:
If no restrictions are configured via the above parameters, both internal and external users should have no problem emailing the Group. That was not the case however, and every external person that tried to send a message to the group was greeted by the following NDR:
The error that the other server returned was:
550 5.4.1 [firstname.lastname@example.org]: Recipient address rejected: Access denied
Now, for those of you that have followed Office 365 for a while, this NDR can bring back some very bad memories (the infamous FOPE issue with duplicate/orphaned domains resulting in “550 5.4.1 Relay Access Denied” NDRs). This is not the case here, regardless of the DSN code being the same. Instead, another old friend of ours is to blame – Directory Based Edge Blocking. DBEB was part of FOPE and later introduced in EOP. In a nutshell, the feature allows EO servers to sync their recipient lists with the edge nodes, and the later block any address not present in said lists. More information can be found in the blog post above or this TechNet article.
So how does this relate to the issue at hand? Turns out, the issue was only happening for messages sent to the *secondary* email address of the group. It’s actually very easy to reproduce – just add an additional alias to any of your modern Groups, then send an external message to it. What seems to be causing the issue is the lack of synchronization (or notification when it comes to modern Groups?) for the newly added addresses to the edge nodes. For any other recipient type, this is done pretty fast – in 10 to 15 minutes or so, max 30 (and yes, during this time window you will get the same NDR message for external senders). If you are in a particular hurry, ‘touching’ the object should trigger the sync.
When it comes to Groups however, this is not the case. Almost a week has passed since my initial tests and the sync is yet to happen. It does seem to happen eventually, considering the fact that older Groups I have created (and added additional aliases to) don’t have the same issue. I believe the issue lies in the special status Groups have and the way their attributes are synced between the different services (watch this session from Ignite for more info). What’s worse, ‘touching’ the object doesn’t seem to have any effect because of that fact.
So what are your options? Option one, wait. The sync should happen eventually, but that’s hardly a viable solution considering the amount of time it takes. The second option will be to change the domain intent to Internal relay, effectively disabling DBEB. This might have some adverse effects in the form of convoluted ‘mail loop detected’ NDRs instead of the plain ‘recipient not found ones’. Switching the domain(s) back on to Authoritative should help with the sync. The third option is again to wait, for Microsoft to fix this.
UPDATE: Apparently, the only way to resolve this issue is to ‘cycle’ every alias as primary, as only the primary SMTP address is being synced to the EOP servers it seems.
4 thoughts on “5.4.1 NDRs when sending external messages to modern Groups (aka DBEB and Groups don’t play well together)”
Could you expand a little on your workaround? We are running into the exact same problem.
Just a note that this also happens with Office 365 shared mailboxes and I suspect for the same reasons. If I add an alias to a shared mailbox in the admin portal or using powershell it results in the same 540 5.4.1 NDRs you speak about above. My solution has been to make the new alias the Primary SMTP address and then wait out the sync process testing the address using https://testconnectivity.microsoft.com until I get a clean test. This still typically take some hours to sync but it isn’t a week. Then I set the original SMTP address as Primary again and test one more time to be sure.
Definitely not an elegant, “It just works” solution.
*correction 550 5.4.1 NDRs