You can't do what you're asking. The only thing you can reliably verify with any real value from a security standpoint is encryption of the message itself (S/MIME, PGP, or similar).
The Long Version
From your comment
TLS secured on transport on the open internet is sufficient for the business (and many large peer businesses)
This sounds like your business (and its "many large peer businesses") don't understand what "TLS secured on transport on the open internet" means in terms of security for email.
Email (SMTP) is NOT a point-to-point connection. It is a relay race.
The security analogy is this:
- SMTP + TLS puts your message in a blank envelope and hands it to a stranger on the street.
- That person opens the envelope and reads the message to see who it's addressed to.
- If the message is for them, they keep it.
- If the message is for someone else, they put it in a new blank envelope and hands it to another stranger on the street.
It's at the second point under (2) where things go all pear-shaped as the message can be intercepted (copied or modified) with impunity - TLS is protecting the channel (so other people on the street can't see your letter when it's being handed off) but not the content, which the intermediate servers are going to need to decrypt in order to see who the message is addressed to.
Bluntly there's no way for you to verify SMTP TLS in messages sent over the public internet. You can consult the header data, but the header data is just a post-it note stuck on your letter by each stranger who touches it -- the headers can be a pack of lies.
You can verify that the last server that handled your message (the one talking to you) used TLS when they talked to you because you know the details of that connection, but that's all you can verify and that doesn't protect the rest of the chain (or the content of the message as noted above).
At least in my field (Medical) TLS in the message chain is completely inadequate as authentication/signature or encryption/confidentiality technology -- It's useful for its own purposes, but not reliable enough to hang your hat on in an audit.
There is some value in verifying that the reading connection (POP, IMAP, RPC/HTTP (Outlook), Webmail) is secured with SSL/TLS, but again this doesn't protect the message itself (nor does it ensure the SMTP half of the email process had any security whatsoever) -- it just keeps prying eyes from reading over your users' virtual shoulders when they're downloading their mail and protects their password (which is pretty important).