Fixing Office 365 Anonymous Group Write-back and External Delivery

Fixing Office 365 Anonymous Group Write-back and External Delivery

  • 1
  • 3
5/5 - (10 votes)

Yes, Hell has frozen over. The cows have come home. The lady of size has sung.

I have come up with a “best case” solution for the Office 365 hybrid group write-back problem.


For the long(er) background, you’ll probably want to go see this post.

For the tl;dr readers:

  1. Office 365 Groups can be written-back to on-premises environments to make them visible to on-premises users.
  2. If your MX record is pointed to an on-premises environment and you have Office 365 Group write-back turned on and some of those groups are configured for anonymous receive (ie, allowed to receive unauthenticated or anonymous messages from the internet), external senders will receive an NDR with the ever-popular and cryptic message “You do not have permission to send to this recipient.”

As was previously discussed in the post, this is because AAD Connect writes a constant value of True for the msExchRequireAuthToSendTo attribute of a written-back group. The synchronization service cannot read the actual value of the attribute from the cloud, which is why a constant needs to be used.

The calamity.

Solution overview and limitations

So, here is how to fix it the best way we can at the moment.  It involves changing the constant value of msExchRequireAuthToSendTo from True to False.  This will allow the on-premises system to route the mail to Office 365, where the value stamped on the actual object will be evaluated.  If the cloud value is True, Office 365 will generate an NDR and relay it back out.  If the cloud value on the group is False, the message will be delivered.

The caveat is this:

Mail will be delivered to any on-premises mailboxes that are members of any Office 365 groups regardless of the cloud value if this configuration change is made to the attribute globally.

To minimize this risk, I recommend modifying the Description attribute of all the Office 365 groups that will require anonymous (external) delivery with a value that you can use as a scoping filter–that way, we can target updating only groups that have a specific keyword in the description of the group.  For this exercise, I modified the description attribute to start with the word EXTERNAL.

Pre-pend description field with EXTERNAL

  1. Connect to Office 365 via PowerShell.
    $Credential = Get-Credential
    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $Credential -Authentication Basic -AllowRedirection
    Import-PSSession $Session
  2. List all the groups that allow external senders.
    Get-UnifiedGroup -ResultSize Unlimited | ? { $_.RequireSenderAuthenticationEnabled -eq $false } | Select Alias,Name,Notes

  3. Update the description (Notes) field to prepend the text to use as a scoping filter (in this case, EXTERNAL).
    Get-UnifiedGroup -ResultSize Unlimited | ? { $_.RequireSenderAuthenticationEnabled -eq $false } | % { Set-UnifiedGroup $_.Identity -Notes "EXTERNAL - $($_.Notes)" }

  4. Verify the update.
    Get-UnifiedGroup -ResultSize Unlimited | ? { $_.RequireSenderAuthenticationEnabled -eq $false } | Select Alias,Name,Notes

  5. Wait for an AAD Connect delta sync cycle to run (or initiate one yourself from the AAD Connect server’s PowerShell interface with the following command):
    Start-ADSyncSyncCycle -PolicyType Delta

Note: This is a one-time update.  Going forward, you’ll need to train your users to both:

  • Ensure the “Let people outside the organization email the group” checkbox is selected in the group configuration
  • Update the description of the Office 365 groups they manage that need to accept mail from external senders to include the text that’s going to be used as the scoping filter.  They can do this by editing the group in Outlook (Select Group from Outlook navigation pane | Group Settings | Description) or in Outlook Web App (People | Groups | Edit Group | Description) and putting the necessary text in that you want to use as a scoping filter in the description field.

Create an outbound to Active Directory rule to modify the attribute value

  1. Launch the Synchronization Rules Editor (Start | Synchronization Rules Editor).
  2. Under the Direction label, select Outbound.  Click Add New Rule.
  3. Enter a Name for the rule, select your Active Directory connector under Connected System, and then select group for both the Connected System Object Type and the Metaverse Object Type.  Ensure the Link Type is set to Join, and then enter a low precedence number (such as 50). Click Next when finished. If you have more than one Active Directory forest configured in AAD Connect, select the forest to which Office 365 groups are written back.
  4. On the Scoping filter page, click Add group.
  5. Click Add clause.
  6. In the Attribute column drop-down, select cloudMastered.  Under Operator, select EQUAL. In the Value box, type true.  Click Add clause, select description. Under Operator, select STARTSWITH. In the Value box, type EXTERNAL.  Click Next.
  7. On the Join rules page, just click Next without adding anything.
  8. Click the Add transformation button.
  9. Under the FlowType drop-down, select Constant.  Under the Target Attribute, select msExchRequireAuthToSendTo.  Under Source, enter false and click Add.
  10. Close the Synchronization Rules Editor.

Preview the objects

  1. From the Synchronization Service user interface, select the Active Directory connector.  If you have more than one Active Directory connector, select the connector representing the directory where the Office 365 groups will be written back.
  2. Right-click on the connector and select Search Connector Space.
  3. Under Scope, select RDN, and in the Specify relative distinguished name (RDN) or anchor value box, enter CN=Group_ (all Office 365 groups written back on-premises are prefaced with Group_) and click Search.
  4. Select a group from the list and click Preview. Note: You may want to select Column Settings… and add the Display Name column so you can more easily identify your synchronized groups.
  5. Select the Full Synchronization radio button and click Generate Preview.
  6. Expand Connector Updates | CN=Group_<guid> | Export Attribute Flow, and then look in the window for the msExchRequireAuthToSendTo attribute.  Note the value in the column should be false.
  7. Click Close twice to close the Preview and Search Connector Space dialog boxes.

Make it so

  1. Right-click the Active Directory connector, click Run.
  2. Select the Full Synchronization option and then click OK.  This will run the synchronization rule on all in-scope objects and stage the changes for export.
  3. After the run profile task has completed, right-click the Active Directory connector, select Run, select Export and click OK.  This will write the changes to Active Directory.
  4. After the run profile task has completed, launch Active Directory Users and Computers, navigate to the organizational unit containing the written-back Office 365 Groups, expand a group, and on the Attribute Editor tab, view the value for msExchRequireAuthToSendTo. Or, alternately, add the msExchRequireAuthToSendTo column to ADUC and review them all.

Now, your external senders should be able to relay to your Office 365 groups via your on-premises gateway.  Woo!

Published by Aaron Guilmette

Helping companies conquer inferior technology since 1997. I spend my time developing and implementing technology solutions so people can spend less time with technology. Specialties: Active Directory and Exchange consulting and deployment, Virtualization, Disaster Recovery, Office 365, datacenter migration/consolidation, cheese.

Reader Comments

  1. Thanks for the great writeup on an important issue! Like others, I’m also getting NDRs with the “554 5.4.6 Hop count exceeded – possible mail loop” error after I’ve implemented these changes described.

    It looks like the email is getting to the on-prem exchange server, and it’s no longer being rejected due to a lack of authorization. The mail server knows that a group exists matching the destination email address, but doesn’t know how to deliver it.

    In the case of a user mailbox, the on-prem AD account has a targetaddress attribute which is populated with an email address using the cloud tenant domain (e.g. The exchange server has a send connector scoped to that domain, and knows to pass messages addressed to that domain to Exchange Online for delivery. For Office365 groups being written back to AD, the targetaddress attribute is set to the same as the primary email address of the group (e.g. Exchange knows that it handles messages for that domain, and doesn’t know to pass the message on to Exchange Online.

    I tried manually updating a group’s targetaddress to use the version of the domain. I then sent a test email to the group from an external address. The message was delivered to the group members, but not to the group mailbox. It looks like the message was passed to EO, where it expanded the DL and delivered the message to the group members, but when it tried to deliver to the group itself it passed the message back to on-prem exchange.

    I expect that this wouldn’t be a problem if you use a seperate subdomain for groups. Since they share the primary domain in our environment, messages get stuck in a loop and eventually bounce. I can see why it’s behaving the way it is, but I’m not sure how to go about correcting the issue.

      1. I don’t think I got a notification that you had replied, or if I did I overlooked it. Our accepted domains are set to Authoritative in both the On-Premises and Online environments. A send connector in on-prem exchange directs mail destined for the “” domain to Office 365.

        My understanding was that the domains should be configured as authoritative when used in a hybrid environment. Is changing them to Internal Relay a supported config?

        1. Yes. You typically shouldn’t have them authoritative in both spots. Since the GAL is the official record of who exists in the org, if you have the domain set to authoritative it well never forward out. You can get Exchange (either on-premises or cloud) to forward to the other environment in the same namespace by setting the domain to Internal Relay.

          1. For the first, I want to thank you for your detailed explanation.

            BTW, you don’t need to set domain as Internal Relay it will work with Authoritative too.
            Two additional things should be done to achieve this goal:
            1. change group default address to instead of @ – it will automatically change targetAddress attribute to this one, also ensure that the last one is presented as alias
            2. change send connector in on-premise Exchange and add to the Address space list

          2. For the first, I want to thank you for your detailed explanation.

            BTW, you don’t need to set domain as Internal Relay it will work with Authoritative too.
            Two additional things should be done to achieve this goal:
            1. change group default address to instead of GroupName@YourSMTPDomain.tld – it will automatically change targetAddress attribute to this one, also ensure that the last one is presented as alias
            2. change send connector in on-premise Exchange and add to the Address space list

    1. I was able to resolve this issue. I have asked Microsoft Support to recommend this workaround so the Development team can bake this into the actual code.

      Basically I had to add the address to the list of Proxy Addresses of the Office 365 Group from Exchange Online Shell

      Then change the TargetAddress to this address (You will have to delete the TargetAddress attribute from the Synchronization Rules so it doesn’t sync back and overwrite)

      After this test email from On-Premise and External source. It should work for both

      1. Thanks for this Navaid. Let me make sure I understand you correctly –

        In Exchange Online, you add a proxy address with the domain to the O365 group.

        In exchange On-Prem, you change the target address to point to the domain.

        In AAD Connect, you block syncing of the targetaddress attribute from AAD to On-Prem.

        Do I have all that right?

        When sending mail from an external source to an office 365 group, does the message get delivered to the group mailbox as well as each individual member’s mailbox? When I had tried changing the target address previously the message was not getting delivered to the group mailbox.

        Blocking sync of the target attribute from Online to On-Prem seems like something that might come back to haunt me in the future. I wonder if I could instead add another transformation to the sync rule described in the article, which would modify the domain used in the target address. That way it would be filtered to the EXTERNAL description, and would be applied automatically instead of me having to manually change the target address on each group. I’ll have to read up on these synchronization rules a bit more to see if that can be done using an expression rule.

        It definitely seems like this would be the right track. Thank you very much for sharing!

        1. I wouldn’t block or delete the sync rule for targetAddress, as that will cause issues for things like mail-enabled users that are synchronized. You should set the domain for the Office 365 group to your address, because all mail for will flow through your hybrid connector to Office 365 if you’ve set your on-premises domain to internal relay.

  2. I too am receiving:

    554 5.4.6 Hop count exceeded – possible mail loop (in reply to end of DATA command)

    I believe it is due to my Exchange environment not knowing of the Write-Back Office 365 Groups in my AD structure. I have not solved this issue thus far.

  3. Hey, thanks for the great article. I have implemented this configuration. Prior to implementing this config, when emailing the O365 group from an external email address, the external user would receive the following NDR: Your message can’t be delivered because delivery to this address is restricted.

    After implenting the change mentioned in your article, the external user now receives this NDR:
    554 5.4.6 Hop count exceeded – possible mail loop
    554 5.0.0 Service unavailable

    Have you encountered this before? any ideas on resolving this?

  4. Thanks for this great article. I’ve implemented this, and the external sender receives a NDR with emailing the office 365 group. NDR states:

    554 5.4.6 Hop count exceeded – possible mail loop
    554 5.0.0 Service unavailable

    Please let me know how this issue can be resolved. Thank you

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.