Share one email with a client, not your whole inbox

What do you need before sharing an email?

A single-message share gives you a link and viewing password for one existing email, with a choice of read-only or reply-enabled access.

Start with an existing connected mailbox, the intended message, and permission to disclose its contents. An Admin must enable sharing. Ask your Admin about your permissions rather than assuming that access to a mailbox also authorizes you to share its messages.

Mailera does not create new mailboxes or email addresses. This workflow uses mail you already have. The Mailera product overview explains that model; use the Outlook and Microsoft 365 connection guide or Gmail connection guide if your mailbox is not connected yet.

Read the entire message before sharing it. Check the body, quoted conversation, sender and recipient addresses, and any attachments for confidential material. A message with a harmless latest paragraph may contain an earlier discussion that your client should not see.

This is also different from mailbox delegation. Google’s Gmail delegation documentation describes delegates as people who can read, send, and delete email in the delegated account. That is a broader job than reviewing one message.

How do you share just one email with a boss or client?

1. Open the intended message. In Unified inbox, confirm its mailbox, sender, subject, and full content. Do not rely on the subject alone when several messages look alike. If you cannot locate it, the guide to finding one message across mailboxes covers the search task.
2. Create a single-message share. The API entry point is POST /mailboxes/{id}/shares, which returns the link and viewing password. It supports both mailbox shares and single-message shares; use the Mailera API documentation for the request details. Choose the individual message, then confirm the scope before distributing anything. A mailbox-wide share is not appropriate when the recipient needs only one email.
3. Choose read-only access. Use reply-enabled access only when the recipient needs to respond through the share. Reading an approval request does not, by itself, require permission to send a reply.
4. Set an expiry. The available durations are 1 hour, 12 hours, 24 hours, or never. Choose a limited duration that covers the review window. For example, a same-day review may fit a 12-hour window; avoid leaving a one-off share open indefinitely merely to save a later setup step.
5. Copy the link and viewing password. Send the password through a separate channel from the link. Do not send your mailbox password, app password, or API key: those are not the share’s viewing password.
6. Before distributing the share, review the recipient-facing content and access mode. Confirm that they match what you intend to disclose.

What can the recipient see and do?

The share’s scope and access mode answer different questions: which content is shared, and whether the viewer can reply.

Decide whether the task is simply to read this email or to collaborate inside the workspace. For ongoing team access, see workspaces and roles; for broader mailbox management, see the unified inbox operations guide.

How do you change or stop access?

Mailera’s share-management API supports changing expiry, rotating the viewing password, and revoking a link. These operations require the share scope. For broader integration design, see reliable email API workflows.

Choose the action that matches the problem:

Revocation is irreversible. If you revoke a link by mistake, do not keep distributing it; create a new share for the intended task.

Share activity can include opens, wrong passwords, locks, password reveals, and sent mail. Use those events to investigate access problems. An open event is not proof that a particular person read or understood the email. If the task requires approval, ask for an explicit response rather than treating an open as consent.

What commonly goes wrong?

Sharing is unavailable

Check with an Admin that sharing is enabled and that your permissions allow the task. Mailbox visibility alone is not a reason to assume you can create a share. Do not work around a permissions problem by handing over mailbox credentials.

The recipient cannot open the message

Check the current viewing password, the expiry, and whether the link has been revoked. Review share activity for wrong-password or lock events. Confirm that the recipient has the current link and password, particularly if you have created a replacement share.

The recipient cannot reply

Check whether the share is read-only. Mailera supports reply-enabled shares, but a read-only share is the right choice when the recipient only needs to inspect the message. Do not broaden access unless replying is part of the task.

The share exposes too much content

Revoke an incorrectly scoped link. Recheck the selected message and its quoted history before creating another share. Selecting one email is not a substitute for reviewing everything contained in that email.

A password change interrupts a viewer

Password rotation signs out viewers who used the old password. Tell the intended recipient that the password has changed and deliver the replacement through your chosen separate channel.

What are the privacy limits of sharing by link?

Expiry and revocation control future access through the link. They cannot erase content someone has already copied, captured, or photographed. Read-only access should not be treated as a promise that the recipient cannot retain the content.

This distinction also appears in Google’s confidential-mode guidance: Google allows access to be removed before expiry but warns that recipients can still take screenshots or photos. Those are Gmail’s controls, not a description of Mailera’s implementation.

Treat the link and viewing password as sensitive access information. Use a limited expiry for a one-off review, and share only content the recipient is authorized to see. If the material is too sensitive for the recipient to retain a copy, reconsider whether it should be shared at all.

For your organization’s review of Mailera itself, consult the Mailera security page. Keep that review separate from the content decision: access controls do not replace permission to disclose the message.