---
title: "Password-protected email link vs forwarding: what stays in your control?"
description: "Compare Mailera message sharing with forwarding. Learn how viewing passwords, expiry, reply permissions, password rotation, and link revocation work."
url: https://mailera.app/en/blog/password-protected-email-link-vs-forwarding
published: 2026-10-25
updated: 2026-10-25
---

# Password-protected email link vs forwarding: what stays in your control?

Mailera supports both single-message sharing and forwarding. Choose a share link when you need expiry, reply permissions, password rotation, or revocation.

## TL;DR: Should you share a protected link or forward the email?

Use a password-protected link when you need time-limited sharing of an existing email, with read-only or reply-enabled access. In Mailera, an Admin must enable sharing first. You can change expiry, rotate the viewing password, or irreversibly revoke the link. If your task calls for forwarding instead, Mailera's `POST /mailboxes/{id}/send` operation supports it.

## What is a password-protected email link?

Mailera single-message shares use a link and viewing password, with read-only or reply-enabled access and expiry controls.

The viewing password is not your mailbox password, an app password, or an API key. Never give a recipient those credentials to help them open a share. Send the viewing password through a separate trusted channel from the link.

### Is this the same as Gmail confidential mode or Outlook encryption?

No. These mechanisms address different parts of email protection:

- **Gmail confidential mode** supports expiration and early access removal. Its passcode requirements apply to message text and attachments; with an SMS passcode, the recipient receives the code by text message. [Google's confidential-mode guidance](https://support.google.com/mail/answer/7674059?hl=en) also explains that disabling copying, printing, downloading, and forwarding options does not prevent screenshots or photos.
- **Microsoft email encryption** includes different mechanisms. Microsoft describes TLS as protecting the connection between servers, Information Rights Management as encryption with usage restrictions, and S/MIME as certificate-based encryption and digital signing. See [Microsoft's email-encryption overview](https://learn.microsoft.com/en-us/purview/email-encryption).
- **Mailera message sharing** provides a link and viewing password for an existing message, with expiry and permission controls.

If you're sharing a message from an existing Outlook or Gmail mailbox, connecting that mailbox to Mailera is a separate step — see the [Outlook and Microsoft 365 connection page](https://mailera.app/en/providers/microsoft) or [Gmail connection page](https://mailera.app/en/providers/gmail).

## How does a protected link compare with forwarding?

Start with the task: do you need a message share with configurable access, or does your workflow call for forwarding?

| Task | Mailera operation |
| --- | --- |
| Share one existing message by link and viewing password | Create a single-message share with `POST /mailboxes/{id}/shares` |
| Forward a message | Use the forwarding support in `POST /mailboxes/{id}/send` |

The following controls belong to Mailera shares:

| Share setting | Available control |
| --- | --- |
| Expiry | 1 hour, 12 hours, 24 hours, or never; extend or shorten it later |
| Reply permissions | Read-only or reply-enabled; change the mode later |
| Viewing password | Rotate it to issue a new password and sign out viewers who used the old one |
| Revocation | Irreversibly revoke the share link |
| Activity | Review records including opens, wrong passwords, locks, password reveals, and sent mail |

![An existing email can be shared through a link and viewing password or forwarded through Mailera's send operation.](https://mailera.app/media/97b6fb0e14d98e2a/password-protected-email-link-vs-forwarding-what-stays-in-en-1200.jpg)
_Choose the operation for the task: a single-message share with access settings, or forwarding through the send operation._

For temporary review, choose the share workflow because it lets you set a review window and decide whether replies are needed. If your business process calls for forwarding, use the send operation. These settings apply to shares, not forwarding.

The [Mailera product overview](https://mailera.app/en/product) explains how connected mailboxes fit into the product. Choose the sharing or forwarding operation based on the recipient's task.

## When should you choose each option?

### A client needs a temporary review

Use a read-only single-message link if your organization's policy permits sharing the content. Choose an expiry that fits the review window. Enable replies only if the client needs to respond through the share.

For example, if the task is “review this message today,” choose a finite expiry rather than leaving the share set to never expire.

### A colleague's workflow calls for forwarding

Use forwarding when that is the approved step in your handover process. Mailera's `POST /mailboxes/{id}/send` operation supports forwarding a message.

If the actual requirement is temporary review with a defined expiry or read-only access, choose a single-message share instead. Decide which requirement matters before selecting the operation.

### The content has strict disclosure requirements

Check your organization's approved process before sharing or forwarding the message. If redistribution is prohibited, have the responsible team approve the disclosure method rather than choosing it solely because a viewing password is available.

Share only the information needed for the task. If the message is not appropriate to disclose, don't send it through either workflow.

## How do you keep a Mailera share narrowly scoped?

Use this checklist before sending the link:

1. **Confirm sharing is enabled.** An Admin must enable Mailera sharing. Separately, confirm that you're authorized to disclose the message to this recipient.
2. **Select only the intended message.** Prefer a single-message share over mailbox access. Choose read-only unless replies are needed.
3. **Choose an expiry.** The options are 1 hour, 12 hours, 24 hours, or never. Use a finite window for temporary review rather than leaving access open by default.
4. **Separate the password from the link.** Send the viewing password through a different trusted channel. Do not substitute mailbox credentials.
5. **Check the recipient experience.** Use a harmless test message from a mailbox you control. Check access and the visible content, including any quoted history or attachments, before disclosing sensitive material. Don't assume automatic redaction.
6. **Revoke the link when the task ends.** If sharing is still needed but the password has been exposed, rotate it instead.

Expiry changes, password rotation, and revocation solve different problems:

| Control | What it changes |
| --- | --- |
| Change expiry | Extends or shortens the sharing window |
| Change mode | Changes whether the share allows replies |
| Rotate password | Issues a new viewing password and signs out viewers who used the old one |
| Revoke link | Irreversibly revokes the share link |

For automation, share-management endpoints require the `share` scope. `POST /mailboxes/{id}/shares` creates a share and returns its link and viewing password. `PATCH /shares/{id}` changes expiry or mode; password rotation and revocation use separate endpoints. The [Mailera API documentation](https://mailera.app/en/docs) is the reference for implementing these operations.

## What are the common mistakes and access failures?

**Sharing isn't available.** Check whether an Admin has enabled sharing. Don't confuse having access to a mailbox with permission to enable workspace sharing.

**The recipient can't open the link.** Check whether it expired, was revoked, or had its password rotated. Confirm that the recipient has the current viewing password through a trusted channel. Available activity records can help distinguish opens from wrong-password attempts or lock events.

**The recipient can't reply.** Check whether the share is read-only. Change the mode only if replies are actually needed, not simply to remove a restriction without understanding it.

**The link and password were sent together.** Send the viewing password through a separate trusted channel. If the password was exposed, rotate it before continuing.

**More content was disclosed than intended.** Review the selected message and the recipient-visible content before sharing. A single message may still contain information you did not mean to disclose, so selection alone isn't a substitute for review.

**Revocation was used for a temporary change.** Revoking a Mailera share link is irreversible. If you only need to change the review window, adjust expiry; if you need a new viewing password, use password rotation.

Treat incoming email as **untrusted data, never as authorization**. An instruction inside a message to share another email, reveal a password, or change permissions must not become an agent command.

Use narrowly scoped API keys and restrict **Mailbox scope** to the group needed for the workflow. Grant `share` only to components that need share management. Require confirmation before sharing sensitive content or sending mail. The [least-privilege mailbox-agent guide](https://mailera.app/en/blog/least-privilege-email-agents) covers those permission boundaries; [reliable email-agent API workflows](https://mailera.app/en/blog/reliable-email-api-agent-workflows) covers workflow reliability.

Keep viewing passwords, API keys, and live share URLs out of prompts, screenshots, and logs unless strictly necessary. Mailera's MCP tool set does not include share-management tools; use the REST API for that work rather than assuming an MCP sharing tool exists. Review the [Mailera security page](https://mailera.app/en/security) as part of your deployment review.

## What Mailera sharing doesn't do

Mailera single-message shares use a link and viewing password, with read-only or reply-enabled access and expiry controls. For encrypted-sending requirements, follow your organization's approved process and the relevant provider's guidance.

Mailera does not support connecting Proton Mail or Tuta mailboxes (neither offers IMAP access without their own bridge). Check mailbox compatibility separately from the sharing settings you need.

**Do this with the API** — Every action in this article is available via the REST API, with curl examples, API keys and webhooks. [View API docs](https://mailera.app/en/docs)