5.7.367: Remote server says not permitted to relay (Microsoft 365)

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code: varies; the enhanced code is the part that identifies the problem.
• Enhanced code 5.7.367: not in the IANA registry; the group is security or policy status (RFC 3463 §3.8).
• Who uses it: Microsoft (Exchange Online): remote server returned not permitted to relay.

A 5.7.367 bounce from Microsoft 365 means a message that your organization forwarded or relayed was refused by the next server, because it failed SPF or DKIM there. The text usually says the remote server returned "not permitted to relay".

What it means

This is Microsoft's code, not one from the IANA registry. Microsoft's Exchange Online NDR reference describes it as a remote server that answered "not permitted to relay". The usual reason is an SPF or DKIM failure on mail that Microsoft 365 passed along. Microsoft notes it is more likely when the path includes servers outside Microsoft.

So the refusal did not happen at Microsoft. Microsoft 365 handed the message on, the next server checked it, and Microsoft is reporting that server's answer.

Why forwarding breaks authentication

SPF checks whether the server delivering a message is listed in the sending domain's SPF record. When a mailbox forwards mail, the message now arrives from Microsoft's servers, which are not in the original sender's record, so SPF can fail (RFC 7372 §3.2 defines the SPF failure code). DKIM is a signature over the message. If anything along the way changes the signed parts, such as a footer, a disclaimer or a subject tag, the signature no longer matches. Depending on the next server's policy, either failure can be enough for it to refuse the message.

Common causes

• A user's rule forwards all mail to an outside address, such as a personal mailbox.
• A transport rule or connector relays mail through another server or gateway outside Microsoft.
• A disclaimer or footer is added to messages after they were signed.
• The original sender's domain has no DKIM signing, so only SPF was available, and forwarding broke it.

How to fix it

If you run the forwarding organization:

1. Find which rule, mailbox forward or connector sent the message on.
2. Where you can, deliver to the final mailbox directly instead of forwarding to an outside server.
3. Do not change messages (footers, disclaimers, rewritten subjects) on the way through, or do it before signing.
4. Check that connectors to outside gateways send to the right destination; see also 5.7.520 if forwarding is blocked by policy.

If you are the original sender:

1. Sign every message with DKIM (DKIM checker), so it can still pass where SPF fails after a forward.
2. Keep SPF current (SPF checker) and see 5.7.26 for combined failures.

What to do with the address

Keep it. The address works; the path the message took after reaching it is the problem.

Related codes

• 5.7.520: External forwarding is not allowed (Microsoft 365)
• 550 5.7.23: SPF validation failed
• 550 5.7.26: Unauthenticated: SPF and DKIM failed, or DMARC rejected it

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.