TLS on Professional Email / Workspace Email (not Office 365)
"Implicit TLS for SMTP Submission" (as recommended in RFC 8314) is implemented on the smtpout.secureserver.net servers, and mail clients such as Microsoft Outlook can successfully use TLS over port 465. Meaning as soon as the TCP-level port 465 connection is established, the server waits for the client to issue a TLS Client Hello to secure the connection before sending any data.
"Explicit TLS for SMTP Submission" (described in RFC 6409) is apparently not implemented by the smtpout.secureserver.net servers. Meaning the mail client creates a TCP-level port 587 connection and communicates unencrypted, determining whether TLS is even supported, before then issuing a STARTTLS command to the SMTP server to begin the TLS Client Hello negotiation.
I have a third-party application (Acronis True Image 2018) which cannot send email notifications via smtpout.secureserver.net, because they (the application) only supports "Explicit TLS for SMTP Submission". If I point that application to smtpout.secureserver.net port 465, the application waits for an SMTP server welcome message that never comes, and the SMTP server is waiting for the application to send a TLS Client Hello which never comes.
I can point the application to one of the clear-text ports smtpout.secureserver.net currently supports, such as port 3535, and the application successfully makes it all the way to the point of issuing the STARTTLS command over the SMTP connection. But the server responds with 500 unrecognized command, so secure negotiation is apparently not allowed, even if it would have otherwise worked.
Is there any way to get explicit TLS for SMTP over port 587 enabled for Professional Email / Workspace Email? In the alternative, is there a port other than 587 over which the STARTTLS command would be accepted? (As opposed to the implicit TLS expected by port 465, which must establish a secure connection before you can ever get to the point of issuing a command.)
Acronis True Image 2018 appears to have run into this issue as a result of a recent change where GoDaddy disabled / no longer accepts SSL negotiation. Which is fine, and what we want; but I think GoDaddy customers are going to need a way to support STARTTLS / Explicit TLS in addition to the Implicit TLS support which is currently working.