System mail accounts

Overview
This is where what the system sends mail with is defined — one sending account per brand. The mail templates govern the content; this page governs the route out.
Affected is everything the system produces itself: invitations, portal mail, quotes, orders, notifications. Two exceptions take their own route: tickets still send through their support mailboxes, and marketing dispatch has its own path.
Core tasks
Create an account. New account requires a label and a type. SMTP and Gmail are available.
Designate a global default. Exactly one account should be marked as the default. It is the safety net: if a brand has no account of its own, the global default takes over. Without a marked default there is no sending route for such brands — and therefore no mail.
Check what exists. The list shows label, type, connection and status. No password is a warning worth taking seriously, not a cosmetic blemish.
Choose the bounce mailbox. Below the list, the section Bounce mailbox decides where undeliverable notices go. Every outgoing mail carries a technical return address for this (Return-Path, also called envelope sender) — separate from the visible sender and the reply address, which both stay unchanged. Only support mailboxes the system actively fetches can be chosen: there it recognises bounces, matches them to the original message and marks it as undeliverable instead of turning it into a ticket. For all brands applies to every brand without its own choice; each brand can get its own mailbox (mailboxes of the brand or cross-brand ones). Without a choice, bounces go to the sender address as before — with a personal or unattended sender nobody reads them. If the chosen mailbox is deactivated, the brand falls back to For all brands, otherwise to the sender.
Mind SPF and DMARC. The return address is the address receiving servers check with SPF: the sending server must be authorised for its domain. DMARC additionally requires that either this domain (SPF) or the signature (DKIM) matches the domain of the visible sender. The easiest way is a bounce mailbox in the same domain as the brand's sender address; if it is in another domain, the mail must be DKIM-signed for the sender domain. The SMTP server of the sending account must also accept such a return address. With a Gmail account Google sets the envelope sender to the account itself — the setting has no effect there.
Fields in detail
This account sends what the system writes: invitations, notifications, documents, dunning letters. It is neither your personal mailbox nor a support mailbox.
| Field | Required | Values / format | What it does |
|---|---|---|---|
Type type | yes | Gmail or SMTP | How sending works. With Gmail access runs through the prepared connection, with SMTP through server and credentials. |
Label label | yes | text | What the account is called in the list. |
Sender address fromEmail | yes | address | What appears as the sender. It must match a domain you are allowed to send for — otherwise the mail lands in spam or is rejected, regardless of whether sending technically works. |
Sender name fromName | no | text | The plain name in front of the address. |
Reply-to replyTo | no | address | Where replies go. Sensible when the sender is an unattended account — the reply then lands where somebody reads. |
Connection integrationId | with Gmail | a prepared connection | Which login sends. |
SMTP server / port / encryption smtpHost, smtpPort, smtpEncryption | with SMTP | address, number, SSL/TLS/none | What sending goes through. |
Username smtpUsername / Password password | with SMTP | text | The credentials. Stored encrypted and never shown again. |
Brand brandId | no | one of your brands | Which brand this account sends for. That way each brand writes under its own address. |
Default isDefault | no | yes/no | Which account is used when none is set up for the brand. |
Active active | no | yes/no | Whether the account is used. If no active account is reachable, mail stays in the queue — visible, not lost. |
Section Bounce mailbox:
| Field | Required | Values / format | What it does |
|---|---|---|---|
For all brands defaultAddress | no | fetched support mailbox | Return address of every brand without its own choice. Empty = off, bounces go to the sender. Only changeable with the permission for all brands. |
Per brand brands | no | fetched mailbox of the brand or cross-brand | The brand's own return address. Empty = like For all brands. |
Settings & permissions
- No route permission of its own. The page is reachable; changing is checked by the server.
- A server setting arms the routing. The per-brand assignment only takes effect once
MAILER_DSN=brand-routing://default is set on the server. If it is not, nothing here changes the actual dispatch — that setting belongs with your administrator.
- There is deliberately no direct dispatch through the server. Without a matching account,
nothing goes out. That is intentional: silent dispatch over an unknown route would be worse than a missing mail, because nobody notices it.
- Credentials are credentials. Treat them accordingly; the list does not show them in clear text.
- Bounce mailbox needs the permission
platform.system_mail_account.manage; whoever holds it only
for some brands sees and changes only those brands, For all brands only with the permission for all. It applies to everything leaving through this sending route; ticket replies (own support mailbox), marketing dispatch (own bounce handling) and personal mailboxes stay untouched.
FAQ & troubleshooting
No mail goes out at all. Check in this order: is there an active account? Is one marked as the global default? Is the server setting for brand routing in place?
Only one brand fails to send. Then both its own account and the global default are missing. Either one is enough.
Undeliverable notices show up nowhere. Check the section Bounce mailbox: without a choice they go to the sender address. If there is nothing to choose, the system does not fetch any support mailbox yet.
Mail arrives, but from the wrong sender. Then the global default is taking over, because no dedicated account is set for that brand.
Ticket replies do not go through this account. Correct — tickets use their support mailboxes. That is intended, so that replies land in the right thread.