In the general case, it is not possible to do what you are asking for. It is also explicitly discouraged in the standard governing Internet email.
It might be possible in some specific scenarios, but those will be highly specific. (Likely depending on specific software in used, software configuration, etc.)
The reason for this is that the email message (RFC 5822) does not contain all the transport-layer information (with SMTP being RFC 5821). Additionally, including all that information can very easily lead to information disclosure; see also RFC 7258.
The trivial case for illustrating this is if you are sending an email to multiple recipients on the same domain using the Bcc: field; in that case, the message (payload data including headers) as transmitted does not contain the envelope recipient information, and the trace headers do not normally contain the recipient addresses in that case. This means that parsing the recipient address out of the email becomes not just difficult, but outright impossible, since the information isn't even there. Other, perfectly valid, examples can be constructed as an extension to this example.
Quoting RFC 5822 section 7.2:
There is no inherent relationship between either "reverse" (from
MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
transaction ("envelope") and the addresses in the header section.
Receiving systems SHOULD NOT attempt to deduce such relationships and
use them to alter the header section of the message for delivery.
The popular "Apparently-to" header field is a violation of this
principle as well as a common source of unintended information
disclosure and SHOULD NOT be used.
Note the definition of
SHOULD NOT from RFC 2119:
- SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
Quoting RFC 7258 section 2:
To summarise: current capabilities permit some actors to monitor
content and metadata across the Internet at a scale never before
seen. This pervasive monitoring is an attack on Internet privacy.
The IETF will strive to produce specifications that mitigate
pervasive monitoring attacks.