MailFixIt

Microsoft 365 relay rejection

Fix 550 5.7.367 Remote server returned not permitted to relay

Microsoft 365 forwarded or relayed a message to another mail server, and that server refused it. The text after -> gives the downstream reason.

Problem description

The Microsoft 365 NDR usually contains:

550 5.7.367 Remote server returned not permitted to relay -> 554 5.7.1 Relaying denied
550 5.7.367 Remote server returned not permitted to relay -> 554 5.7.1 <recipient@example.com>: Relay access denied

Run this automated test on my domain

Enter your domain. MailFixIt checks the relevant DNS records automatically and shows the evidence.
Is this temporary or permanent?

The 550 response is permanent for this attempt. Fix the mail path, then send a new message.

Read the complete error

550 5.7.367 is a Microsoft 365 wrapper around a rejection from the next server. The useful part is after ->.

For example, 554 5.7.1 Relaying denied means the downstream server refused to accept the message as local mail or as an authorized relay. It does not automatically mean that your Outlook password is wrong.

The common Microsoft 365 cause

Microsoft documents this sequence:

  1. An external message enters Microsoft 365 through forwarding or a non-Microsoft gateway.
  2. SPF is fail or softfail, and DKIM does not pass.
  3. Microsoft 365 sends the message through RegularRelayOutboundPool.
  4. The downstream gateway does not trust that pool and rejects the message.

Microsoft is less likely to use the relay pool when at least one of these is true when the message enters Microsoft 365:

Fix the Microsoft 365 path

  1. Open the failed message in Microsoft 365 message trace.
  2. Check whether OutboundIpPoolName is RegularRelayOutboundPool.
  3. Check the inbound Authentication-Results for SPF and DKIM.
  4. If mail enters through Proofpoint, Barracuda, Plesk, or another gateway, configure Enhanced Filtering for that inbound connector. This lets Microsoft evaluate the original sender instead of only the gateway IP.
  5. If you control the sender domain, confirm that it is an accepted domain in Microsoft 365.
  6. Make SPF or DKIM pass when the message first enters Microsoft 365. Preserve DKIM and ARC headers across gateways where possible.
  7. Remove unnecessary forwarding hops, then test the same route again.

Do not add relay pool IP addresses to SPF or a permanent allowlist. Microsoft does not publish this pool because it changes, and it is not part of the normal Microsoft 365 outbound ranges.

If the nested reply says Relay access denied

The downstream server may have a separate routing problem. Check where the recipient mailbox actually lives.

In the Plesk community example, Postfix treated the domain as local while some mailboxes lived in Microsoft 365. A working setup used local recipient entries that forwarded those users to the tenant’s *.mail.onmicrosoft.com routing domain. That is specific to split delivery. Do not copy it unless your mailboxes are intentionally split, and do not disable the global Plesk virtual mailbox maps because that can break other inbound mail.

What to send to your administrator

Provide the complete NDR, UTC timestamp, sender, recipient, Microsoft 365 message trace, original message headers, and the downstream gateway log for the same attempt. These items show which of the two paths above failed.

What MailFixIt can check

Paste the domain, bounce text, and message headers into the checker. Add the sending IP and DKIM selector when known. The result can expose relevant SPF or DKIM problems, but the Microsoft 365 trace and gateway logs are still required to prove this specific relay failure.

Frequently asked questions

What does Microsoft 365 error 550 5.7.367 mean?

Microsoft 365 tried to forward or relay a message, but the next mail server rejected it. Read the response after -> to see the reason returned by that server.

Why can error 5.7.367 be intermittent?

Only some forwarded messages may fail authentication when they enter Microsoft 365. Those messages can use the relay outbound pool while other messages use the normal outbound pool.

Should I add Microsoft relay pool IP addresses to SPF or an allowlist?

No. Microsoft says the relay pool is unpublished, can change, and is not part of its normal outbound ranges or SPF record. Fix inbound authentication or routing instead.

Can MailFixIt confirm the complete cause?

MailFixIt can find relevant SPF, DKIM, and header evidence. A Microsoft 365 administrator must check the message trace, outbound pool, connectors, and downstream gateway logs.

Related email diagnostics

Outlook 550 5.4.1: Relay Access DeniedDiagnose Microsoft 365 550 5.4.1 relay access denied or recipient address rejected without assuming one DNS cause. Outlook 550 5.7.23: The message was rejected because of Sender Policy Framework violationDiagnose Outlook and Exchange Online 550 5.7.23 SPF violation using the actual sender IP, MAIL FROM domain and current SPF record. SMTP 550 5.7.20: No passing DKIM signature foundUnderstand SMTP 5.7.20, inspect the DKIM selector and public key, and fix a missing or failing DKIM signature without guessing DNS values. Outlook 550 5.7.515: Access denied, sending domain does not meet the required authentication levelDiagnose Outlook 550 5.7.515 email rejection safely. Check SPF, DKIM and DMARC DNS, interpret the receiver report, and identify the next configuration step.

Primary sources: Microsoft: Forwarded or relayed messages rejected with 5.7.367, Microsoft: Enhanced Filtering for Connectors, Plesk community: Split delivery with Microsoft 365.