550 5.7.367 means Microsoft 365 forwarded or relayed a message and the next server refused it as "not permitted to relay". The address is fine. The fix sits in the forwarding tenant's settings, and when a gateway sits in front of Microsoft 365 it is usually Enhanced Filtering for Connectors.
How to read the result
The bounce carries two codes joined by an arrow: Microsoft's, then the next server's reply, which usually just says relaying was denied. The real reason is on Microsoft's side of the arrow.
When a message fails authentication on its way into Microsoft 365, a forward of it is more likely to leave from a separate relay pool. Microsoft does not publish that pool, and it is not in Microsoft 365's SPF record, so the next server does not treat the message as Microsoft's. An admin can confirm it in the message trace, where OutboundIpPoolName reads RegularRelayOutboundPool.
How to fix 550 5.7.367
Microsoft's 5.7.367 troubleshooting article gives three fixes, each aimed at making SPF pass on the way in:
Your MX record points to a third-party gateway or an on-premises server. Turn on Enhanced Filtering for Connectors, so SPF is checked against the original sender.
The original sender's own SPF fails. That domain's admin lists every service that sends as it.
The sender is a domain you control. Add it as an accepted domain in Microsoft 365.
Allow-listing the relay pool on the far gateway chases a list nobody publishes, so fix the way in instead.
What to do next
If you only sent the message and never set up a forward, the recipient's mailbox probably forwards your mail, and none of these settings are yours. Tell the recipient their forward is failing, and reach them another way until their admin fixes it.