Reverse DNS does not match SMTP Banner

It appears that this question, or ones similar, have been asked previously, but I did not find a solution in the responses that were given.


Here is my scenario...

I have a Exchange server behind the UTM that hosts multiple domains (my own personal domains). Recently I have been experiencing more occasions where mail messages sent from my domains are ending up in a users junk/spam folder. Obviously this is undesirable.

Tests on MXToolbox return no errors, but there are a few warnings, the one I am most concerned about being "Reverse DNS does not match SMTP Banner"

I recently changed ISPs and that meant that my fixed IP changed too. Initially there was a problem with my reverse DNS, but that was resolved.


On the Exchange server you can configure multiple Send Connectors (one for each domain) and these normally deal with the HELO/EHLO requests. However, these are overridden by the UTM (Email Protection > SMTP > Advanced > Advanced Settings > SMPT Hostname). It would appear that whatever is set there is what is seen for a HELO/EHLO request.
I have tried leaving the SMTP Hostname blank, but that is worse. Then the UTM simply reverts to the UTM's hostname.

The end result is that the "Received: from" header does not match any of my email domains, which I assume is causing me the issues.


I believe that technically I could set the SMTP Hostname on the UTM to the MX name of one of my domains and set the MX records of my other domains to match, but that would be quite undesirable. I need the Received header to match the hostname of the email being sent.
Receiving mail to multiple domains is not an issue at all.


So, this is my question...

Is there a way I can use the SMTP proxy on the UTM but have my Exchange Send Connectors do the HELO/EHLO response?

Or maybe there is another way I can get around this issue of multiple email domains behind the UTM.


As always, I am open to suggestions.


UTM v9.502-4

Home License

  • You can ignore the warning on mxtoolbox about the rdns entry. The main thing is to actually have an rdns as most spam filters will do an rdns check to make sure there is one.

    What the actual entry is doesn't really matter in my experience.

  • In reply to Louis-M:

    Yeah.... I thought that too, but this does not account for an increased amount of messages now being seen as SPAM.

    I have run the same Exchange server for over 10 years and this has only become a problem since changing my ISP about 12 months ago. As mentioned, my RDNS is valid.
    I am in the planning stages of upgrading my server environment and wanted to address this issue at the same time, but I am not finding any solutions as yet.

  • In reply to BigO:

    Have you tried to nslookup <your public IP-address that your Sophos mail protection is using>

    and then enter the name that appears as the SMTP-hostname in settings? That is wat did the trick in my environment.

  • In reply to apijnappels:

    Yes, I did think of doing that and in fact I tested it too.

    As much as it appears to resolve the SMPT banner issue, I am concerned that it will create even more problems, as this contains my ISPs domain name, not mine.

    RDNS = (where xxx-xxx is the last 2 octets of my fixed IP address)

    My concern is that using the above will make it look like I am a relay, as the RDNS does not include any of my domains.
    What I think should work is to configure multiple send connectors in Exchange, as you can specify the HELO/EHLO FQDN there, but I do not see a way of doing this with the UTM in front of the Exchange server.

  • In reply to BigO:

    You can safely do this. Spam filters check various ways but some things that most insist on is the IP comes from a static range and has a valid rdns entry.

    I've never had an issue apart from Microsoft and that was down to some sort of reputation filter that only allows x amount of mail. Never had an issue with rdns though and if you are concerned, you could strenghten it up with SPF and DKIM

  • In reply to Louis-M:

    Okay... even if the SMTP Banner issue is resolved by using the RDNS string in the UTM, I am still seeing messages to some recipients being classified as SPAM/Junk.

    The UTM, as I see it, only allows you to set a single HELO/EHLO response and if the RDNS sting is used it does not resemble any of my email domains in any shape or fashion.
    I am in no way a mail expert, so I may be seeing issues that do not actually exist, but I would think that some weight for "is it SPAM or isn't it?" would involve the HELO/EHLO response a mail server gets from my UTM.

    gMail was fine to send to a week ago, but now when I send test mail messages to that domain every message is going into the Junk folder. I now fear that my IP address has been identified by gMail (and others) as "dubious" and no matter what I change from this point onward will have no effect.

    I have been running my own mail server for nearly 20 years now and this is the first time I have had problems like this. I am currently at the point where I have run out of ideas about how to fix this issue of my mail messages being seen as SPAM.

  • In reply to BigO:

    Your IP can have only one PTR record or RDNS name. Has nothing to do with sophos hostname
    The simple way is to put that hostname in every MX record

  • In reply to BigO:

    I run an email environment with multiple domains, and I think your spam problem lies elsewhere.

    The method for configuring an rdns entry for youself  is called SWIP, which I believe stands for Shared Whois for IP.   Your ISP helps set it up.

    You pick one host name and use it for all of the mx records, for the swip record, and for the smtp hostname in EHLO.

    If you are sending high volume, you may need to register all of the above wifh aol, yahoo, google, etc.   Their requirements differ, and some may appear to require one rdns for each domain, but they have been reasonable in my experience.

    The most important step is to collect examples of blocked mail.  The headers usually provide valuable insight.   Then check with the admins of those services if you still have unanswered questions.

    Because so much legitimate email is sent by third parties, I have never seen a spam rule that links the server name to any other message content.

    You do need to ensure that all of your email is clean.   In a multi-client environment, one misbehaving client can blacklist your server, causing problems for all clients.

  • In reply to DouglasFoster:

    Apologies for the delay in replying, but you know how it is... sometimes you just get busy.

    A while back I had considered using a single domain name as the MX for all of my domains, but resisted going down that path as I did not want to link any of the domains to another.
    Upon some further investigation I believe that I can modify my RDNS from the one assigned by my ISP to one of my own domains. I intend to contact the ISP this week to confirm this.
    If that is the case, I am considering purchasing another "generic" domain to use as my MX gateway. TLDs are plentiful and cheap these days, so if as you say, using the one domain name for the MX, RDNS and HELO/EHLO will work then I am willing to give it a try.

    I will also contact some of the people I know have received my mail messages in their junk folder and see if I can talk them through getting me the header information.

    I can only assume that this problem started as a result of not having a RDNS for a period of time when I changed ISPs. That was a screw up by the ISP, but I seem to be paying for it.
    My mail server and domains have been online for about 15 years in their current configuration and it's never been a problem, until now. It's a real PITA.

  • In reply to BigO:

    I have decided to take a bit of a sideways step, prior to doing anything radical.

    As I have mentioned previously, everything used to work fine prior to me changing ISP and getting a new fixed IP. I am pretty sure that the main issue was that the RDNS was not configured properly by the ISP for the IP they allocated me. That was sorted out, but I fear it was in that misconfigured state long enough for it to create issues.

    All I have really changed now is to update the SPF record slightly and add a DMARC record. I have also changed the UTM SMTP hostname (Email Protection > SMTP > Advanced > Advanced Settings > SMPT Hostname) to be the ISP configured RDNS. Although I do not really like doing this, but it does resolve the SMTP Banner not matching error.

    When I test any of my domains now on MXToolbox I do not see any errors. There are a couple of warnings, like the the SMTP server may be an open relay, but I know that is just because of how the UTM works, not that it is an open relay.

    I will leave things as they are now for a while and see if there is any reduction in my messages being seen as SPAM.

    Thanks to everyone that has offered suggestions on this subject.

  • In reply to BigO:

    I don't think the problem had anything to do with your SMTP banner.  It sounds like your authoritative public name server is managed by your ISP so they have now configured valid FCrDNS, so I don't think that was the issue either.  Big services like Gmail also have their own "suspicious-senders" lists, and it sounds like the ISP's initial mistake might've gotten you onto some of them.

    Assuming that you followed The Zeroeth Rule in Rulz, I think you could change 'SMTP Hostname' to a blank with no effect on your emails being blocked as spam unless your emails already get high-enough spam scores that this pushes them over the limit.  As Doug commented, getting the headers of emails rejected as spam would be valuable.  You might even want to get a look at spam scores on similar emails that aren't rejected.  It would be interesting to learn your results.

    Cheers - Bob

  • In reply to BAlfson:

    Thanks for your input Bob.

    I too think that the screw up with my ISP not initially configuring the RDNS definitely did not help. It was a few months before I was alerted to this issue, by which time I could have been added to some spammer lists. Grrrrrrrrrrrrrrr!

    How I have things configured now looks to be okay, so I am leaving it that way for a while and will see how things go.