Clients can't email host cluster5a.us.messagelabs.com

[Anita Mano]

Our Server IP is cleaned, no spamming on the IP found/No issues. All records are correct however we're still seeing emails from the domain/ip sent to the below getting timed out/failing. Our client thinks its us. I've checked our IP in the PBL as well as on Symantec's site, found no issues. 

IP Address is 199.103.61.10

Sample of the bounced messages are below.

[e-mail]
Delay reason: H=cluster4a.us.messagelabs.com [54.165.145.171]:
SMTP error from remote mail server after RCPT TO:<[e-mail]>:
421 Service Temporarily Unav

No action is required on your part. Delivery attempts will continue for some
time, and this warning may be repeated at intervals if the message remains
undelivered. Eventually the mail delivery software will give up, and when
that happens, the message will be returned to you.
---------------------------------------------------------------------------------------------

[Martin Line]

I can see that the MX records for vaughan.ca are set up correctly as;

• 10 - cluster4.us.messagelabs.com
• 20 - cluster4a.us.messagelabs.com

That should mean that the client should send to the top record, cluster4.us.messagelabs.com, but the error message seems to imply that they are sending to cluster4a.us.messagelabs.com. That server is a deliberate trap for spammers that will often try to send to the lowest priority route in the hope that they can bypass security measures. If the client sends to the top MX record then the email should be successfully delivered.

[Anita Mano]

Hi, how does one sending an email choose where to send to?  cluster4.us.messagelabs.com

our client is simply sending an email to vaughan.ca , where/how can they select choose where it goes on the backend? you're saying my client is using cluster4.us.messagelabs.com instead of cluster4.us.messagelabs.com.

Please let me know what we the hosting provide/my client the person trying to email Vaughan.ca needs to do to ensure messages we send go through cluster4.us.messagelabs.com

same client is also receiving the same errors sending to
@td.com
host cluster5a.us.messagelabs.com [52.203.13.146]
SMTP error from remote mail server after RCPT
TO:<@td.com>:
421 Service Temporarily Unavailable: retry timeout exceeded

Im guessing the same issue. 

[Martin Line]

The issue will be with whatever setup the sender has for outbound mail, presumably a mail server. That should always send to the primary MX record for a given domain, but it is sending to the secondary. That should only happen if the primary is unavailable, but our infrastructure is global and high availability so that should never happen. I'm sorry, I don't know anything about mail server setup or why that server may be picking the secondary MX record to send to, but that is where the problem lies. Note that any cluster#a record is a honey trap for spammers and will fail.

[Anita Mano]

So you're saying the sender has to change their records to fix this issue with getting mails to the correct MX for these recipients?  especially when they have no issues emailing anyone but 2 clients who's bounceback are both showing messagelabs error?

Do you have any suggestions of what should be changed at the senders end in order for them to email these 2 domains and hit the correct cluster4.us.messagelabs.com.

We will check the senders records to verify. can you please confirm these IP's aren't blocked at your end 199.103.61.10 and 208.69.57.25. We checked the Symantec reputation and both show no issues but reading through your forums, I've seen you check the ips to see if they're blocked.

[Martin Line]

The records are set up correctly. Those IPs aren't blocked, the issue is at the senders end. The client mail server is trying to send an email, looking up the recipient domain in DNS and choosing the secondary MX record as the destination instead of the first. That is where the issue lies.

It may be worth the customer checking the routing from their mail server to cluster4.us.messagelabs.com to see if it is accessible. If that cannot be reached for some reason then the default action for the mailserver is that it should use the secondary server, which will just result in the error they are seeing.