What an administrator can configure
Install and initial setup cover a single domain and a single mailbox. That is a starting point, not a ceiling. Once a deployment is running, an administrator — through the admin UI or the Admin API directly — can add domains, give a person multiple addresses, provision shared mailboxes, group people together, and review deliverability and audit history. This page is a map of that surface; the Admin API reference has the RPC-level detail.
Domains and addresses
Section titled “Domains and addresses”Multiple domains
Section titled “Multiple domains”A deployment is not limited to the domain created at bootstrap. DomainsService.AddDomain registers
another domain in SES, and ListDomains returns all of them; each domain has its own send/receive
capabilities, DMARC policy, and SPF mode, configured independently. In the admin UI this is the
Domains page. One domain is flagged is_primary, but nothing in the proto suggests sending or
receiving is restricted to the primary domain — each domain that has send_enabled / receive_enabled
set works on its own.
Source: admin-api/proto/domains.proto:389-422 (DomainsService, AddDomain/ListDomains);
admin UI navigation.domains / pages/domains/index.tsx.
Aliases — multiple addresses per account
Section titled “Aliases — multiple addresses per account”AliasesService lets an account receive mail at more than one address. CreateAlias adds an address
on any configured, verified domain to an existing account; each alias independently controls:
is_active— whether incoming mail to it is accepted at all,is_visible— whether it shows up in the UI’s sender picker,can_send_from— whether it may be used as the From address when composing or replying (defaultfalse; an alias that only receives mail does not automatically get to send as that address),name,reply_to,bcc— per-alias From display name, Reply-To override, and an always-BCC address for mail sent from it.
Plus-addressing is separate from aliases and needs no setup: mail to
you+anything@your-domain.com is delivered to you@your-domain.com. That holds for every address
on the deployment, out of the box — there is nothing to configure and no alias to create for it.
The primary alias created with the account can be deleted like any other (DeleteAlias “can delete
primary aliases” per the proto comment), though the account still needs at least one address to
function — the proto does not state what happens if the last alias is removed, so treat that as
unverified. In the admin UI, aliases are managed from the Accounts page, per account.
Source: admin-api/proto/aliases.proto:7-156; admin UI i18n/locales/en.json accounts.aliases.*,
components/AccountAliasesPanel.tsx.
People and access
Section titled “People and access”Shared mailboxes (resource accounts)
Section titled “Shared mailboxes (resource accounts)”ResourceAccountsService provisions resource accounts — mailboxes not tied to a single person.
CreateResourceAccount takes a resource_class: SHARED (a standard shared mailbox), ROOM, or
EQUIPMENT (bookable resources). Each resource account gets its own JMAP account and email address,
and capabilities (mail, contacts, …) are added to it after creation with
AddResourceAccountCapability, the same way a user account’s capabilities are extended. In the admin
UI this is the Resources page; the create dialog labels these presets “Shared Inbox”, “Meeting
Room”, “Equipment”, and “Contact List” (equipment/rooms/contact-list are marked “coming soon” in the
UI copy even though the proto’s ResourceClass enum already defines ROOM and EQUIPMENT).
Access to a resource account is granted per-principal with AddDelegate / RemoveDelegate /
ListDelegates, at one of two levels: READ_ONLY or READ_WRITE (“read-only access to mailbox
contents” / “full read/write access to mailbox contents”, per the proto comments). A delegate can be
either a user or a group. Whether READ_WRITE delegate access also allows sending mail as the
resource account (as opposed to editing its mailbox contents) is not stated in the proto or the admin
UI copy — unverified, would need to be checked against the JMAP-layer authorization code.
Source: admin-api/proto/resource_accounts.proto:8-233; admin UI i18n/locales/en.json
resources.*, pages/resources/components/DelegatesPanel.tsx.
Groups
Section titled “Groups”GroupsService manages group principals — a name, an owning user (owner_principal_id), and a
membership list managed with AddGroupMember / RemoveGroupMember / ListGroupMembers. Unlike a
resource account, a group has no email address or JMAP account of its own: the admin UI’s group
creation dialog only collects a name and an owner (the local_part / domain fields that exist in
the UI’s translation strings are not wired into the create form, and CreateGroupPrincipalRequest
has no such fields either — a group cannot currently be given a receiving address).
A group’s practical use is as a delegate principal: AddDelegate on a resource account accepts either
a usr_ or a grp_ principal ID, so a group can be granted shared-mailbox access on behalf of all
its members in one step instead of adding each person individually. Whether group membership is
actually expanded at authorization time (so that being a group member grants the group’s delegate
access) is not established from the Admin API contract or the admin UI — an unbounded search of
modules/ found no Go code that resolves group membership into access decisions. Treat that
mechanism as unverified.
Source: admin-api/proto/groups.proto:8-161; admin UI pages/groups/index.tsx,
pages/groups/details.tsx.
Beyond the setup flow’s first admin, UsersService (see the
Users reference) is where accounts are added, disabled, or removed
day to day, and where a user’s rights (mail, admin, or both) are set. This page does not repeat that
detail — see the admin UI’s Users section and the reference page for the full RPC set.
Deliverability and oversight
Section titled “Deliverability and oversight”Suppressions
Section titled “Suppressions”SuppressionService tracks per-recipient bounce and complaint history and lets an admin inspect or
clear it. ListSuppressions / GetSuppression show the current bounce level (none/soft/hard) and
complaint level (none/permanent, tracked separately per message class — transactional, mailing list,
bulk). ClearBounceSuppression and ClearComplaintSuppression reset the level to NONE while
keeping the historical counters. The admin UI’s Suppressions page surfaces these as a “Manage”
action with an explicit warning that clearing suppression for a recipient who keeps bouncing or
complaining can damage sending reputation. See
Bounce & Complaint Handling for how a recipient ends up
suppressed in the first place, and the Suppression reference for
the RPCs.
Mail feedback
Section titled “Mail feedback”MailFeedbackService is the underlying event log Suppressions is built on: ListRecentFeedback,
ListFeedbackByIdentity, and ListFeedbackByRecipient return individual bounce/complaint events
(SES bounce type and sub-type, complaint feedback type, the identity and account that sent the
message) rather than the aggregated suppression state. This is a separate, read-only Mail Feedback
page in the admin UI, useful for investigating why a recipient ended up suppressed.
Email identities
Section titled “Email identities”EmailIdentitiesService manages individual verified sender addresses in SES — distinct from a
domain-wide verification. AddEmailIdentity registers a single address (not a whole domain) and
ResendVerificationEmail re-sends the confirmation link; this is the mechanism used while an AWS
account is still in the SES sandbox, where only verified individual addresses can send or receive.
The admin UI’s Email Identities page and the Setup wizard’s sandbox step both use this
service.
Audit log
Section titled “Audit log”AuditService.ListAuditLogs returns every admin mutation with actor identity (user, service, system,
or a vendor support engineer operating under a time-boxed support case — ACTOR_TYPE_VENDOR),
field-level before/after changes, and success/failure status. ListActors and ListOperations back
the admin UI’s filter dropdowns on the Audit Logs page. Filtering by operation prefix (e.g.
"domains") or by actor is efficient (indexed); combining both filters falls back to client-side
filtering on top of the operation index, per the proto’s own comments.
Related topics
Section titled “Related topics”- Bounce & Complaint Handling — how suppression state in this page’s Suppressions section gets set in the first place.
- Admin API reference — full request/response detail for every RPC named above.