Back to Community Threads
SMTP Blocks on Reverse DNS name
Idea shared by Douglas Foster - 4/16/2026 at 10:35 AM
Planned
D
I would like to block be able to configure SMTP blocks based on ReverseDNS name.
In some cases, the ReverseDNS name is very stable, because it represents the hosting service, while the HELO name is unstable, because it is manipulated by the client.
Currently, SmarterMail only allows blocks based on HELO.
Derek Curtis Replied
4/16/2026 at 10:44 AM
Employee Post
Hey, Douglas

I asked about this, and it's definitely doable. I changed this over to an Idea, so I'll add a feature request for it. Appreciate the suggestion!
Derek Curtis
CCO
SmarterTools Inc.
J
Since we're on the topic of feature requests and the SMTP Blocking feature - bumping this yet again, since it can't even seem to get any visibility let alone the first response:


Additionally, it would be nice to have detection where when an EHLO submitted is ONLY an IP address that we can test that "submitted IP in EHLO" against the IP address actually connecting as...  Having this as an option would block several hundred SPAM attempts a day at the connection level... The most effective option would include a switch to "bypass on authenticated connections" - in other words, SMTP user authenticates to send mail, this check doesn't apply - but if it's just an inbound unauthenticated connection, it should be available as an option for blocking...
MailEnable survivor / convert --
D
Yes.  Also the ability to filter on HELO/EHLO keyword, since J LaDow has documented the benefits of blocking HELO keywords.
@J. LaDow, a mail client connecting will EHLO with a local IP address, so you might want to ignore those mismatches.

On the subject of EHLO IP addresses only, I find a surprising number of attacking IP addresses are also used as EHLO addresses for other attacking bot's IP addresses. 

Like so:
Search "182.95.14." (21 hits in 2 files of 8 searched)
  D:\SmarterMail\Logs\2026.04.20-smtpLog.log (19 hits)
    Line  86: 01:42:09.148 [182.95.14.14][2845520] Connection initiated
(snip)
    Line  90: 01:42:10.555 [182.95.14.14][2845520] cmd: EHLO [149.54.62.170]
(snip)
    Line  98: 01:42:19.133 [182.95.14.14][2845520] Authenticating as postmaster
    Line  99: 01:42:19.133 [182.95.14.14][2845520] rsp: 334 UGFzc3dvcmQ6
    Line 100: 01:42:20.403 [182.95.14.14][2845520] Authentication failed - login failed LOGIN_FAILURE_DOMAIN_NOT_FOUND
    Line 101: 01:42:20.404 [182.95.14.14][2845520] rsp: 535 Authentication failed
    Line 102: 01:42:21.872 [182.95.14.14][2845520] disconnected at 4/20/2026 1:42:21 AM
  D:\SmarterMail\Logs\2026.04.19-smtpLog.log (2 hits)
    Line 1127: 13:45:00.704 [152.52.245.142][12212237] cmd: EHLO [182.95.14.14]
    Line 1131: 13:45:05.669 [152.52.245.142][12212237] cmd: EHLO [182.95.14.14]
J
In our research, it's HELO that is suspect greeting, not EHLO.  You'll find that HELO greetings from outside servers are almost always garbage, while EHLO is the most common greeting and not something to filter against on it's own. Only if the appended string to EHLO is from a known bad host like *.enduserdrm.info -- 

So watching our logs for EHLO smtp43.enduserdrm.info and blocking the IP instantly since it's malicious and hosting phishing content is what I consider acceptable. 

On your other note - when HELO/EHLO contains an IP address only, very rarely does it match the IP that connected - especially when malicious - and that would be something nice to filter against as an option. This is next to impossible to filter out/block because it requires some deterministic scanning that most plain log scanners can't do on their own.
MailEnable survivor / convert --
I agree with that, but I very rarely see HELO in my logs, 5 in the last 10 days on one server and 222 on the other. Of those that were IP only, the vast majority matched. On the smaller server, there are 1630 EHLOs, of which 76 are EHLO mail1.(my domain).com. Shouldn't THAT be an insta-BAN?
J
On our servers, we do insta-ban remote hosts that try to identify as domains we host in HELO/EHLO -- as they are most likely trying either phishing or relay attacks --

We also insta-ban hosts that try to ID as our own IP(s), hosts that call themselves "localhost", "admin", "localhost.localdomain", "example.(com|net)", *.internal", 10.*.*.*, 172.*.*.*,  and close to a hundred more along those lines...
MailEnable survivor / convert --
Check out and vote for this idea from a couple months ago:

It takes this request one step further and allows you to score ReverseDNS at the SMTP level. So it could be used for blocking, but offers more flexibility as it can combine with other SMTP checks.
I saw this is marked as Planned.  Can we enhance this request and make it even more powerful by integrating it with the SmarterMail spam scoring and SMTP blocking?

See this thread:

Thanks.
Back to Community Threads

Reply to Thread

Enter the verification text
Related Knowledge Base Articles
Recommended SPAM SettingsSmarterMail > Antispam and Antivirus
Cannot Send Email MessagesSmarterMail > Troubleshooting
Resolving SMTP Failures on AWS-based ServerSmarterMail > Server Configuration and Management
SmarterMail for Linux – SSL/TLS & Certificate ReferenceSmarterMail > Server Configuration and Management
Deploying Rspamd For Use With SmarterMailSmarterMail > Server Configuration and Management