Error 550-5.7.367 in Office 365 occurs when a message is rejected because the sending client or server is not authorized to relay mail through the tenant. This usually happens when external devices, third-party applications, or misconfigured connectors attempt to send email without proper authentication or when they are blocked by anti-spam policies designed to prevent unauthorized relay attempts.
Understanding the Error Code
The specific error code 550-5.7.367 indicates that the recipient's mail system has rejected the message due to an unauthorized relay attempt. In the context of Microsoft Exchange Online and Office 365, "relay" refers to the process where a mail server accepts a message from a sender and forwards it to another destination. While internal users typically authenticate directly against their mailbox, external entities must prove they are allowed to send on behalf of your domain. If this proof is missing or invalid, the server returns this rejection to stop potential spam or spoofing.
This issue often confuses administrators because it can appear as if the user’s password is wrong, but the root cause is almost always related to how the mail flow is configured rather than individual account credentials. It is critical to distinguish between a simple authentication failure (like bad password) and a policy-based rejection like 550-5.7.367, which specifically targets the relay mechanism itself.
Common Causes for Unauthorized Relay
There are several scenarios where this error manifests. Identifying the correct scenario allows you to apply the right fix without disrupting other services.
- Third-Party Applications: Many legacy applications or IoT devices do not support modern authentication methods like OAuth2. They often try to connect using older protocols or basic authentication over SMTP without properly authenticating first, leading to a relay rejection.
- Incorrect Send As Permissions: If a shared mailbox or resource account is being used to send email, the account attempting to send must have explicit "Send As" permissions. Without these, the system views the action as an unauthorized relay attempt.
- Misconfigured Connectors: Hybrid environments or custom connectors might be routing traffic incorrectly. If a connector is set to accept mail from untrusted sources without requiring authentication, it may trigger this error when those sources try to relay.
- Anti-Spam Policy Settings: The default anti-spam policies in Exchange Online are aggressive. If a sender’s IP address is not recognized or if the message headers suggest spoofing, the policy may block the relay before it even reaches the mailbox.
Solving Third-Party Application Issues
If you suspect a specific application or device is triggering this error, you need to verify its connection settings. Most modern Office 365 setups require apps to use OAuth2, but some older tools still rely on Basic Authentication. Microsoft has been phasing out Basic Auth, so many of these connections now fail with relay errors.
To resolve this, check the application’s documentation for supported authentication methods. If the app supports OAuth2, configure it to use the standard Office 365 login flow. If it only supports Basic Authentication, you may need to enable it for that specific user account via the Microsoft 365 admin center, though this is less secure. Alternatively, consider replacing the legacy application with one that supports modern security standards.
If you are managing Outlook profiles for users who encounter this while configuring accounts, ensure that the SMTP settings match the current Office 365 requirements. For more details on managing Outlook configurations, you might find How to Display a New Item Alert Window in Outlook helpful for general troubleshooting steps.
Checking Send As Permissions
When a user sends email from a shared mailbox, delegate, or resource account, the sending identity must be explicitly permitted. If the "Send As" permission is missing, Exchange treats the request as an unauthorized relay attempt because the sender is not the owner of the mailbox.
To fix this, navigate to the Exchange Admin Center. Go to Recipients and select the shared mailbox or group in question. Under the Mail Flow tab, click Manage Send As. Add the user or service account that needs to send email from this address. After adding the permission, wait up to 60 minutes for replication across all servers, then test the email delivery again.
If you are dealing with complex delegation issues, understanding how conversations are handled can be useful. For instance, if you notice conversation history loss between different clients, such as Troubleshooting Conversation History Loss Between Outlook and Samsung Android Clients, ensuring proper permissions helps maintain consistency in mail flow.
Reviewing Anti-Spam Policies
If the above steps do not resolve the issue, the problem may lie within the anti-spam policies. These policies filter incoming and outgoing mail based on reputation, content, and sender verification. A strict policy might reject a legitimate message if it fails SPF, DKIM, or DMARC checks, interpreting it as a spoofed relay attempt.
Check the Message Trace feature in the Exchange Admin Center. Look for the failed message and examine the detailed trace information. It will show exactly which policy blocked the message and why. If the block reason mentions "Relay Access Denied," it confirms the authorization issue. You may need to adjust the anti-spam policy to allow specific IPs or domains, but this should be done cautiously to avoid opening your tenant to spam.
Verifying Connector Configurations
In hybrid deployments, connectors define how mail moves between on-premises servers and Office 365. If a connector is misconfigured to accept mail from any source without requiring TLS or authentication, it can lead to relay errors when external parties try to send mail through it.
Review your inbound and outbound connectors in the Exchange Admin Center. Ensure that the IP addresses listed in the trusted senders list are accurate. Remove any unused or incorrect IP entries. If you are using a third-party spam filtering service, ensure that the connector is configured to trust the service’s IP addresses and that TLS is enforced for secure transmission.
Frequently Asked Questions
Does this error affect internal email delivery?
No, internal emails between users within the same Office 365 tenant are not affected by relay errors. This error only appears when mail is sent from outside the tenant or by applications that do not properly authenticate against the Exchange Online environment.
Can I whitelist an IP address to fix this?
Whitelisting an IP address in your anti-spam policies might help if the sender is known and trusted, but it does not solve the underlying authentication issue. It is better to fix the authentication method on the sending side rather than lowering security standards.
Is this error related to SPF records?
While SPF failures can cause similar rejections, the specific 550-5.7.367 code points to relay authorization. However, poor SPF configuration can exacerbate the issue by causing messages to be flagged as suspicious, leading to stricter relay checks.
How long does it take for permission changes to take effect?
Changes to Send As permissions or connector configurations can take up to 60 minutes to replicate across all Exchange Online servers. During this time, you may continue to see the error until the updates propagate.
What should I do if the error persists after fixing permissions?
If the error persists, check the Message Trace for detailed logs. Look for any additional blocks from anti-spam policies or DNS issues. You may also need to clear the cache on the sending device or restart the application to refresh its connection settings.