Skip to content

Admin-Managed Shared Mailbox Access in Nextcloud Mail #12223

Description

@Bytrider

Is your feature request related to a problem? Please describe.

In organizational environments (e.g. associations, SMEs, healthcare facilities, schools), email communication is often based on shared mailboxes such as info@, support@, or office@.

Currently, shared mailboxes in Nextcloud Mail must be manually configured per user and per client.
There is no central administrative interface to:

  • Define shared mailboxes
  • Assign users to mailboxes
  • Control access and sending permissions centrally

This results in:

  • High administrative overhead
  • Inconsistent configurations
  • Increased error rates, especially during onboarding/offboarding

Describe the solution you'd like

Extend Nextcloud Mail with an admin-level mailbox management interface that allows administrators to:

  • Centrally define shared mailboxes (email address / IMAP account)
  • Assign users to those mailboxes
  • Define per-user permission levels:
    • 🔍 Read-only
    • ✉️ Send
    • 🔧 Full access
  • Control mailbox visibility and sending rights independently from a user’s personal email setup

This feature should integrate into the existing Nextcloud account and permission model.

Describe alternatives you've considered

  • Centralized management of shared mailboxes
  • Reduced setup and support effort
  • Clear role-based email access
  • Improved suitability for multi-user organizations

Additional context

  • Group-based mailbox assignment
  • Audit log for mailbox access
  • API support for automated provisioning

Activity

  1. ChristophWurst commented on Jan 9, 2026

    @ChristophWurst
    Member

    I'm tagging this feature request as accepted. Some of this feature will require a mail server that supports the specific use case.

  2. bernd-wechner commented on Jan 14, 2026

    @bernd-wechner

    I would add:

    • Assign user groups to shared mailboxes

    I would also suggest avoiding the term "Shared mailbox" as that idea already exists on mail servers (notably, Microsoft provide these). What I suspect we're all keen on here is rather "Shared mail configuration".

    But if such a feature is implemented and supported as a set of properties in an existing mail configuration it might not need a specific name in the UI, so much as a "share" option. If it's characteristically different (for example series in a different place/table) it may still need a name.

  3. Overpass4014 commented on Jan 31, 2026

    @Overpass4014

    We would also very much like to see this feature implemented. If this is helpful, we would be willing to make a financial contribution.

  4. MundMBo commented on Feb 18, 2026

    @MundMBo

    It is not a good admin interface, but in the past I just used PhpMyAdmin and copied an existing mailbox configuration in oc_mail_accounts and just changed the user_id. After waiting for the next cron execute or executing php occ mail:account:update <id> manually, the mailbox was setup perfectly fine for another nextcloud user. I know this is not the intended way, but for a workaround it is enough.

  5. bassjoe commented on Mar 27, 2026

    @bassjoe

    To be able to select users based on their groups rather than their email domains, I first set up a Nextcloud development environment and tried to understand the code so I could implement the functionality myself. Unfortunately, I've had a very hard time understanding how everything fits together, partly because I have very limited access to step debugging and logging. That's why I haven't gotten very far with the implementation; see
    https://github.com/bassjoe/mail/tree/12223-shared-mailbox

    In my opinion, the ideal solution would look something like this:

    • Name: Managed Accounts (vs. Personal Accounts), whether shared or personalized using a template
    • Any number of accounts, sorted alphabetically in the app after personal accounts (currently, you can configure multiple accounts, but only one is applied or displayed per user)
    • For managed accounts, the user has no access to server settings or login credentials
    • The account title on the configuration page should be the account's email address (or the template with placeholders). This would also be a more meaningful UNIQUE index in the database than the domain pattern.
    • In the UI, the account's email address should be entered first, and only then should you specify which users it should be available to etc.
    • Instead of a preview, a link should display how many users the configuration currently applies to, and clicking it should show a list of those users where you can also search by name. However, this should only serve for traceability, i.e. be read-only.
    • The server settings (Host, Security, and Port) should be entered separately and be reusable for multiple accounts. The login credentials, on the other hand, should remain part of the account. In the UI, the username should be pre-filled with the email address as long as the user has not entered anything.
    • The configuration of managed accounts on the groupware configuration page should be displayed in a condensed table with one row per account. For convenient input and details, dropdown menus and links to pop-ups should be included in the table cells. For example, the IMAP column could simply display the hostname as a link, and a pop-up would then show the SSL and port configuration, which also applies to other managed accounts using this IMAP server.
    • The placeholders are hard to read; [userid]@example.com would be more readable than %USERID%@example.com
    • I don't understand why one would want to select the users to whom the managed account is provided based on the domain of their email address. (If the use case only occurs in combination with LDAP, one should instead be able to specify an LDAP query.)
    • The selection based on groups should be represented as a separate table in the database so that consistency is maintained when a group is deleted (or renamed, if that is possible). If no groups exists, no one should be able to view the account.
    • To provision a managed account for all users, this should be explicitly selected in the configuration.

    Someone with more Nextcloud development experience or a better development environment should take this issue further. The intended scope of implementation should be broken down into issues that are as small as possible and build on one another.

    If I could assign managed accounts to users by group, that would be an absolute killer feature for me, even without permission controls. This would also play well with the app visibility setting which is also based on groups.

  6. philippejadin commented on Oct 8, 2026

    @philippejadin

    My 2 cents on this feature purely from a end user (admin) standpoint.

    In short : I would love to see it handled exactly the same as team folders.

    • allow admin to configure a "team mailbox" not owned by a specific user (mailbox credentials are handled by admin)
    • allow admin to share this team mailbox with groups
    • show team mailboxes alongside other (per user) mailboxes for each group member in the mail interface. Bonus point to provide some permissions per group, per mailbox (read, compose, delete would be a good start)

    hope that make sense!

  7. Backtrennpapier commented on Oct 10, 2026

    @Backtrennpapier

    Totally agree to the original suggestion and follow-up comments. I think many especially organizations don't have the possibility to operate their own mail servers or pay for mail providers that support delegation.
    I see that #7723 was implemented, but this feature still requires an account to delegate from. I see it more as a delegate personal account feature i.e. share it (and why I also agree that shared mailbox might be misleading). This feature is much more in the area functional or team mailboxes. Nextcloud already offers a strong package, but this one especially would help them. hope it can be developed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions