7 Best Practices for SMTP/TLS

securemailI was working with a customer the other day who was having some problems with TLS sessions between their Exchange servers and a partner’s. They asked me to help do some troubleshooting. I was home at the time, but since this is Internet edge servers we’re talking about here, I thought I could take a look at a few things remotely, since I too am “on the Internet.” Since the complaint was that they could not establish a TLS session between systems, which is something that was working previously, the first think I asked was, of course, “what changed?” I bet you know what the answer was! So, the next thing I did was try to establish a TLS session myself. I dropped to the command prompt, and entered

telnet customersmailserver.example.com 25 [enter]
220 customermailserver.example.com ESMTP MAIL Service ready 
at Wed, 6 Mar 2013 21:12:21 +0000
help [enter]
214-This server supports the following commands:

Hmm, something seems missing there. STARTTLS! According to that response, the server does not support TLS, so I called my customer back and told him “it looks like someone turned off TLS on your server.” He asked why I thought that, so I described what I had done, feeling quite clever really, to have him say something along the lines of “oh, yeah, that wouldn’t work for you. We only allow TLS from certain IP addresses.” To which I replied <blink…blink…> “uhm, why?” I won’t bore you with the details of his response. Trust me when I say it had something to do with a complete misunderstanding of what SMTP/TLS is about, and a false belief that it is risky to use it with just anyone. BZZZZZZ! Wrong answer. So here are some best practices regarding SMTP/TLS that you should implement with your email systems.

1. Obtain your certificates from a public CA.

Exchange 2010 does not require this, and by default will not perform certificate validation, but not everyone uses Exchange. By using certificates from a public CA, you provide more assurance to your partners that your MTA is really yours.

2. Use stronger keys-2048 is a good choice.

Anyone still using keys less than 1024 bits is doing it wrong.

3. Use UCC certificates with a CN and SAN that matches what DNS resolves to any of your MTAs, and configure your MTAs to respond with that FQDN in their 220.

For those systems that do want to validate the certificate, and also that it matches the hostname they are trying to reach, having the DNS name of your MTA in the CN and SAN, and making sure your MTA uses that name in the 220 response, will help partners validate that your server is yours, and ensure even the most tightly configured server can correctly connect to yours.

4. Enable opportunistic TLS for everyone.

There is no reason at all not to use TLS whenever possible. If your server is really so old that you don’t have the CPU cycles to support it, you’ve got more things to worry about than securing email.

5. Enforce TLS for partners when compliance needs require it.

If you are using TLS to meet any compliance requirements for encrypting email, make sure you require TLS for the partner domain, and that the partner’s MTAs all support TLS. Your server cannot verify end to end encryption…only to the next hop, so if there is more of an SMTP path than you can see, you cannot be sure you have end to end encryption.

6. Monitor your server to ensure that TLS is being used as you expect.

Once you enable TLS, make sure your communications are using it by making regular reviews of your logs.

7. Set reminders for certificate renewals so mail flow doesn’t break when a cert expires.

And here we come to the part that would have fixed my customer’s issue above. Certificates expire. You have to renew them before they do, or they stop being useful for most situations. If nothing else, set a reminder in Outlook, or send an invite to everyone on your team for a week before the certificate expires, so that someone will know ahead of time and can renew the certificate before it expires. By the way, when you need to test TLS on your email server, and you want to do a little more than just what you can with TELNET and you don’t have another email server handy, there is a great website that can test your TLS and more. Here’s the link. http://www.checktls.com/perl/TestReceiver.pl

Written by Casper Manes

I currently work as a Senior Messaging Consultant for one of the premier consulting firms in the world, I cut my teeth on Exchange 5.0, and have worked with every version of Microsoft’s awesome email package since then, as well as MHS, Sendmail, and MailEnable systems. I've written dozens of articles on behalf of my past employers, their partners, and others, and I finally decided to embrace blogging and social media, so please follow me on Twitter @caspermanes if you enjoy my posts.


  1. Tim the IT Guy · April 3, 2013

    Just how strong is the 2048 key? Well, according to most IT security experts, it will take an average desktop computer approximately 6.4 quadrillion years to break a 2048 SSL certificate. That’s how strong it is! Try hacking that. Even the most sophisticated brute force attack will not have a chance.

    Using a much stronger key is not only a good choice. It’s a must especially to businesses that handles a lot of server data maintenance and management. At today’s age of superior computing power, even a kid can hack an email just by Googling some commands and watching step-by-step YouTube video tutorials. We are less secure now and the 2048 key is one tool we can depend on.

  2. Rob · May 2, 2013

    Email systems are always vulnerable. So it is just right that we never slack off in finding ways to protect and improve them. All the 7 in this list share the same weight value, but I agree with Tim the IT Guy; using 2048 is the best option for businesses dealing with a lot of server data. There’s just too many ways one can easily hack into an email system nowadays. And, yes, one can learn how to do so just by looking at YouTube videos. So we must be employ tougher ways to fend off hacker of all types.

Leave A Reply