How do you read successful TLS connection in email headers

More context to get a clearer picture what you have access to and what you are veriying.
Are you handling the mail server and need to confirm that outgoing or incoming messages are exchanged within an encrypted TLS channel?
Or the exchange used STARTTLS, initial connection is plain text, then the encrypted communication channel is setup.

If this is on the incoming, side, you could look at the system you have and the example ste5an provided on whether the mail server you have can be setup to include this parameter if it is not already.

Unless the message is encrypted at the source, the TLS, SSL, STARTTLS are an encryption during interchange.
If this is a means to confirm a secure communication channel, any mail server the message crosses, even if encrypted during the exchange the contents are not secured.

The incoming MTA you're using determines "if this is done" + "how it's done".

As @ste5an mentioned, many MTAs inject this information into a Received: header, clearly showing the TLS protocol level used (TLSv1.2 in ste5an's comment) + also the exact cipher used ( ECDHE-RSA-AES256-GCM-SHA384 in ste5an's comment).

This is the best case scenario.

Other times, you'll have to did through your MTA logs... hoping the data is there...

Tip: If you must have this data, then arrange for the data to be injected into a header (as above) which is the cleanest way for the exact connection data to follow the message through it's entire lifetime.

Side note:  In the case of spam, routing headers can be (and usually are) spoofed in an attempt to hide the origin and routing of the spam.  Treat anything seen in routing headers with a healthy degree of suspicion.

Echo sentiment of Dr.Klahn, but the parameter, headers to indicate whether the connection to their mailserver used encryption.

You can guarantee TLS is used by rejecting everything without STARTTLS / SSL port
You can only control the last leg of a message. If there is a relay that sends a mesasge to you that relay may perfectly accept an unencrypted message transfer.
meaning it wasn't encrypted everywhere.

Now any relay in the stream can still read the message. If you need confidentiality you need end to end encryption.
Either using S/MIME or PGP or some other method of sending encrypted attachment, all with it perks.

thanks everyone