What are 'undisclosed recipients' in email and when should they be used?
Published 13 Nov 2025
Updated 9 Aug 2026
11 min read
Summarize with
Updated on 9 Aug 2026: We clarified how undisclosed recipients work, how to send them safely, and when individual delivery is the better choice.
Undisclosed recipients are what people often see when an email has no visible recipient in the To: or Cc: header. In practice, it usually means the sender put the real recipients in Bcc, or the sending system inserted an empty address group such as Undisclosed recipients:;. The recipients are not shown to each other, but the message is not anonymous and mail servers still know where the email is being delivered.
The direct answer on when to use it is simple: use it only for small, ad hoc messages where you need to hide a recipient list and you are sending manually. Do not use it as a normal pattern for transactional email, marketing email, product notifications, legal notices, account alerts, or anything sent through an application or website SMTP connector.
If the real requirement is, "send the same message to multiple people without exposing their email addresses," the better answer is almost always to send one normal message per person. Put that person in the To: header, keep the envelope recipient specific, and let your mail system handle unsubscribes, suppressions, bounce handling, and audit records per recipient.
What undisclosed recipients means
Diagram comparing visible To headers, hidden Bcc recipients, and the SMTP envelope.
Email has visible message headers and a delivery envelope. The visible headers are what a person sees in the mail client: From:, To:, Cc:, subject, date, and similar fields. The envelope is what SMTP uses to route the message to each mailbox. Bcc hides addresses by keeping them out of the visible headers, not by removing them from the delivery process.
Typical undisclosed recipients headertext
From: sender@example.com To: Undisclosed recipients:; Subject: Quarterly update The actual recipients are delivered through SMTP envelope data.
That To: line uses standard address-group syntax with an empty group. The label "Undisclosed recipients" is a long-running convention, not a special SMTP status or delivery mode. Some clients generate a similar display when the To: header is blank and every recipient is in Bcc.
The key distinction
Bcc hides recipients from other recipients. It does not hide the delivery path from the sending provider, receiving provider, logs, compliance systems, or abuse handling systems.
- Privacy: recipients do not see each other's addresses in normal mail clients.
- Routing: mail servers still process each real recipient in the SMTP envelope.
- Identity: the sender identity and authentication results still matter.
What recipients can see
A recipient can see the visible headers that remain in the delivered message. They cannot see the full Bcc list or every SMTP envelope recipient. Depending on how the sending system processes Bcc, the delivered copy can have no Bcc field or a Bcc field containing only that recipient's address. It should never expose the other Bcc recipients.
|
|
|
|---|---|---|
To header | Yes | Displayed recipients |
Cc header | Yes | Displayed copies |
Bcc header | Usually no | Removed or recipient-specific |
SMTP envelope | No | Used for routing |
Reply all | Limited | Uses visible addresses only |
Visibility of recipient-related email data
A Bcc recipient can reply to the sender. Reply all includes only addresses that remain visible in To and Cc, so it does not reveal or contact the other Bcc recipients. This reduces accidental reply-all messages, but it also makes group discussion impractical.
This is also why "undisclosed recipients" does not mean the sender used encryption, anonymous delivery, or a privacy relay. It only says the delivered message did not expose a normal visible recipient list.
It is a narrow mail-client convenience, not a design pattern for systems that send mail on behalf of a business.
When to use undisclosed recipients
The safe use cases are small and human. If a person is sending a one-off email to a small group and the recipients should not see each other's addresses, putting the sender's own address in To and the group in Bcc is acceptable. It solves a basic privacy problem without leaving the visible recipient field empty.
- Small groups: use it for a short, manual note where the sender knows the recipients.
- Recipient privacy: use it when exposing addresses to the group would be inappropriate.
- Low volume: use it only when the message is not part of a repeated bulk workflow.
- Clear context: make the body explain why the recipient is getting the message.
- Manual sending: keep it to a person sending from a mailbox, not an application.
Fit by sending pattern
Use undisclosed recipients only where recipient privacy is the main requirement and the sending pattern is small.
Good fit
Small
Manual one-off notes to a small private group.
Caution
Limited
Occasional announcements where replies and list hygiene are not critical.
Avoid
Scale
Transactional, marketing, product, legal, or high-volume mail.
The moment the message has unsubscribe requirements, consent rules, template variables, bounce processing, per-user audit needs, or user-specific content, undisclosed recipients are the wrong tool. Send separate messages.
How to send to undisclosed recipients
Most mail clients support the same basic method. Use your own valid address in To and place the private recipient list in Bcc. If you want the familiar label, save your own address as a contact named "Undisclosed recipients" or enter it as a display name where the client accepts standard address syntax.
Visible recipient and hidden recipientstext
To: Undisclosed recipients <sender@example.com> Bcc: alice@example.com, bob@example.com
- Start a new message: open the compose window instead of replying to an existing thread.
- Set the visible recipient: put your own address in To, optionally with the display name "Undisclosed recipients."
- Show Bcc: enable the Bcc field and add the people whose addresses must remain private.
- Check the fields: make sure no private address appears in To or Cc.
- Send a test: use two accounts you control and confirm that neither received copy exposes the other Bcc address.
Check the provider's limits
Mailbox providers set their own per-message and daily recipient limits, and those limits change by account type. Do not treat a technical limit as a safe audience size. For a repeated send or a large group, use individual delivery with consent, unsubscribe handling, bounce processing, and suppression controls.
When not to use it
A request to support undisclosed recipients inside a website builder, CMS, CRM, or SMTP plugin is often a sign that the sender is trying to solve recipient privacy with the wrong abstraction. If software is generating the message, it can generate one message per recipient.
Undisclosed recipients
- Headers: one generic visible recipient line for many recipients.
- Tracking: opens, clicks, bounces, and complaints are harder to tie back cleanly.
- Replies: reply behavior depends on visible headers and client quirks.
- Scale: large Bcc lists look like bulk mail handled through a mailbox pattern.
Individual sends
- Headers: each recipient sees a normal message addressed to them.
- Tracking: delivery events and suppressions map to one recipient.
- Replies: reply handling is predictable and easier to route.
- Scale: the pattern works for product, lifecycle, and broadcast systems.
This is the same practical issue behind using only Bcc: the header trick is not the same thing as proper list management. It hides addresses, but it does not create per-recipient control.
Do not build product email this way
For transactional or application-generated mail, a hidden recipient list is a shortcut that creates debugging and compliance problems later.
- Audit: it is harder to prove which user received which message version.
- Suppression: one unsubscribed or bounced address should not affect unclear batches.
- Personalization: per-user fields belong in separate messages with separate events.
Deliverability and authentication impact
Undisclosed recipients do not automatically break SPF, DKIM, or DMARC. SPF checks whether the sending IP is authorized for the envelope sender domain, DKIM validates a cryptographic signature, and DMARC checks whether an authenticated SPF or DKIM domain aligns with the visible From domain. The recipient display line is not a core input for those results.
That said, an empty To: header with a large hidden recipient set is a poor sending pattern. Filters can treat it as one signal among many. The bigger problems are usually weak engagement, missing unsubscribe controls, poor suppression handling, sudden volume, shared mailbox sending, and weak domain reputation.
The undisclosed-recipient label does not bypass consent rules, unsubscribe duties, or provider requirements for bulk senders. Those obligations depend on the message, audience, jurisdiction, and sending volume, not on whether addresses are hidden in Bcc.
Before changing a live flow, send a real sample and inspect the headers with an email tester. Check what the delivered message looks like, whether DKIM signs it, whether SPF passes, and whether DMARC produces the expected result.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For ongoing operations, Suped's product supports a broader domain-authentication workflow. Use the sample test for a single delivered message, then use Suped for DMARC reports, SPF and DKIM checks, and alerts when a sending source starts failing authentication.
Email tester sample report showing total score, email preview, issue summary, and per-section results
If you are not sure whether the issue is a header choice, authentication issue, or wider domain setup problem, run a domain health checker before changing DNS or application code.
How to implement it safely
If you still need undisclosed recipients, make the implementation explicit. Do not rely on whatever a plugin happens to do when the To: field is blank. Decide whether the system is sending a manual privacy note or a real application email.
- Confirm purpose: write down why recipient addresses must be hidden from the group.
- Limit volume: keep the hidden-recipient pattern to small manual sends.
- Set headers: use a clear group line or a normal visible recipient, not a broken blank field.
- Test delivery: send to multiple mailbox providers and inspect the delivered headers.
- Prefer fanout: use one message per recipient whenever software is generating the email.
Better application patterntext
Message 1 To: alice@example.com Message 2 To: bob@example.com Message 3 To: chris@example.com
The better application pattern looks ordinary, which is the point. Each recipient gets a normal message. Each event has a clear owner. Each bounce, complaint, unsubscribe, and reply can be processed without guessing.
What to ask a vendor or plugin developer
When a vendor asks to support undisclosed recipients, ask for the exact user story and the exact raw message they expect to generate. The phrase often hides different requirements, including privacy, batching, audit copies, group sends, or a workaround for a weak email module.
|
|
|
|---|---|---|
Who receives it? | Defines scope | One per person |
Why hide them? | Clarifies privacy | No shared list |
Is it bulk? | Changes risk | Use fanout |
Need audit? | Tracks proof | Log per user |
Need replies? | Affects routing | Use Reply-To |
Questions that expose the real requirement
If the answer is "we send to multiple users but do not want to disclose everyone," that is not a reason to use an empty To: group. It is a reason to implement per-recipient sending.
A practical acceptance rule
Support undisclosed recipients only for mailbox-style manual sending. For application mail, require a recipient fanout model and normal visible headers.
- Accept: one person sending a small private notice through a mail client.
- Reject: a website or app sending many users one hidden-recipient message.
- Replace: hidden batches with one generated email per recipient.
Views from the trenches
Best practices
Ask for the exact raw message before supporting an undisclosed recipient request.
Use one generated message per recipient when software sends the email at any scale.
Keep Bcc-only sending to small manual notes where recipient privacy is the goal.
Common pitfalls
Treating an empty To group as a product requirement hides the real sending problem.
Sending app mail through Bcc batches weakens tracking, suppression, and audit logs.
Assuming hidden recipients are anonymous ignores logs, routing, and provider records.
Expert tips
Separate visible headers from SMTP envelope data when debugging recipient behavior.
Inspect delivered headers because mail clients display empty recipient lists differently.
Replace shared Bcc batches with recipient fanout before volume or compliance increases.
A marketer from Email Geeks says 'undisclosed recipients' often appears when everyone is placed in Bcc and no visible To or Cc recipient exists.
2025-11-05 - Email Geeks
An expert from Email Geeks says the phrase is usually an old empty address group workaround, not a meaningful modern delivery feature.
2025-11-05 - Email Geeks
Should you use undisclosed recipients?
Undisclosed recipients are a display pattern for messages without visible recipients. They are mainly produced by Bcc-only sending or empty address-group syntax. They hide recipient addresses from other recipients, but they do not create anonymity, improve authentication, or replace a proper sending system.
Use them for small manual messages where recipient addresses must remain private. Put your own address in To and the private list in Bcc. For anything generated by software, send one message per recipient to preserve normal headers, accurate logs, and reliable compliance and suppression handling.
