Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What's the best way to check if an SMTP server is SSL-enabled or not?

Follow-up question: How do I make it SSL-enabled if it's not yet SSL-enabled.

The OS is CentOS.

share|improve this question
up vote 11 down vote accepted

That depends whether you mean SSL or TLS.

  • SSL has it's own dedicated port at TCP/465. The best way to test for it's presence would be to use OpenSSL's wonderful s_client which will negotiate the SSL trickery for you.

    openssl s_client -connect localhost:465

    If your server isn't bound to localhost then obviously replace that with the IP or hostname.

  • TLS looks just like normal SMTP at first. The encryption is negotiated from and on-top of the plain-text protocol. You can test whether it is available by issuing an EHLO request to the server. You can use Netcat or Telnet clients for this.

    $ nc -v localhost 25
    localhost [] 25 (smtp) open
    220 ESMTP Exim 4.69 Fri, 11 Sep 2009 09:25:20 +0100
    ehlo test Hello localhost []
    250-SIZE 10485760
    250 HELP

    The important line is second from last which advertises the STARTTLS capability.

In order to say how to enable SSL/TLS for your mail server you'll need to tell us what mail package you're using.

share|improve this answer
You can use openssl for TLS too, if you add -starttls smtp – grawity Sep 11 '09 at 10:19
I didn't know that. Thanks! – Dan Carley Sep 11 '09 at 10:25
I really meant SSL. Thanks! But don't remove the part with TLS; I'd probably refer to this thread again when I'm dealing with TLS already. – Randell Sep 11 '09 at 13:03
This answers mixes up the terminology big time !!. SSL and TLS are simply encryption protocols. When the poster talks about 'TLS' I believe he really means 'STARTTLS'. See my answer below. – unixhacker2010 Sep 13 '13 at 7:02

If you are running CentOS, you are probably using Sendmail. Install the Sendmail-mc package. Inside the /etc/mail/ are some directives for you to look into for TLS:

dnl # Rudimentary information on creating certificates for sendmail TLS:
dnl #     cd /usr/share/ssl/certs; make sendmail.pem
dnl # Complete usage:
dnl #     make -C /usr/share/ssl/certs usage
dnl #
dnl define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
dnl define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl
dnl define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.pem')dnl
dnl define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.pem')dnl

Once you have that working, you can enable Sendmail over SSL with something like so:

DAEMON_OPTIONS(`Addr=, Port=465, Name=SSA, M=Eas')

Oh, and block a bunch of time to play with it before you get it right.

When I've done this, I've almost always had to run three instances of sendmail:

  • one with TLS enabled on port 587 with the various SMTP-AUTH configurations (so authenticated remote users can send arbitrary mail);
  • one with SSL enabled on port 465 with the various SMTP-AUTH configurations (same reason, different clients (thank you Microsoft Outlook "Express"); and
  • one with TLS enabled but no AUTH, locked down so that it only receives mail for valid local recipiants (remote senders can use TLS or not as they like).

Each one had a separate config file. There should be a way to get the first two to run as the same instance listening on both ports, but I could never get it to work right.

If you get big enough, these different instances can get run on different machines.

share|improve this answer

In my mind the answers given on this page are simply wrong.

The reason is that SSL/TLS + SMTP can mean two different things.

One is where you wrap the socket in SSL/TLS. If the server wants to service both unencrypted and encrypted traffic then it needs two ports for this purpose, one for each type of traffic. By convention SMTP servers normally uses port 25 for unencrypted traffic and port 465 for encrypted traffic. By use of external tools such as stunnel this can actually be implemented in such a way so that both the client and the server are unaware that the actual traffic travels on an encrypted socket. So you can implement this approach even if your SMTP server does not support SSL/TLS .. but servers like sendmail and postfix do support this so no need for an external tool.

The other approach is that STARTTLS is used. This is an extension to the SMTP protocol and thus requires both the server and the client to support it. Using STARTTLS the server can serve both encrypted traffic and unencrypted traffic over the same socket, i.e. you can use port 25 for both. You can see if a SMTP server has STARTTLS enabled by connecting to it on port 25 and issuing the EHLO command as Dan explains elsewhere on this page.

Both SSL and TLS are just encryption protocols, TLS being the successor to SSL.

I've got my info from here.

The confusion between the two approaches is accelerated by the terminology used by SMTP servers. Think of Postfix's parameters smtpd_tls_security_level and smtpd_use_tls and their associated documentation. These parameters deal with STARTTLS, not as such with TLS. Other SMTP servers does an equally great job at confusing the terminology.

share|improve this answer

There's a simple tool for this. You send them an email and they reply with a bunch of details:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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