One of the ways to configure Postfix in situation like yours is to define two outgoing smtp transport interfaces in master.conf:
mail.example.com-out unix - - n - - smtp
-o smtp_bind_address=198.51.100.30
-o smtp_helo_name=mail.example.com
-o syslog_name=postfix-mail.example.com
mail2.example.com-out unix - - n - - smtp
-o smtp_bind_address=203.0.113.40
-o smtp_helo_name=mail2.example.com
-o syslog_name=postfix-mail2.example.com
Then define 'default_transport' parameter in your main.cf:
default_transport = mail.example.com-out
Finally, create a shell script that checks your ISP connections regularly by cronjob and switches Postfix transport on the fly. Here is an example of such bash script (assuming your two ISPs connected to eth0 and eth1 interfaces. Alternatively, use -S switch for ping command below defining source ip address: ping -S 198.51.100.30 -c 2 $SERVERIP... - particular way depends on your configuration of two gateway interfaces/routing table), it shoud be run under root:
#!/bin/bash
SERVERIP=8.8.8.8
ping -I eth0 -c 2 $SERVERIP > /dev/null 2>&1
if [ $? -ne 0 ]
then
echo "ISP1 is down"
ping -I eth1 -c 2 $SERVERIP > /dev/null 2>&1
if [ $? -ne 0 ]
echo "ISP2 is also down"
else
echo "Switching to ISP2"
sed -i 's/mail.example.com-out/mail2.example.com-out/g' /etc/postfix/main.cf
systemctl reload postfix
fi
else
echo "ISP1 reachable"
if grep -q 'mail2.example.com-out' /etc/postfix/main.cf; then
echo "Switching back to ISP1"
sed -i 's/mail2.example.com-out/mail.example.com-out/g' /etc/postfix/main.cf
systemctl reload postfix
fi
fi
Root's crontab (run 'crontab -e' under root to edit) example to run the script once in every 2 minutes:
*/2 * * * * /path/to/your/script.sh 2>&1 | ts | tee -a /var/log/check_postfix_transport.log
Rationale:
SMTP banner is defined only for the smtp daemon (server) receiving the incoming connection from the smtp client. With the SMTP banner server identifies itself for the connecting client during session initiation. It is optional, however.
From RFC 5321:
3.1 Session Initiation
An SMTP session is initiated when a client opens a connection to a
server and the server responds with an opening message.
SMTP server implementations MAY include identification of their
software and version information in the connection greeting reply
after the 220 code.
Client (for example another server that wants to deliver email to the incoming server) never sends SMTP banner to receiving server. What is sends to server is EHLO/HELO host name and this is the very thing that is checked by servers against PTR mismatch with regard to spam, etc.
From RFC 5321:
3.2 Client Initiation
Once the server has sent the welcoming message and the client has
received it, the client normally sends the EHLO command to the
server, indicating the client's identity.
Based on EHLO/HELO the server may check PTR (if SMTP sending party's ip resolves back to its host name) and/or spf and finally decides if it really wants to receive or relay the email message originating from the SMTP client.
Based on this, what you should do in general is to care about EHLO commands that your SMTP server sends to other servers when it wants to send email messages to them (and acts as an SMTP client during these connections). You should ensure that your SMTP server uses proper source ip address and sends proper EHLO host name that resolves back to that ip used for connection. And you may basically ignore SMTP banner simply because it is about receiving email, not sending.
I guess that mxtoolbox also mixes up SMTP Reverse DNS Mismatch and SMTP Banner Mismatch and checks the latter for no reason, and its wording about SMTP banner with that regard is partially incorrect. SMTP rDNS Mismatch does matter, SMTP Banner Mismatch does not. Again, SMTP banner is sent by the recieving server (that is why it is defined in Postfix in 'smtpd_banner' parameter, not in 'smtp_banner') and not by the sending/relaying client. Thus it has nothing to do with spam, etc.
In this sense the SMTP banner serves the same purpose that certificates do to identify the receiving server, though without the third party chain of trust.