WHM: How to solve SMTP lacking PTR record or record not same as SMTP Banner and also SMTP doesn't support TLS

[martin MHC]

I have over the years had persistent issues with TLS and, separately, rDNS PTR records. With some work some years ago (pre-covid!) this was resolved and everything was hunky dory.

Now, for some reason, the issue has returned according to mxtoolbox.com which states that for every domain on one of our servers:

	smtp	domain.name	Reverse DNS does not match SMTP Banner
	smtp	domain.name	Warning - Does not support TLS.

1) PTR

Now, I have read a lot of conflicting reports from different sources about how to set up correct PTR records and even some example guides are fundamentally incorrect.
Yes we absolutely do have delegation authority on this server IP address.

The PTR record on the "Email Deliverability" has been set correctly on WHM .

The PTR record for the specific domain(s) looks like this (where server IP address is exampled as 44.33.17.25 ):

25.17.33.in-addr.arpa. 14400 IN PTR domain.name.

IS THIS CORRECT?

2) PTR Server side Setup

The server wide Email Deliverability PTR record (a WHM feature addition in a recent-ish update) claims to be set correctly.

However, the WHM guide here: How to Configure Reverse DNS in WHM | cPanel & WHM Documentation states to test the record with:

host 192.168.0.1

but that returns the value:

Host 1.0.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

I am unable to update the PTR record in Email deliverability. How can I fix this apparent "not found: 3" issue?

3) SMTP Banner

Our current SMTP banner as set by Exim Manager is:

"${smtp_active_hostname} ESMTP Exim ${version_number} \#${compile_number} ${tod_full} \nWe do not authorize the use of this system to transport unsolicited, \nand/or bulk e-mail."

This has previously been absolutely fine.

4) SMTP TLS

MXToolbox persistently claims that TLS is disabled on our SMTP ; but this isn't so as far as I'm aware, TLS is handled by CPanel / Sectigo AutoSSL and is working perfectly as far as I can tell. How can I clarify this on the server and how can I fix it so the server shows this correctly to mxtoolbox?

 

[martin MHC]

All of the above issues seem to be magically resolved by turning off Exim ACL delay --

ACL Options​
Introduce a delay into the SMTP transaction for unknown hosts and messages detected as spam.

I'm unclear why the PTR records or TLS status should be changed by removing the transaction delay, but yeah...

 

[rbairwell]

1) PTR

The PTR record for the specific domain(s) looks like this (where server IP address is exampled as 44.33.17.25 ):

25.17.33.in-addr.arpa. 14400 IN PTR domain.name.


IS THIS CORRECT?

Setting up the PTR (also known as the reverse record/reverse IP address/reverse DNS/rDNS) isn't something smallish webhosts running servers are able to do - this needs to be done at the "netblock owner" level (i.e. your hosting company usually has the ability to do this - sometimes they do have a control panel which allows this [sometimes you have to raise a ticket] - but it is highly unlikely you can correctly set the PTR on your server/DNS records.

Plus the entry shown above is incomplete.

If you run from a command line on your PC:
host 44.33.175.25
do you get something like:
Host 25.175.33.44.in-addr.arpa. not found: 3(NXDOMAIN)
or:
25.175.33.44.in-addr.arpa. domain name pointer server.example.com

If you get the not found message, then the reverse entry is NOT setup correctly. Your server provider/data centre should be able to do this.

PTR records are checked as "ownership/authorisation" during email acceptance by remote servers - if your server says "Hi, I'm server.example.com and I'm from IP 10.29.32.123" the receiving server will go "Are you? Let me just see what 10.29.32.123 resolves to...." if it doesn't match server.example.com then it'll be spam flagged or blocked.

This covers "2) PTR Server side Setup" as well.

3) SMTP Banner

What is the problem with the SMTP banner?

4) SMTP TLS

You might find Secure Email a better tool for checking than MXToolbox : if you use //email/testFrom: and send it an email, it should help diagnose your outbound problems - selecting all the "Select Extra items to show" will also help diagnose.

SMTP TLS is controlled by WHM and should be setup when your server acquires a server SSL certificate: if you are able to login to WHM without certificate warnings, then Exim should be okay.

Are you sure MXToobox isn't mentioning "SMTP TLS Reporting" (aka TLS-RPT) which is a slightly different kettle of fish and, tbh, isn't really worth worrying about at the moment as very few services seem to bother reporting.

All of the above issues seem to be magically resolved by turning off Exim ACL delay --

Are you having problems with INBOUND mail (i.e. mail sent to your server) or OUTBOUND (your server sending elsewhere). Everything else mentioned relates to outbound email - but Exim ACL delay relates to INBOUND mail...

 

[martin MHC]

Are you having problems with INBOUND mail (i.e. mail sent to your server) or OUTBOUND (your server sending elsewhere). Everything else mentioned relates to outbound email - but Exim ACL delay relates to INBOUND mail...

The issue is caused by MXToolbox contacting our server and our server percieving MXToolbox as non-genuine / spam so adding a delay (~14 seconds) and causing the above issues. I know Exim is inbound but that's the point -- Exim works on the request call from MXTB and possibly rejects the incoming request which then leads MXTB to give the above results.

 

[rbairwell]

Yep, that makes sense. I was under the impression when you said " All of the above issues seem to be magically resolved by turning off Exim ACL delay" that it actually related to reportable issues rather than just a report from MXToolbox