My gut feeling says "this isn't a problem and logically cannot really be fixed". I am configuring a backup ISP connection for use with our onsite exchange mail server.

This is what I have set up: -> primary ISP -> backup ISP

The following added to our example.com domain DNS:

mail.example.com. A
mail2.example.com. A
example.com. MX 10 mail.example.com.
example.com. MX 20 mail2.example.com.

PTR added by relevent ISPs: mail.example.com mail2.example.com

Now, our mail server always worked with just mail.example.com as the banner, all is well, MXToolBox is happy. However, what do I do with the banner regarding our failover MX? Obviously the failover PTR is mail2.example.com and will produce a "Reverse DNS does not match SMTP Banner" in MXToolBox.

Do I just not worry about this or have I not set something correctly?

EDIT: SSL SAN cert installed on mail server has both mail.example.com and mail2.example.com.

  • As a comment to my above, I could have used a DNS failover entity such as DNSMadeEasy, leave a single MX record and let the DNS failover happen via a third party (with appropriate firewall rules). However I am going to use the solution I selected as answer as this ensures that the system can use either IP regardless and there will be no chance of a mismatch between firewall sending via IP2 and the third party DNS failover still in TTL for IP1 – AngryCarrotTop Sep 19 '19 at 9:15

On best practices: have two MX servers

The best option is to have two servers i.e. configure another Exchange (or alternatively an opensource based SMTP server, e.g. Postfix) as a backup/secondary MX server. In most cases the server itself may cause more downtime than the Internet connectivity. As the banner mismatch is only an issue on outbound mail, this server could perfectly fine be the mail2.example.com in your current configuration.

A single server with two Internet connections

Configuration for outbound mail

Second approach would be to have both connections configured with the same hostname, as it in fact is the same host with to different IP addresses and routes. That could be achieved with a round-robin DNS configuration + matching PTR records & SMTP banner e.g.

mail.example.com. A
mail.example.com. A PTR mail.example.com. PTR mail.example.com.

Do not forget to add an SPF record allowing both IP address to send mail, e.g.

example.com. IN TXT "v=spf1 +ip4: +ip4: -all"

Configuration for inbound mail

If you want to prefer the first ISP over the secondary on inbound mail (for example if it has better bandwidth), you could separate your MX configuration from this e.g. by adding

mx1.example.com. A
mx2.example.com. A
example.com. MX 10 mx1.example.com.
example.com. MX 20 mx2.example.com.

The banner mismatch is not a problem for inbound mail, so this would be perfectly fine.


To keep the certificate valid for both configurations it should now have SANs for all mail.example.com, mx1.example.com and mx2.example.com. Generally this doesn't matter so much, as mail server certificates are only seldom actually valitated, and most mail systems would still allow falling back to unencrypted connections.

Instead of CA based certificate validation, DNS-based Authentication of Named Entities (DANE, RFC 6698) is a proposed alternative, allowing verification of self-signed certificates, too. For backwards compatibility it's not possible to configure an SMTP server to only allow encrypted connections, which leaves a hole for MitM attacks for connections that could be established over TLS. With DANE it's possible to declare that TLS should be used for the connection and only certificates published in the DNS zone should be allowed.

| improve this answer | |
  • I'll not edit the question but yes, but I updated my SPF with the extra IP added. Since I have exchange already it possible to get another license but expensive. Since the answer seems to be "not possible without 2 servers" I am now looking at scripting. When our firewall fails over it can run a script as part of the gateway alarm, I am looking at scripting a banner change at this point. – AngryCarrotTop Sep 18 '19 at 7:52
  • In my answer, 284 of 354 words are about how to do this with a single server. Please read it as carefully as I was trying to be thorough. – Esa Jokinen Sep 18 '19 at 10:38
  • TL;DR: Do not try and change the banner, but use the same hostname in both of your PTR records. The scripting adds complexity; therefore, it's more likely to fail. – Esa Jokinen Sep 18 '19 at 10:42
  • After more careful consideration, this is the solution I will be using. SSL is via letsencrypt so not a problem with added domains. I will be implementing a "3 A record solution" two 'mx A records' and a third ptr for both IP addresses (both IP addresses with the same third A record as a "round robin"). All three A records will live on the SSL cert, IPs are already on the spf so no change there. – AngryCarrotTop Sep 18 '19 at 19:31

You only need to worry about what the banner name is when mail2 is used to send an outgoing mail. And in that case, it should still match the reverse DNS for the IP it is using. About the only thing left to check is that the proper name is used in any SSL certs (all 3 names need to match for each server - banner/helo name, name in SSL cert, and reverse lookup) and that the backup server is listed in any SPF records, etc. As far as that goes, my SPF records simply list "all MXs for this domain".

So yes, as far as I can tell with what you've posted you should be good to go.

| improve this answer | |
  • I will edit that the SSL cert also has mail.server.co.uk and mail2.server.co.uk - it is simply the banner that will be different when primary ISP goes down. At that point all incoming mail will be via mail2.server.co.uk and outgoing mail will be mail2.server.co.uk - note that there is only one mail server so as far as I can tell I can only put one SMTP banner hence the question. – AngryCarrotTop Sep 17 '19 at 18:53
  • @AngryCarrotTop now i'm confused. one box with multiple ips from different providers? Then the ISPs need to configure reverse DNS for all IPs to point to the banner name used. Your question wording sounded like you have two servers, and two connections, and the backup server kicks in when ISP one goes down. In which case my answer applies. – ivanivan Sep 17 '19 at 19:52
  • one exchaneg server not servers. PTR (for domain listed in each MX) is registered with each ISP - i.e. mail.example.com with ISP1 and mail2.example.com with ISP2. – AngryCarrotTop Sep 18 '19 at 7:39
  • @AngryCarrotTop in that case, all reverse DNS should map to the banner name used. Keep the one DNS entry for mail2 so that your backup mx delivery will work, although having an actual second server for the backup mx is better. – ivanivan Sep 18 '19 at 12:57

You are right with your gut feeling that this is not an actual issue because of two things:

  1. MX records govern where you want to receive incoming email messages for your email.
    Your backup MX record is not intended to be used to send mail, only to receive incoming mail.

    Receiving email is easy: Although some senders may have have slightly more strict checks on for instance the contents of a TLS certificate for backwards compatibility almost all senders will simply deliver mail to your MX records as long as something is both listening on TCP port 25, responds correctly to SMTP protocol messages and is returning a "250 Requested mail action completed successfully" response after accepting mail for delivery to you.

(It is only sending email reliably that definitely requires much more careful configuration and protocol adherence.)

  1. The incoming SMTP server does not need to identify itself at all. It only has to accept messages it wants to receive and reject any it does not. (Only the sender is required to identify itself.)

    As far as I know only the actual SMTP response return code number in almost all server messages is relevant for the protocol itself. The text following the SMTP server response code not only in the banner message, but also in error and most other messages is only interesting for debugging purposes / human interaction and not relevant at all from a SMTP protocol perspective (and mostly ignored). Please note that is only for server messages, to combat spam SMTP servers themselves are much more strict on what they require when receiving messages from clients/other mail servers.

From RFC 5321 :

SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems. Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns

| improve this answer | |
  • This was my thinking but I was concerned that failover IP2 would trigger spam traps. Ironically enough Im not sure what my setup would do - I use puremessage as my spam filter so would need to look up "what does puremessage do with banner mismatches". Oddly enough, bbc.co.uk secondary mx has a banner mismatch.... – AngryCarrotTop Sep 18 '19 at 19:36
  • Spam detection is based on the behavior of the sender , not of the behavior of receiving (your) mail server – HBruijn Sep 18 '19 at 20:09
  • In this situation, however, the secondary MX is actually the same server. If ISP1 gets down, mail will be sent using the secondary IP. That's why it's problematic. – Esa Jokinen Sep 19 '19 at 3:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.