Remote SMTP server never use 2nd MX record

[alexandre34]

Hello,

I have 2 Ironport C370 in centralized management mode.

2 MX records in my public DNS :

10      frel01.xxx.xx     [IP_Public_frel01]

20      frel02.xxx.xx     [IP_Public_frel02]

Those 2 records work fine, I checked them with online tools (mxtoolbox.com).

If I shut frel01 or if I shut SMTP service (Clusterconfig / disconnect + suspend) on frel01, frel02 should be used to send and receive external mails.

it works for sending external mails but not to receive, external mails are still received on frel01.

There is the result when I try with http://network-tools.com (I also tried to send a mail from a personnal mail)

SMTP session

[Contacting frel01.xxx.xx [IP_Public_frel01]...]

[Connected]

421 No SMTP service here

[Unfavorable reply code, cannot continue]

RSET

Why the remote SMTP server do not try frel02 when it sees that frel01 is unavailable ??

Thanks,

Alex

[Donald Nash · Accepted solution]

The 421 reply code is a temporary failure. It means, "I'm not working right now but I might work later." That's not sufficient to trigger the remote MTA to move to the next MX record. The SMTP listener needs to be shut down entirely, so connections to port 25 get "connection refused" or time out.

You can get better utilization of your two appliances by giving both MX records equal weight. That will split the load between the two units, assuming your DNS servers return their results round-robin style.

++Don

[Rick Williams · Accepted solution]

As Don says above. To balance the mail into your servers you should set the MX value on both to the same value.

Interestingly, spammers love to use the higher value as it's generally the less secure system.

Not all sending servers will use both MX records if they are equal, but you will get a better distribution of mail.

To test the failover to the other MX record, remove the network cable on the first system.

[alexandre34]

Giving both MX records equal weight fix the problem.

Thanks.

[Donald Nash]

It probably didn't fix the problem so much as mask it. The sending server will still defer when it gets the 421 greeting code, but it now has a 50/50 chance of getting the other server next time it connects. You could still experience significant delays on individual messages, although that's not particularly likely.

++Don