550 5.7.193, and why outside senders cannot email your Microsoft 365 group

A client emails your project group and it bounces. Internal mail to the same address works, which is what makes people start looking at spam filtering and mail flow rules. The bounce itself is more specific than that, and reading it first saves changing the wrong setting.

Read the bounce before changing anything

The group <group name> isn't set up to receive messages from <sender name>.
Status code: 550 5.7.193
550 5.7.193 UnifiedGroupAgent; Delivery failed because the sender isn't a
group member or external senders aren't permitted to send to this group.

That code is specific to Microsoft 365 groups, and it is issued by the group agent rather than by anti-spam. If the sender is seeing this, the mail reached your tenant and the group refused it on policy. Nothing about your connectors, your filtering or your DNS is involved, which rules out most of what people check first.

Note that the message names two possible causes and does not tell you which one fired. A group can reject outside senders wholesale, or it can accept them only when they are members. Both produce this code.

Permitting senders from outside the organisation

Groups do not accept unauthenticated mail by default, which is a deliberate choice on Microsoft's part rather than an oversight. There are two ways to change it and the right one depends on how open the group should be.

1. For a single known sender, add them to the group as a guest. The group then accepts their mail without opening up to everybody, which is the narrower and usually better option.
2. For a group that genuinely needs to receive mail from anyone, open the Exchange admin center, go to Recipients, then Groups, and select the group.
3. In the details pane choose Settings, tick Allow external senders to email this group, and save.
4. Wait before retesting. The change is not instantaneous, and an immediate retest that bounces will send you looking for a second problem that does not exist.

The same change from Exchange Online PowerShell, which is the practical route if you are doing more than one group:

Connect-ExchangeOnline

Set-UnifiedGroup -Identity "Project Falcon" -RequireSenderAuthenticationEnabled $False

The lookalike fault: mail arrives, members never see it

This gets reported in exactly the same words and is a different setting entirely. The group accepts the mail, the conversation is sitting in the group's mailbox, and no member has any notification of it. People conclude the mail never arrived.

The distinguishing test is whether the sender got a bounce. No bounce and no visible mail means delivery succeeded and the problem is subscription: whether copies of group conversations are being sent on to members' own inboxes. That is a per-group setting, and a newly created group does not do it by default, which is why this shows up most on groups created last week.

• Sender got a 550 5.7.193 bounce, so the group refused the mail. Fix the external sender setting.
• No bounce and nothing in anybody's inbox, so the mail was accepted. Fix the subscription setting.
• No bounce and nothing in the group's conversation view either, so the mail did not arrive. Now message trace is the right tool.

Distribution lists fail this differently

If the address is an old-style distribution list rather than a Microsoft 365 group, the sender authentication setting exists there too and behaves similarly, but the failure people actually hit is the reverse direction: mail to the list reaching internal members and not external ones. Microsoft documents that case separately, and it is worth confirming which object type you are looking at before applying advice written for the other one.

The quickest way to tell them apart is that a Microsoft 365 group has a SharePoint site and a Teams presence behind it, and a distribution list does not.