SMG doesn’t use higher preference MX routes?

I do not need a solution (just sharing information)

We have a compliance rule which routes matching messages to a domain name using MX records that we have defined in our DNS.  There are two MXes with preference 10 and one MX with preference 100.

During our most recent DR test, when both MX 10s were unavailable, the matching emails were just queueing up, Not willing to go to the MX 100 route.  I even started a TCPDUMP session which detected zero attempts to connect to the MX 100 target host.

Lowered the MX to 50.   Nothing.

Lowered the MX to 10, to match the other two – bingo, the emails flowed out to that target host.

So what’s going on there?  Is SMG’s routing logic broken?



Being throttled by Messagelabs Server

I need a solution

Hi Support throttling our mail servers.

We had issues on our mail queues and once we resolved it, a lot of mails were sent in the queues. Subsequently we are now being throttled. I have mailed, called Symantec Support to no avail. Please assist us urgently.

Date Received: 2019/03/25 13:56:19

Expiration Time: 2019/03/27 13:56:19

Last Error: 421 Service Temporarily Unavailable External MX record External MX record External MX record

Kind Regards




cluster{x} deferred mail from users at our domain

I need a solution


I am hoping someone from Symantec support could look into this problem.

When sending mail from our domain ( to customers whose MX records point to both


mail is being deferred with the following message:

dsn=4.0.0, stat=Deferred: 421 esmtp: protocol deviation

The source IP for’s mail relay ( is

I have checked the IPs reputation on and directly at and there’s nothing to see there.

Mail to MX records at (cluster{1,4} are delivering normally, but I see instances where mail to is also deferred with the same “protocol deviation” error.

It does seem that the cluster{N}a (where in is an integer like 1,2,3…) records are always the backup MX records for the domain. Is there some reason why when we initially queued the messages, the primary MX was unreachable and forced the switch to the backup? And now because the messages are queued for the “backup” and the “primary” is available we are being rejected (using a lower priority MX when the higher priority MX is available is a SPAMmer trick — hence the “protocol deviation”?)

Can anyone shed a little more light on why in particular cluster{N} and cluster{N} MX destinations are deferring (for days now) mail from our users?

Thanks for your insights.



Blocked IP address

I need a solution


my client ( is trying to email their parent company ( but their emails aren’t getting through the messagelabs filtering.

they are getting 421 service temporarily unavailable   when emailing out to this domain.

i checked this article so i checked their DNS. their DNS resolves correctly and does the nslookup for the MX records correctly but when i do a telnet into the primary MX it won’t connect, but it will to the secondary MX record.

also a tracert doesn’t get to the primary MX.
my clients domain is and they are trying to email to which has the MX records of and

can you please remove the block for the IP ( i did do a lookup of this IP on but it’s not listed with a negative reputation