I was recently sent a scam email, and for giggles I opened it up to read it. Very plain, and not much effort thrown in.

I noticed something peculiar; this email was not addressed to me. At first, I suspected a CC, or a BCC, but nowhere does it have my address on the mail. I have provided a picture below. How is this done?

enter image description here

  • 8
    Post the full message headers... also you may have a secondary SMTP address on the email server that this was sent to perhaps. Email server admins should be able to help advise you on this but edit you answer and post the full message header detail of this message too. May 15, 2017 at 18:27
  • 55
    You were probably in the blind carbon copy field of the email.
    – Mokubai
    May 15, 2017 at 18:30
  • 61
    You won't see the BCC list, that's the "B"lind part. ;) May 15, 2017 at 18:41
  • 14
    @tuskiomi No, not in Outlook. Gmail does show bcc: me, perhaps others do as well...But if you look at the full message headers you should see your email there
    – wysiwyg
    May 15, 2017 at 18:49
  • 20
    @tuskiomi - No, you will never see anyone listed in BCC, not even yourself. Moreover, if it's spam, there may not even be a true BCC list; spamware can manage the recipient list any way it wants, and what ultimately matters is what the spamware's dialogue with the mail server looks like - not what the content of the mail is. The only way you'll see your email address is if you look at the internet headers. May 15, 2017 at 18:50

5 Answers 5


An Internet e-mail message consists of two parts. We can refer to them as the envelope and the payload message or simply message.

The envelope has routing data: primarily, this is the sender address and one or more recipient addresses.

The message has the message content: subject line, message body, attachments, and so on. It also carries some technical information such as trace (Received:) headers, DKIM data, and so on; as well as the displayed sender and recipient addresses (what you see in the From, To and Cc fields in your mail client).

Here's the crux of it: The two don't have to agree!

A mail server will look at the envelope data to determine how to send the message. On the other hand, with few exceptions, the message itself will be treated as just data. Particularly, a well-behaved mail server does not look at the To: and Cc: fields of the message itself to determine the list of recipients, nor does it look at the From: field to determine the sender's address.

When you compose and send an e-mail, your e-mail client takes what you entered into the To, Cc and Bcc fields, and translates that into envelope routing information. This is mainly done by removing any full names (leaving only e-mail addresses), but can also involve things like address rewriting, alias expansion, and so on. The result is a list of e-mail addresses which are given to the mail server your mail client is talking to as the list of recipients. The To and Cc lists are kept in the e-mail, but the Bcc is not passed along to the server, making it invisible to message recipients. The sender address works very similarly.

When the message reaches its final destination, the envelope data is either thrown away, or retained in the detailed message headers. That's one part of the reason why Spittin' IT asked for the full message headers in a comment to your question.

Additionally, with Internet e-mail, it is possible to talk directly to a mail server, and thus inject a message that has a mismatch between the envelope data and the message data that a normal, well-behaved e-mail client wouldn't let you compose. Also, mail servers do varying degrees of checks on the sender address that they are given in the envelope data; some barely check it at all beyond making sure it's a syntactically valid e-mail address. The From header of the message data is subjected to even less scrutiny.

Since the receiving e-mail client displays what's in the From, To and Cc headers, not the address data from the envelope, it's possible to put anything you want there and the receiving e-mail client will have no recourse but to trust that it is reasonably accurate. For legitimate mail it usually is accurate enough; for spam, it almost never is.

In the world of tangible, physical objects inhabited by us mere humans, the envelope sender and envelope recipient corresponds to the return address and recipient address, respectively, that you write on the outside of the envelope; and the From: and To:/Cc: headers correspond to whatever you put as your and the recipient's addresses, respectively, in the letter which you put in the envelope.

  • 8
    I wish people made more real-world analogies here so others would understand what the physical equivalent is. The "sender" of an email is like the person handing the mailman the envelope; the "from" address is the one it's intended to be from. Like you could be a secretary sending on someone else's behalf, etc.
    – user541686
    May 15, 2017 at 20:33
  • 21
    @Mehrdad No; the (SMTP) envelope sender address is like the return address on the outside of the envelope (where it gets sent if it can't be delivered), whereas the address in the From header is whatever you write on the piece of paper that you stick inside the envelope and that the mailman doesn't even know about.
    – user
    May 15, 2017 at 20:37
  • I was thinking of the Sender: header when I wrote that, and it was just an example. Just saying it'd be nice to add an example like this to your answer.
    – user541686
    May 15, 2017 at 20:44
  • 91
    The amount of bolding here is really unnecessary at best. And that is only my opinion. May 16, 2017 at 0:35
  • 3
    @SupremeGrandRuler Because the recipient information (in contrast to a possible Sender or Return-Path) is not contained in the email. Imagine the full recipient list was included, including the addresses the MUA got from the Bcc field (remember: SMTP (the envelope protocol) does not know about Bcc, it only knows about recipients) … That’d be a privacy issue (and a huge waste of space) not only on large mailing lists (operating by the same principle as Bcc does). May 16, 2017 at 5:20

tl;dr at bottom.

The SMTP protocol doesn't have the notion of CC or BCC recipients; this is a convention held by mail clients. The SMTP server only typically cares about routing information and data. This is an important distinction, because without this capability, BCC could not exist. As a legitimate BCC communication consider the following client transcript:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.


Now, in this case, Anonymous was sent a message about this meeting. However, this version of the mail was not routed to Jane Doe; she knows nothing about Anonymous being notified. In contrast, Jane Doe will be sent the message with a different body and header:

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.


Here, since Anonymous was in the BCC, the message sent to Jane Doe did not include the BCC recipient list. Because of the BCC convention, the email envelope may not include recipients that actually received the message, and it may also include recipients that do not appear in the message headers.

As mentioned by @JonasWielicki, which I also meant to include, is that the MUA (Mail User Agent) is typically responsible for sending the multiple emails that are required to implement BCC. Email servers do not know anything about BCC, and so the MUA must implement BCC by sending multiple emails with different email routes specified in the envelope headers. For this reason, BCCs typically take longer to send than normal emails, because different message bodies must be constructed and sent out individually.

This also helps with some email compliance rules. For example, a mail server may have rules configured to automatically BCC an archive email server (all emails sent to it are also archived), in which case the mail server might not even be a real recipient.

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.


Here, the recipient is another party that is completely undisclosed to any of the recipients or even the sender. This is a feature of the protocol, typically used in relaying or archiving messages.

What this spam message did is take advantage of that behavior. It's a standard loophole that technically should work with any compliant mail server. Of course, many updated servers use "extensions" like DKIM to verify that such an email is authentic, but there are still many old mail servers out there that don't care, simply because it's tempting to not fix things that are not broken.

Also note how I've specified a Date header. This can be any arbitrary (but well-formatted) value; many clients will happily display any legal date range from the distant past to the far future. I have personally sent an email to myself years ago that will remain at the top of my mail box long after my life expectancy, as well as an email that predates my email account and my own birth.


So, in summary, the sender spoofed an email, the originating mail server accepted/relayed it, your email server accepted it and stored it in your inbox, and your client faithfully displayed the data that was in your inbox to you, all without circumventing any security. "Sending" security is often much less restricted than "receiving" security in that perspective, since POP3 almost always requires a username and password before you can access a mail box (you could theoretically circumvent this, but I don't know of any legitimate mail services that do).

  • 3
    You should note that stripping of Bcc is typically not handled by mail servers (the SMTP transcript you provided suggests otherwise, because the HELO sounds like a mail server and not a MUA). To provide a copy with Bcc header to the person addressed in that header requires extra work by the MUA by sending two separate emails. May 16, 2017 at 5:24
  • @JonasWielicki That's a good point. I've added an edit to that effect.
    – phyrfox
    May 16, 2017 at 5:44
  • 5
    If you add a bcc line to a delivered mail it is not blind anymore :)
    – eckes
    May 16, 2017 at 21:45
  • 1
    Actually requiring the client to send multiple messages in the case of BCC is incorrect. It is perfectly sound to send just a single message. The SMTP client can list multiple RCPT TO instructions. The only requirement is that the receiving SMTP server either be the authoritative server for both recipients, or be willing to relay for any that it is not.
    – phemmer
    May 20, 2017 at 2:09

SMTP and email are very old Internet services from an era when security and authentication were taken much less seriously (DNS is another example). The design of the protocol makes no effort to verify the authenticity of the sender address, and only validates the recipient address insofar as it is ensuring that the mail is deliverable.

Email is transmitted through the SMTP protocol. The SMTP protocol is relatively dumb; it provides a facility to transmit plaintext to an email address and very little more. The structure of this plaintext is defined by RFC 5322. The general idea is that the email text has metadata called a header, and the actual text body of the message. This email header is generated by the sender (none of it can be trusted) and contains fields like "to:", "from:", "subject:", etc...

The SMTP protocol does not (and is not supposed to) validate that the email headers match any of very few things defined in the SMTP protocol, which are essentially your email address and a sender email address that is never validated in any way.

Almost everything in an email message can be fake.

The only thing even remotely trustworthy about email contents today are DKIM signatures, which prove that the email was processed through an email server sanctioned by the domain registrant. Digging deeper, you would find that this scam email has no DKIM signature.

  • I'd add the final Received: header added by your own system to the trustworthy parts. May 18, 2017 at 20:18

Address To in email header is for information purposes and it is shown by the email client. The real recipient address is given with RCPT TO in SMTP. It is the same if you write letter, put in envelope, write Address-1 on envelope. Then go to courier, give another Address-2. The courier puts your envelope in bigger envelope with Address-2 and the shipment will go there. Your secretary (email client software) puts the external envelope to trash and show you the internal envelope with Address-1. You can see this with RAW view of email message.


This is a slightly different look, based on examining headers. The other answers handle the details of SMTP better than I could.

If you can get the full headers of your message, then search them for your address, you may find it in a field called Envelope-to, Delivered-to or X-Apparently-to. The first is used by my mail provider, the second by Gmail; I've seen the third used as well. These are different fields but for our purposes tend to mean the same thing: the mailbox to actually deliver the message into. I tested by sending from outlook (desktop version) with the recipient BCCed.

My mail provider also uses the Delivered-To field but for the mailbox name on their server. This isn't my email address though it looks like one (think ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

Outlook (combined with exchange server) on the other hand doesn't include in the headers a single field with the recipient's email address if you're listed as BCC.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.