Undisclosed Recipients

To: Undisclosed recipients:;

Very occasionally you’ll see something in the To: header of an email that isn’t the email addresses you expect, instead it’s the string Undisclosed recipients:;. What does that mean?

When sending a mass mail to a list of recipients using a normal mail client you don’t want to include all the recipients in the To: or Cc: fields, both because it leaks the addresses of all the recipients and because of the risk of reply allpocalypse. That’s when a recipient does a reply-all in response to the mail, typically asking to be removed, to all the recpients, and people respond to that and millions of emails later everyone’s mailbox is unusable.

a Cisco employee sent an email to a “sep_training1” mailing list containing 23,570 members requesting that an online training be performed. The resulting storm of more than four million reply emails, many of which were requests to unsubscribe and facepalm images, generated over 375 GB of network traffic and an estimated $600,000 of lost productivity. The following month, a nearly identical email storm occurred when an employee sent a message to a Cisco group containing 34,562 members. The thread was flooded with “remove me from the list”, “me too”, “please don’t reply-all”, and even a pizza recipe.

That’s just one example from Wikipedia’s Email Storm page, not even one of the bigger ones.

So long-standing advice is to put all the recipients of a bulk mail into the Bcc: field of the email. That way none of the email addresses will appear in the email, folks won’t be able to reply-all, there’s no leak of addresses and it’s all good.

Except… that means there’ll be no email addresses in the To: (or Cc:) headers at all. And that’s not only syntactically incorrect, it’ll even cause some mail clients to misbehave. To avoid that a mail system needs to put something in the To: header, something that’s syntactically valid but not an email address.

There’s an obsolete feature, named lists of recipients, that looks like this:

listname:first@example.com,second@example.org;

You don’t even need to include the recipient email addresses in this syntax, with the assumption being that the mail will have been sent to everyone on the distribution list “listname”.

So Undisclosed recipients:; is just a distribution list called “Undisclosed recipients”. It being used in this way is syntactically valid, and hints to recipients that the mail was sent to people via Bcc. There’s nothing special about the name, it’s just what an early mail system put into the To: field by default if the only recipients were Bcc-ed.

Should you use this in 2025? You can, and despite it being an obsolete feature it will still work. A better option for internal email in a corporate environment is to use a real mailing list manager, or at least an internal mail exploder.

For commercial mail, either B2B or B2C, should always be using an ESP or mailing list manager that sends one mail to each recipient with their email address in the To: header.

And if you’re just sending an ad-hoc mail to a few dozen people via Bcc? Put your own email address in the To: field.

Related Posts

Friendly email addresses

Most of the time when we’re talking about email addresses, we’re talking about the actual user@domain format that’s used to send mail over the wire, but that’s not how we most often see them. When they’re used in a To: or From: header they’re usually associated with a display name – the “real name” of the user with the associated email address. In the From: field that’s often called the “friendly from”, but the syntax used in the To:, Cc: and Bcc: fields is identical.
The display name is important, as it’s shown more in mail clients than the actual email address is. Some mobile clients don’t display the email address at all, just the display name.
There are three ways you can put an email address in a header field.
The best way is to wrap the email address itself in angle brackets, and put the display name in front of it.

Read More

Don’t break the (RFC) rules

It looks like Microsoft are getting pickier about email address syntax, rejecting mail that uses illegal address formats. That might be what’s causing that “550 5.6.0 CAT.InvalidContent.Exception: DataSourceOperationException, proxyAddress: prefix not supported – ; cannot handle content of message” rejection.

Read More

“Friendly From” addresses

When we’re looking at the technical details of email addresses there are two quite different contexts we talk about.

Read More