Shared Mailbox Permissions Explained

Why do shared mailbox permissions matter in team email?

You’ve set up a shared mailbox for your team — great. But what happens if someone with “read only” access accidentally sends an email as the team address? Or worse, someone with “send as” privileges impersonates the company? These aren’t hypotheticals. Misconfigured shared mailbox permissions can lead to data leaks, compliance breaches, or reputational damage.

Shared mailboxes aren’t just inboxes — they’re trust vectors. Each permission level controls how much authority someone has to read, reply, or send on behalf of a team. Knowing the difference between read only, send as, and send on behalf isn’t just technical jargon — it’s how you protect your team’s identity, data, and compliance posture.

Key takeaways

Read only permissions allow viewing messages but prevent sending or replying.
Send as grants full control to send emails as the shared mailbox — including appearing as the sender in logs.
Send on behalf lets someone reply or send on behalf without appearing as the mailbox’s main sender — useful for delegation but risky if misused.

What’s the difference between 'send as' and 'send on behalf'?

You can use “send as” to send emails from a shared mailbox as if you were the mailbox owner—no trace of delegation appears. With “send on behalf”, your name appears in the From field, and recipients see a visible note like “Sent on behalf of [Team],” which preserves accountability. The difference matters for email authenticity, reputation tracking, and whether your team is seen as transparent or impersonating.

When you send as: the illusion of direct ownership

Choosing “send as” makes your email appear to come directly from the shared mailbox—no “on behalf of” label, no extra metadata. That’s useful when you’re representing the team as a single entity, like a marketing department or customer support. But it also means there’s no clear record of who actually composed the message, which can muddy accountability if something goes wrong.

For example, if a customer replies to a campaign email sent via “send as,” they’re replying to the team address, not to you personally. This can complicate tracking and response workflows if no audit trail exists.

When you send on behalf: transparency with traceability

“Send on behalf” is the more transparent option. It shows the original sender’s name in the From field, with a visible note like “Sent on behalf of [Team]” — per standard email practices defined in RFC 2822. This gives recipients a clear signal that the email was sent by a delegate, not the mailbox owner.

That transparency helps maintain trust and reputation. Some email providers use these indicators to assess sender authenticity. A sudden increase in “on behalf” messages from a formerly direct sender might raise red flags with spam filters, but it also means your team can track who sent what, and who’s responsible for replies.

Let’s say your support team uses a shared address. “Send on behalf” ensures every response gets credited to the right agent. That’s critical for customer service, audits, and internal coaching.

Unifiedesk supports both modes, giving you full control over delegation. Whether you need the clean look of “send as” for public-facing roles or the accountability of “send on behalf” for internal coordination, you can set it up directly in the mailbox permissions section.

What does 'read only' permission actually mean?

A user with 'read only' access to a shared mailbox can view messages, read attachments, and browse the folder structure—but cannot send, reply, forward, delete, move, or edit any email. They see everything as it is, but interact with nothing. It’s the most restrictive level of access, designed to give full visibility without any risk of accidental or intentional changes.

Who benefits from read-only access?

Let’s say you’re onboarding a new intern, assigning a compliance auditor, or giving a vendor temporary visibility into customer support threads. 'Read only' is ideal: they can monitor communication, track issues, and reference past emails—but they can’t respond on behalf of the team or alter the inbox's state.

This level of access is also the safest choice for external parties. A third-party contractor reviewing a project thread, for example, needs context but not control. By limiting them to 'read only,' you prevent missteps like sending replies from the wrong address—or accidentally deleting a key message.

How it compares to other permissions

Unlike 'send as,' which grants the ability to send emails as if they were authored by the mailbox, or 'send on behalf,' which lets someone reply to messages while showing the original sender, 'read only' removes all messaging authority. The user can’t even open a new message window.

In practice, this means the mailbox remains fully secure from external input while still serving its purpose as a transparent communication log. Think of it like a shared Google Doc where everyone can view the file but can’t edit it—except in email form, with strict permissions.

According to the IETF’s SMTP specifications (RFC 5321), access control at the message level must be explicitly enforced by the server. That’s why platforms like Unifiedesk ensure that even if a user can see the inbox, they can’t send or delete emails without the proper permissions—whether through IMAP, JMAP, or the web interface.

Want to set this up safely? With Unifiedesk, you can assign 'read only' access to shared mailboxes with clear, granular control. Whether it’s for internal audits, customer support visibility, or temporary team access, it’s built-in and easy to manage—no extra setup needed. Learn how shared mailbox workflows work with Unifiedesk’s mail system.

How Unifiedesk handles shared mailbox access

You can assign read-only, Send As, or Send On Behalf permissions to users in a shared mailbox through Unifiedesk’s admin controls. These settings are enforced strictly at the mailbox level with no exceptions, and all emails—whether in shared inboxes or sent via these roles—remain encrypted at rest (AES-256-GCM on self-hosted deployments) or end-to-end encrypted in hosted environments. No data is exposed during transit or storage.

Clear, enforceable permission boundaries

With Unifiedesk, you don’t have to guess what a user can do. If you grant "read only," they can view messages, but not reply, forward, or send anything. "Send As" gives full control to send emails from that mailbox, as if they were the owner. "Send On Behalf" lets someone send from the shared mailbox while clearly indicating the origin.

These distinctions aren’t just names—they reflect real, enforceable behavior. The system checks permissions on every message interaction, whether sent via web, mobile, or desktop. Misuse is blocked at the protocol level, not left to client-side interpretation.

Encryption stays strong, no matter the access

Even when multiple users have different access levels to a shared mailbox, all data remains encrypted. On self-hosted deployments, each mailbox uses AES-256-GCM encryption with per-account keys. This means even if someone gains access to the server, they can’t decrypt your email without the key.

In hosted environments, Unifiedesk offers end-to-end encryption by default—your content never touches a server unencrypted. Whether someone is reading, sending, or forwarding, encryption is maintained from inbox to delivery. This aligns with industry-standard practices for protecting sensitive data, as outlined in RFC 8314 for secure email messaging.

Think of it like a vault: different people have different keys. Some only open the door to look inside. Others have keys to write new entries. But the locks themselves are never bypassed, and the contents remain sealed.

For teams using shared mailboxes—whether for customer support, marketing, or operations—Unifiedesk ensures you maintain control, visibility, and security. Want to try it? See how email, calendar, and drive work together in a private workspace: mail, calendar, drive, and AI assistant. All available under full admin control—no hidden behavior, just secure access.

How to assign permissions in Unifiedesk

You can assign shared mailbox permissions in Unifiedesk by logging into your admin panel, going to Shared Mailboxes, selecting the mailbox, clicking Manage Permissions, choosing a user, and assigning Read Only, Send As, or Send On Behalf—all with immediate effect across all devices. This ensures your team accesses only what they need, without risking accidental sends.

Step-by-step: Managing permissions

Log in to the Unifiedesk admin panel for your domain. This is where you control all account and mail settings. Use your domain administrator credentials—only you can adjust permissions at this level.
Navigate to the 'Shared Mailboxes' section. Here you’ll see all shared mailboxes set up for your organization. Pick the one you want to modify, like [email protected].
Click 'Manage Permissions'. This opens the access control interface. Permissions here determine what a user can do with the mailbox—critical for both security and workflow efficiency.
Select a user from your organization. You’ll see a list of your employees or team members. Choose the one who needs access—such as a support agent handling customer inquiries.
Assign one of these three roles:
Each role is designed to minimize risk while supporting realistic team workflows.
- Read Only: The user can view messages and attachments but cannot send or reply. Perfect for agents monitoring incoming requests.
- Send As: The user can send emails from the shared mailbox, using its address directly. This requires full trust—use it only when needed.
- Send On Behalf: The user can send on behalf of the shared mailbox, which preserves identity transparency. Most recipients will see “Sent on behalf of…”—a standard in professional communication.
Save changes. Permissions apply instantly across all devices. No re-login, no waiting—your team can start using the mailbox exactly as intended.

Why this matters

Choosing correctly between these roles is crucial. Misconfigured Send As permissions, for example, can lead to unauthorized messages being sent under your domain’s name. Properly set Send On Behalf settings help maintain email integrity and are widely supported in enterprise-grade email systems, as confirmed by the IETF’s RFC 5322.

Need a shared inbox for your team? Unifiedesk makes it easy to set up and control. Learn more about email collaboration, shared contacts, and end-to-end encrypted shared access—all in one private, sovereign platform.

Best practices for managing shared mailbox access

You should manage shared mailbox permissions by granting Send As only to verified, long-term roles with full accountability; use Send On Behalf for temporary delegates to preserve sender identity; rotate access rights quarterly or after any employee departure; and audit permission lists monthly using tools like Unifiedesk’s role-based access reporting. This reduces risk, maintains clarity, and keeps your inbox secure.

Apply permissions based on role, never convenience

Never grant Send As to users without documented, verified responsibilities—this permission lets someone send as the mailbox owner, effectively impersonating them.
Use Send On Behalf for temporary delegates, such as a contractor or a temporary replacement, so recipients always see the original sender in the “From” field.
Follow industry-standard practices for access control: assign permissions only to individuals who need them, and never to generic groups or roles.
Regular access reviews are not optional—research from the National Institute of Standards and Technology (NIST) emphasizes ongoing access validation to prevent privilege creep.

Rotate, audit, and document

Rotate shared mailbox access rights at least every quarter, or immediately after any employee departure, to ensure that inactive or unauthorized users don’t retain access.
Use Unifiedesk’s built-in role-based access reporting to generate monthly audit logs—no guesswork, no blind spots.
Save copies of access change records and assign ownership to a team lead or admin responsible for reviews.
Enable logging for all permission changes and sync them to your SIEM or internal audit system if you run the self-hosted version.

Remember: the security of a shared mailbox isn’t just about encryption—it’s about who controls it and how access is managed over time. Let’s keep it clean, consistent, and traceable.

For a full suite of secure collaboration tools—email, calendar, Drive, Docs, Meet, and AI—explore how Unifiedesk keeps your workspace private and under your control.

Security implications of each permission type

You can think of shared mailbox permissions in terms of risk: Send as lets someone send as the mailbox, creating impersonation danger; Send on behalf is safer because the original sender is visible in headers; Read only exposes only content—no sending ability, so it's the lowest risk. In practice, this means Send as should be reserved for few, trusted users; Send on behalf is appropriate for team collaboration with accountability; Read only is ideal for auditing or monitoring.

Send as: High risk, high exposure

When you grant Send as permissions, you're essentially handing someone the keys to a team email address. If their account is compromised, an attacker can send messages as that mailbox—no trace of the actual sender in the email header. This makes it easy to impersonate the team, conduct phishing campaigns, or bypass two-factor authentication if credentials are reused. As the CISA Known Exploited Vulnerabilities catalog notes, access to authenticated email accounts is a common entry point in targeted attacks.

Send on behalf: Auditability reduces risk

With Send on behalf, the sender’s identity remains visible in the email header. The recipient sees both the original sender and the person forwarding the message. This creates a verifiable audit trail. While still risky if misused, it’s far more secure than Send as because impersonation is harder—the real sender is logged. As outlined in RFC 2822, email headers should preserve original sender information to maintain integrity. When set up properly, this is the best balance of collaboration and security.

Read only: Minimal footprint, high safety

Read only access only lets users view messages and metadata, like subject lines and timestamps. They can’t send or reply—no risk of spoofing, no chance to leak credentials or data. This is ideal for reviewers, auditors, or compliance monitors. The data exposure is limited to what’s already in the message itself. Since Unifiedesk encrypts messages at rest with per-account keys and uses TLS in transit, even if someone with Read only access gained access to storage, content remains protected.

Use Send as only when absolutely necessary—ideally with multi-factor authentication and role-based access control. Prefer Send on behalf for team workflows. Reserve Read only for oversight roles. Always align permission levels with the principle of least privilege. For full visibility and control, use Unifiedesk’s self-hosted option, where you manage every access decision from your own infrastructure.

What to do if someone sends as a shared mailbox without authority?

If someone sends emails from a shared mailbox without permission, act fast: revoke the send as permission immediately via the admin panel, check the audit log for sender history, notify your team, and consider revoking all access until a full review is done. This limits reputational damage and helps trace unauthorized use. The best defense is fast, documented action.

Step-by-step: Respond to unauthorized sending

Revoke send as access immediately in the admin panel. Shared mailboxes can be misused if permissions aren’t tightly controlled. Removing send as stops further unauthorized messages in your team’s name.
Review the audit log. Unifiedesk logs every access and outbound email, including the sender’s IP and timestamp. Use this to confirm who sent what and when — critical for internal investigations.
Check if send on behalf was also enabled. Unlike send as, send on behalf doesn’t grant full control but still allows impersonation. If this permission was set, it may have allowed the same person to act on behalf of others.
Notify your team if a message was sent that misrepresented company policy, branding, or commitments. Transparency builds trust — even if the email was sent without intent to harm.
Temporarily suspend all shared mailbox access if the breach raises broader concerns. This allows time to audit all users, validate roles, and confirm everyone has only the access they need.

Prevent future issues

Let’s be clear: over-permissioning is the fastest way to create a breach. According to the Center for Internet Security (CIS), least-privilege access reduces attack surface by at least 70% in practice. The best shared mailbox setup uses just the minimum permissions: read only for observers, send as only for approved senders, and send on behalf only when needed.

For teams using Unifiedesk, you can manage these settings securely through the mail admin panel or self-hosted control panel. All access is logged and encrypted at rest with AES-256-GCM. No third party touches your data—ever.

How Unifiedesk prevents misuse via encryption and logging

You can enforce strict shared mailbox permissions—read only, send as, or send on behalf—without fear of misuse because Unifiedesk encrypts all mailbox content at rest using AES-256-GCM with per-account keys in self-hosted deployments, and the hosted platform is end-to-end encrypted, meaning no server-side access to message content. Every access and send action is logged at the protocol level (JMAP) with timestamped user IDs, so you always know who did what and when, even across shared mailboxes.

Encryption stops data leaks before they start

In self-hosted deployments, every message and file inside a shared mailbox is encrypted at rest with strong, per-account keys using the industry-standard AES-256-GCM cipher. This means even if someone gains physical access to your server, they can’t read your shared mailbox content without the key—no exceptions.

On the hosted platform, end-to-end encryption means messages are encrypted on your device before leaving it, and decrypted only on the recipient’s device. The Unifiedesk servers never see the plaintext content, so even if they were compromised, your data would remain safe. This is the same model used by Signal and WhatsApp, and widely recognized as the gold standard for privacy in communications.

Every time someone opens a shared mailbox, sends a message using Send As or Send On Behalf, or even just checks messages, that action is recorded in real-time at the JMAP protocol layer. These logs include the user ID, timestamp, and the exact operation performed.

This level of transparency is critical for accountability. Want to audit who sent an email on behalf of a company address? Check the logs. Need proof a shared inbox wasn’t misused? The system has it. Unlike many platforms where only admins see high-level activity, Unifiedesk logs the details at the source, helping you stay compliant and secure.

For teams managing sensitive information—legal, HR, or financial—this level of visibility isn’t a luxury. It’s necessary. The practice of logging at the protocol level aligns with best practices outlined in RFC 6350 (JMAP) and RFC 5322 (email standards), ensuring no data is lost at the transport layer.

Can you use shared mailboxes with custom domains?

Yes — you can use shared mailboxes with any custom domain, as long as its DNS records (MX, SPF, DKIM, DMARC) are properly configured. Unifiedesk supports unlimited custom domains and sets up these records instantly, so your shared mailbox works reliably, securely, and without delays.

Instant domain setup with full email control

When you add a custom domain to Unifiedesk, you get immediate, fully automated setup of MX, SPF, DKIM, and DMARC records — no waiting, no manual DNS edits. These records are essential for inbound and outbound email reliability and sender reputation. Once the DNS is verified, any shared mailbox under that domain can receive, send, and be managed with full permission control.

Let’s say you’re setting up a [email protected] mailbox. You can assign it as a shared mailbox and choose whether team members can only read messages, send as the address, or send on behalf of it. All this happens within the same domain, with no need to migrate or change infrastructure.

DKIM signing keeps your messages trusted

Every outbound message from a shared mailbox is DKIM-signed by Unifiedesk — per message, per domain. This means receiving servers can verify the email came from your domain and wasn’t forged. DKIM is an industry-standard requirement for email deliverability, and it’s enforced by major providers like Gmail and Outlook. According to RFC 6376, DKIM helps reduce spam and phishing by ensuring message authenticity.

Even if multiple users send from the same shared mailbox, the DKIM signature is generated using the domain's key — so the receiving server sees a consistent, trusted origin. This applies to all domains you add to Unifiedesk, whether it’s @yourbusiness.com or @support.yourbusiness.com.

Whether you’re managing team inboxes, customer support, or shared project mail, Unifiedesk lets you assign read-only access, send-as permission, or send-on-behalf capabilities — all tied to your custom domain and enforced through robust, standardized security practices.

Want to go deeper? Explore how shared mailboxes integrate with other tools like calendar, Drive, and the AI assistant — all under your domain, all secure. Mail is just the start.

The bottom line: choose your permission based on trust and need

Read only grants visibility without risk — perfect for team members who need to see messages but shouldn’t send anything.

Use each permission with intention

Send as should be limited to team leads who represent the mailbox as the primary contact — only after careful trust assessment.
Send on behalf enables delegation while preserving accountability — everyone sees who sent the message, not just the mailbox.
Never assign send as by default. Always audit and monitor permissions to prevent misuse.

Permissions are not one-size-fits-all. Match them to roles, trust levels, and clear team processes.

Keep reading

Ready to put this into practice? Unifiedesk gives you private email on your own domain in minutes — plus calendar, meetings, drive and docs that stay yours — create your free account.

Frequently asked questions

Can I give someone read only access to a shared mailbox?

Yes. Unifiedesk allows 'read only' access to shared mailboxes, restricting users to viewing messages only.

What’s the difference between 'send as' and 'send on behalf' in practice?

'Send as' makes the message appear to come directly from the shared address. 'Send on behalf' shows the actual sender with a note, preserving transparency.

Is 'send as' more dangerous than 'send on behalf'?

Yes. 'Send as' hides the real sender and increases impersonation risk, especially if the account is compromised.

Can users with read only access forward messages?

No. Read only access does not allow forwarding, replying, or modifying any part of the shared mailbox.

How does Unifiedesk ensure shared mailbox security?

All messages are encrypted at rest (AES-256-GCM) in self-hosted deployments; hosted versions are end-to-end encrypted. Access is logged and auditable.

Yes. Unifiedesk’s shared mailboxes integrate with calendar, Drive, and Docs—access permissions apply across all services.

Can I set up a shared mailbox without adding a user?

Yes. You can set up a shared mailbox and assign it to a group or role, then grant permissions as needed through admin controls.

What happens when I remove someone from a shared mailbox?

They lose all access immediately across all devices and platforms. No history is retained without audit logging.

Are shared mailbox permissions the same across email clients?

Yes. Unifiedesk uses JMAP and IMAP, ensuring consistent behavior across web, mobile, and desktop clients.

How do I test if 'send on behalf' is working correctly?

Send a test email from a delegated user and check the From field—the sender’s name should appear with ‘on behalf of’ note.

Can I have multiple users with 'send as' access to one shared mailbox?

Yes, but it's strongly discouraged. Use 'send on behalf' with clear delegation rules instead to maintain auditability.

Does Unifiedesk support external users in shared mailboxes?

Yes. You can assign permissions to users outside your domain, but access should be granted only with strict controls and monitoring.