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

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 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.
• 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 or Gmail connection page.

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?

The following controls belong to Mailera shares:

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 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:

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 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 covers those permission boundaries; reliable email-agent API 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 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.