550 5.7.367 is an SMTP rejection code that usually indicates a permission or security problem during message relay. The server has refused to forward the email because it cannot verify that the sender is authorized to use that SMTP path. It is a transport-level failure, not a content-level rejection.
What the code means in SMTP relay
550 5.7.367 is not a message-content failure, it is a transport and policy refusal. In practice, the SMTP server is saying the sender is not authorised to use that relay path, so delivery stops before the message is accepted for forwarding.
This matters because the code often points to authentication, authorisation, or relay policy controls rather than a malformed email. A mail administrator should treat it as a signal to inspect who is trying to send, through which path, and under what trust relationship.
Why relay refusal happens
SMTP relays are designed to forward mail only for permitted senders, domains, or networks. When that trust decision fails, the server may reject the transaction with a 5.7.x-class response instead of attempting delivery.
That refusal can be intentional, for example when the mail system blocks unauthenticated relays, or accidental, for example when a connector, smart host, or sender policy no longer matches the expected trust boundary. The code does not by itself tell you which policy failed, only that the server would not forward the message.
How to check exposure and scope
To understand exposure, start with the mail path itself: identify the sending system, the SMTP submission or relay route, and whether the sender is expected to authenticate. Then compare the failing path against approved connectors, relay rules, and vendor documentation for the mail platform in use.
It is also useful to confirm whether the issue is isolated to one application, one mail server, or one sender population. If the same rejection appears across multiple systems, the problem may sit in shared mail infrastructure, network allowlisting, or a central policy change rather than in a single client.
Remediation and verification
Fixes usually involve restoring the correct trust relationship: authenticate the sender properly, use the correct submission host, or align the relay configuration with the organisation’s mail policy. If the sender is supposed to be allowed, the configuration mismatch should be resolved at the server or connector layer rather than worked around in the message itself.
After the change, validate by sending a test message through the same route and confirming that the server now accepts relay. Then review logs for repeated failures, because a persistent 5.7.367 pattern can reveal a misconfigured application, expired credentials, or an unintended policy block.
Risk and Threat Considerations
This code matters because relay controls are a security boundary, not just a delivery setting. If they are too loose, unauthorised systems can abuse the mail path for spam, phishing, or reputation damage; if they are too strict or misaligned, legitimate services can fail to send operational mail.
Failure mechanism: The server refuses a relay attempt when the sender cannot prove it belongs to the authorised set for that SMTP path, which is often the right outcome but can also expose configuration drift or broken trust assumptions.
Impact: The immediate impact is message delivery failure, but the deeper operational impact can be lost alerts, failed workflow emails, delayed customer communication, or a hidden mail-control gap if administrators respond by weakening the relay policy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | SMTP relay refusal enforces policy on who may forward mail. |
| IA-2 — Identification and Authentication (Organizational Users) | Relay denial often follows failure to authenticate the sending user or process. | |
| SC-7 — Boundary Protection | The code reflects a boundary decision at the mail relay trust edge. | |
| Recommendation — Apply AC-4 to restrict mail relay paths to authorised senders and systems. Require strong authentication before allowing access to SMTP submission or relay services. Enforce SC-7 at mail gateways to allow only approved relay traffic across trust boundaries. | ||
| CIS Controls v8 | CIS-5 — Account Management | Mail relay access depends on correctly managed sender accounts and service identities. |
| Recommendation — Inventory and govern mail-sending accounts so only approved identities can relay email. | ||
Practitioner Guidance
What to watch for: Treat repeated 550 5.7.367 responses as a configuration and control signal, not a mail-body problem. The most useful next step is to verify the sending identity, relay route, and policy that authorises that route, then confirm the fix with a controlled resend.
Practitioner note: When the rejection is legitimate, preserve the control and correct the sender; when it is accidental, repair the trust path without broadening relay permissions beyond what the application actually needs.