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.
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. |
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.
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.
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.