Emails not being delivered outbound in the Cloud Service for Email
Article ID: 262047
Updated On:
Products
Issue/Introduction
You are seeing mail queuing in your cloud MTA, which is sending messages to the DLP Cloud Service for Email.
Environment
DLP Cloud Service for Email
- Usually configured in Forwarding mode with Email Security.cloud (aka MessageLabs) downstream of the DLP Cloud Service
Cause
Further research on the emails at the Cloud Service reveals the following codes occurring for a lot of emails coming from the customer MTA to DLP:
553 Mailbox <random-string-1>@<domain>.com is not allowed
553 Mailbox <random-string-2>@<domain>.com is not allowed
553 Mailbox <random-string-3>@<domain>.com is not allowed
These errors do not originate from the DLP Cloud Service for Email, which is acting as an SMTP Proxy between upstream and downstream MTAs, so they are being passed from downstream MTA through DLP.
Although RFCs for 5XX errors indicate they should not be resent, it seems the upstream MTAs (e.g., O365, or Exchange) are placing the messages into their RETRY queue.
This can lead to several minutes of delays for each message.
If enough messages are sent rapidly, it can noticeably impact outbound email at the upstream MTA - causing queueing as each message exhausts the configured RETRY mechanism (e.g., being resent every 7, 15 or 22 minutes, for up to 24 hours).
Resolution
To address this issue, look specifically for any messages being returned with 5XX SMTP error codes. These usually indicate problems which can cause significant queuing upstream.
Customer should review their email address lists to verify if any recipient mailboxes need to be updated or removed from the system.
Complete resolution usually involves detailed analysis of existing Distribution Lists and Email boxes - ensuring they contain only valid addresses.
In some cases this means that old Distribution Lists may need to be purged of users no longer with the company, or email Transport Rules updated accordingly (maybe skip DLP if messages don't need to be inspected).
Additional Information
In some cases, email administrators will be reporting that messages in the queue show the following errors:
Reason: [{LED=451 4.4.400 Error communicating with frontend host or destination host. -> 421 4.4.2 Connection dropped due to SocketError};{MSG=};{FQDN=smtp-europe-west1-p11-i01-si01.dlp.protect.broadcom.com};{IP=144.49.245.98};{LRT=8/14/2023 8:31:10 AM}]. OutboundProxyTargetIP: 144.49.245.98. OutboundProxyTargetHostName: smtp-europe-west1-p11-i01-si01.dlp.protect.broadcom.com
The Socket Error in general simply means the MTA cannot connect to the DLP CDS - but this is not because we are refusing connections. It could be for different reasons (a network issue on the customer side, or can also happen when the MTA is configured to send to DLP on an incorrect port - not 25).
While the socket errors reported may lead to a delay for a 1-2 minutes at most, they will not cause delays in the same way that recurring 5XX errors will for other email services connecting to the DLP Cloud Service.
A similiar but different issue (550 errors being returned), specific to Address Registration in Email Security.cloud, is described in this KB:
Email rejected from DLP CDS for external recipients but not internal ones (broadcom.com)
Email Security.cloud can return a whole series of errors through DLP back to the upstream MTA. This KB covers those:
Email error and bounce codes for Email Security.cloud (broadcom.com)
Feedback
