550 5.7.367 Remote server returned not permitted to relay

Why it happens

When a message fails authentication on the way into Microsoft 365, Exchange Online is more likely to forward it from a relay pool IP that is not in the Microsoft 365 SPF record. Downstream gateways then block it. A common trigger during migrations is an inbound gateway or on-premises server in front of Microsoft 365, which makes SPF check the gateway IP instead of the original sender.

Where you see it, and what it affects

The NDR reads 550 5.7.367 Remote server returned not permitted to relay -> 554 5.7.1 Relaying denied, and the downstream gateway logs show "relay denied". It affects mail that Exchange Online auto-forwards or relays for external senders, and it happens more often where a non-Microsoft gateway is in the mail flow. In message trace, failed messages show OutboundIpPoolName as RegularRelayOutboundPool. Senders in your accepted domains, or messages that pass SPF on the way in, avoid this pool.

How to fix it

1. 1

   Step 1

   If your MX record points to a third-party filter or on-premises server, configure Enhanced Filtering for Connectors so SPF is checked against the original sender.

2. 2

   Step 2

   If you own the sender's domain, add it as an accepted domain in Microsoft 365.

3. 3

   Step 3

   Reduce forwarding hops and automatic forwarding chains.

Check that it is fixed

• In the Exchange admin center, run a message trace on new forwarded messages. They should no longer fail with 5.7.367 or show RegularRelayOutboundPool.
• Open the headers of an inbound message that gets forwarded. Authentication-Results should show spf=pass, not fail or softfail.
• Check the downstream gateway logs. They should no longer show "relay denied" for those messages.

Sources

Full guide: How to cut over email DNS without losing mail →