E-mail lifecycle after it's been sent

I was testing my mail server's STARTTLS configuration when I stumbled onto this page : https://starttls.info/about. The following excerpt puzzles me:

When you send an email through your outgoing mail server, that email will potentially do multiple hops between different mail servers before reaching its destination. All of these intermediate servers will have to have strong STARTTLS support, in order for your message to not be exposed at one or more stages of its journey.

It was my understanding that the process of sending an e-mail was the following:

  1. The mail server performs a DNS lookup to get the recipient's domain name's MX.
  2. The mail server initiates a connection to the obtained IP on port 25 (SMTP).
  3. If both servers support opportunistic encryption, a secure connection is established.
  4. The e-mail is delivered to the recipient (EHLO, MAIL FROM:, RCPT TO:, DATA, .)

Now where in all this is there an opportunity for the e-mail to bounce around multiple servers?


Mail regularly gets bounced around between servers. For example, if I send an email to a friend it might:

  • Go from my computer to my own mail server (hopefully encrypted)
  • My mail server sends it to it's smarthost, since it's configured not to send mail directly
  • The smarthost sends it to the MX record of the destintion domain, which happens to be a hosted spam filter
  • The spam filter tries to send it to the target's real mail server, but it's unreachable, so it uses the secondary MX, a hosted system that stores its email in case the real mail server is down.
  • Real mail server comes back up, the secondary MX sends the email to the target mail server.
  • My friends downloads his email from his mail server.

That's a fairly common configuration, and causes the email to bounce around 6 times. It eventually gets where it's going, but unless all those servers use STARTTLS or other encryption, at some points it will be unencrypted. Even with transport encryption, the admin of any of those servers could still read the email. It's stored unencrypted on their hard drives while it waits to be sent to the next stage.

There could easily be even more if my friend had his email set to forward somewhere else, which is common if your web hosting provider also does your email, and you forward it to your gmail account.

If you are concerned about people reading your email, the best thing to do is encrypt the message using something like GPG, not to rely on transport encryption. Of course, this requires that the person receiving the email also care enough to setup GPG and exchange keys.


Try that: The server you send is not the one that it finishes. it is MY gateway server for incoming emails that is doing some nice anti spam stuff then forwarding it to the real server.

Gets even better. THe sending email server you use is not the one your company uses facing the internet. It does NOT do a DNS lookup but forwards all emails to a gateway server that THEN sends them to the final recipient. This is not a rare setup in larger organizations.

I maintaina system like that in which multiple network share a common gateway server for incoming and outgoing emails. Incoming emails are forwarded to one of multiple servers, depending on client.

On the incoming site it may also be that the real email server is down. MX can hanve backup entries - and in mose cases these will just buffer the email and then forward it again once the real server is available again.


How you outlined it is pretty much how it works across the board.

There are still intermediate mail servers, but generally they are the public facing servers that your source server connects to. That server may relay the message to an internal server based on any number of rules, such as username, time, load, content(spam), etc.

I would hope that these organizations or third party providers support the same features throughout. Your mail should not transit through a mail server that is unknown to the source or destination, as all intermediaries should be owned or managed by a trusted party.