What your e-mail client reports as the source (From:) and destiantion (To: or Cc:) of an e-mail message has nothing to do with how the message is delivered. All of the header lines you typically see in an e-mail message are actually part of the message’s content, and have nothing to do with how the e-mail servers actually deliver the message to you.
The e-mail protocol (RFC 788 and its many successor standards) works along these lines (some steps omitted or may be different from what modern mail clients do, in order to make the basic concepts clearer):
-
The sender’s computer connects to an e-mail server. Typically, this will be the sender’s ISP’s mail server, but it could be any e-mail server on the Internet that is configured to accept the connection.
In the past, most e-mail servers would accept connections from anyone, but today, most servers are configured to only accept connections from trusted servers, so you typically have to send via the server(s) provided by your e-mail service provider. But there are some servers on the Internet that have weak or no security, and they are often used by scammers to try and hide where they are really sending from.
-
The sender sends a
HELOcommand to the server, identifying the sender’s computer. The ID could be anything, but a modern server will attempt to verify the ID and will log any discrepancies by adding new header lines to the mail message (see below). -
The sender sends a
MAIL FROM:command, identifying the sender’s e-mail address. If this isn’t provided, most mail servers will attempt to guess it by reading header lines in the mail message’s content. This address is often referred to as the “envelope sender”, because it’s not part of the message, but is part of the protocol that wraps around the message (it’s “envelope”) -
The sender sends a
RCPT TO:command, identifying the recipient of the mail message. This address is often referred to the “envelope recipient”. If the mail is supposed to be sent to multiple recipients, the sender will include aRCPT TO:command for every recipient. -
The sender sends a
DATAcommand, followed by the entire content of the message. (Followed by a “.” on a line by itself, indicating the end of the data). This includes all of the message’s headers, its body and attachments (which are actually part of the message body).After this command completes successfully, the server begins the process of trying to deliver the message to its recipient.
-
The sender sends a
QUITcommand, which tells the server that the session is done. It will disconnect the client.
Now that you’ve got that information, here’s the critical bit that you may not have known:
The sender and recipient specified in the MAIL FROM: and RCPT TO: commands do not have to match the To: and From: headers in the message’s content.
The message will be delivered to the address(es) specified in the RCPT TO: command, without regard to the content of the message headers.
This is not a bad thing. This is how your mail client’s Bcc feature works (where you specify a recipient who doesn’t appear in the header). It’s also how mailing lists work - the message header says it was sent to the list, but it gets delivered to the list’s subscribers (who are all named in the RCPT TO: commands when the message is sent).
What’s happening is that the sender has specified your address in the message’s RCPT TO: command, and that’s how the message is delivered to you. But your e-mail client is showing the contents of the To: header in the message’s content, which doesn’t have to match it.
You can actually see evidence of this.
If you view the full set of message headers for the e-mail (the mechanism will depend on what e-mail client you’re using), you will see a lot of e-mail headers. The most interesting ones here are the ones called Received:.
Every e-mail server prepends a Received: header to every message it receives. At minimum, this will identify the mail server and have a timestamp. So by looking at all of the Received: headers, you can see every server the message passes through (the most recent ones at the top of the message).
Many servers will put additional information in the Received: header, containing data from the message’s envelope, including, possibly, the content of the MAIL FROM: and RCPT TO: commands, if they differ from the corresponding headers in the mail message, and maybe also the SSH/TLS parameters used to establish the connection between servers.
Servers may also prepend additional header lines containing other information (e.g. the results of whatever spam filtering software they’re running). If they do, the Received: header is always the last one prepended, so you know that all header lines between two Received: headers were inserted by the server that inserted the first of them.
The last Received: header in the message was added by the first server to receive the message. Some number of header lines below that were probably inserted by that server, with all the header lines below that coming from the actual sender - any and all of which may be completely bogus.
I wrote a long message here in January where I decode and explain the headers of an e-mail message I received. I recommend you look it over, since it will help you understand the headers in the mail you receive: