Groups

A group is a shared address on your domain, e.g. [email protected] or [email protected], whose members are your domain users.

It works in both directions:

• mail to the group reaches each member's own mailbox
• each member can send as the group address

To the outside world the team is one address. Inside, each person keeps their own mailbox, credentials, and rules.

A group is an address, not a person

• It has no mailbox, storage, password, or sign-in of its own. Nothing collects "in" the group; each copy is in a member's mailbox from the moment it arrives.
• Membership is a property of the domain user, not a list on the group. You add somebody to a group from their page. The group's page shows who is in it, but you don't edit membership there.

Create a group

Groups are created where every other address is: open Email & Identity → Accounts, choose the domain, then Create, then the Group type.

The form asks for:

• a Group Address: the local part only, up to 30 characters
• a Group Name, optional: the display name a member sends under
• a Note, for you. Nobody who receives mail sees it.

One namespace per domain

The address shares one namespace with every other address on the domain, so [email protected] can be a group, or a domain user, or a forwarder, but not two at once. Account types covers the namespace and compares the types.

Membership

A domain user's groups are set on the user: the Groups field when you create the user, and the Group Membership section of their page after that.

The panel offers the groups on that user's own domain, so a group and its members are always on the same domain: a group on example.com collects domain users of example.com.

Only a domain user can be a member

A group can't hold another group, a forwarder, a send-only account, or any external address. When the audience is anything other than your own domain users, you want a mailing list.

The group's page lists its members, each linking to their account. It's the fastest answer to "who is on support@ right now?". There is no limit on the number of members.

What happens to mail sent to the group

Each member gets their own copy, delivered to their mailbox like any other message.

The message isn't rewritten: From still names the person who wrote it, so a member who replies replies to that sender. That's the biggest difference from a mailing list, which rewrites From to the list.

Delivery happens per member, so everything that belongs to a mailbox applies to the copy:

• the member's Sieve rules sort it
• the member's quota holds it
• suspected spam goes to their Junk folder rather than being refused. The copy goes to a mailbox you host, so there's no reputation at another provider to protect. A forwarder is different.

A group with no members refuses mail

The address is withdrawn while the group is empty: the server doesn't accept a message and then drop it, and a sender gets an ordinary "no such address" refusal. So removing the last member is a visible act, and mail doesn't disappear silently.

Send as the group

Every group a domain user belongs to is one of the addresses they can send from, in the From: header and as the envelope sender.

The mail server checks this at submission: a member sending as [email protected] is accepted, anyone else trying the same address is refused. The message counts against the rate limit of the user who sent it.

The result is that a team conversation stays with the team. A reply a member sends as the group arrives from [email protected], so the answer comes back to everybody, not to one person's inbox.

Clients know different things

A client that signs in through the portal, webmail included, learns which addresses the user can send as, so a group can appear there as a selectable identity.

A client set up with a plain password knows nothing about this; the user adds the identity by hand. The check at submission is the same either way.

Delivery Failures

Mail to a group goes to each member separately, so one member's mailbox can fail, most often over quota, while the others receive the message normally.

Why the report goes to the group, not the sender

The sender did nothing wrong and can't repair a mailbox they don't own. And they must not learn your team's membership from a bounce.

The reports are on the group's Delivery Failures tab, one row per failure:

• the time and the member. If the member left the group after the failure, the row shows the plain address instead.
• the result, and the reason the receiving side gave
• whether a summary email already included the failure
• the subject and sender of the message that failed

The result is one of:

Result	Meaning
Failed	Permanent. That member didn't get the message and won't.
Delayed	Temporary. The server keeps trying.
Relayed	The server handed the message to a system that reports nothing back, so the result is unknown.

The summary email

Nobody watches that tab, so the panel also emails the failures to the members:

• Each member gets the same summary, covering every failure no summary has reported yet.
• At most one summary per group every three hours.

So one problem is one email, not one per failed message, and a mailbox that's full for a week doesn't also fill every other member's inbox. The tab's description shows the time of the last summary.

The summary names each failed address with its number of failures, the first and last time, the reason the receiving side gave, and the affected messages, and links back to the tab. A long summary is cut to about ten addresses with a few messages each, and says how much it left out; the tab always holds everything.

It's automatic mail with no reply address

Act on it in the panel instead.

The summary goes to each member, including the one it's about. If that member's mailbox is the problem, their copy is deleted rather than refused: their own mailbox already tells them, the rest of the team knows, and a report about a delivery failure must never cause one. Once the mailbox works again, the next summary reaches them too.

Nothing more happens automatically

A member whose mailbox keeps failing stays in the group. A mailing list is different: it removes an address that keeps bouncing, to protect its own sending reputation.

Group members are your own people, so the fix is to repair the mailbox, not remove the person. Make space, correct the address, or remove the member yourself. The records are kept for 180 days.

tip

Look at this tab first when somebody says they never got a message the rest of the team discussed.

A group as an audience

A group also answers "who can see this?".

• A restricted website can name a group instead of individual people, so the .htaccess file never changes when somebody joins or leaves; you grant access by adding the person to the group in the panel. The rule differs between the two authentication methods, and group membership reaches an open browser session only after that session ends. Restrict access covers both.
• Your own applications can use the same membership. A domain user's groups reach every application connected to the identity provider as the elpan:groups claim, listing the group addresses the user belongs to.

So a group is a usable authorization role: "everyone in [email protected] can open the reports section", with your application keeping no copy of who is on which team.

When a group is the wrong choice

Situation	Use instead
The recipients are outside your domains. A member must be a domain user, and mail to an external address fails in different ways.	A mailing list.
The audience manages itself. A group has no subscription, moderation, or archive.	A mailing list, which has all three.
Only one person reads the mail.	That person's domain user, or a forwarder if the address has to move later.