Delivery · 20 / 23
Outgoing mail
Invitations and password-reset links sent by the CMS itself, queued in the same transaction that issued them.
Until they accept the invite, they appear in the members list as “Invited” and can’t sign in. You can resend or revoke the invite anytime.
Their account exists but is dormant until they accept. The invitation is on its way to sofia@newsroom.example; there is no link to copy.
What happens when they open it
- They land on a page that already knows their name and email — the only thing they choose is a password.
- Their account activates with the Contributor role and the workspace access you picked.
- They’re signed in immediately, and the link stops working.
Hello Sofia Lindqvist,
Mara Lind has invited you to Ortha CMS.
Follow the link below to accept the invitation and choose a password.
https://cms.newsroom.example/invite/…
The link expires on Oct 5, 2026 (UTC).
If you were not expecting this invitation you can ignore this message.
How it works
- 01
Point the mail plugin at an SMTP relay.
- 02
An invite or reset is queued with the change that created it.
- 03
Without a mail backend configured, the admin shows a one-time link instead.
- Backends
- SMTP, or console for development
- Messages
- Invite, resent invite, password reset, password recovery
- Retries
- 5 attempts over about 20 minutes
In depth · For whoever runs the installation
Invitations that send themselves
Point the CMS at a mail relay and invitations, resends and reset links go out by email instead of through an administrator’s clipboard.
What changes when you configure a relay
Relayed by hand
- The API returns the raw invite token
- It passes through an administrator’s clipboard and chat
- Somebody has to remember to send it
Sent
- The response carries no token at all
- The link exists in one message, deleted once sent
- The member has it seconds after the invite is saved
Queued with the change that created it
The message is rendered and queued in the same transaction that creates the token. If that rolls back, there is no member and no message. A worker sends it afterwards, and a delivered row is deleted, so the secret is not kept.
Messages
| Message | Sent when |
|---|---|
| Invitation | Somebody is invited. |
| Invitation, again | A pending invite is resent; the old link stops working. |
| Password reset | An administrator starts a reset for somebody. |
| Password recovery | Somebody uses "Forgot it?" on the sign-in page. |
Transactional only: no newsletters, no inbound mail, and templates live in your codebase.
Details
- Any SMTP relay
- Resend, SES, Postmark, SendGrid, Microsoft 365 or your own relay; credentials are checked at boot.
- Five attempts over twenty minutes
- Retried with jittered backoff; a rejected sender or bad address stops at once.
- Links from configured URL
- Never from the request’s Host header, so a link cannot be pointed elsewhere.
- Reveal once, on the record
- An administrator can reveal an undelivered link, and the activity log records it.
- Off until you turn it on
- With no backend, invite and reset routes return the link exactly as before.
Questions
Does this give people a "forgot my password" link?
Yes, once mail is configured. The form answers the same for every address, and requests are rate limited.
What happens to my scripts when I turn it on?
The invite, resend and reset routes stop returning the raw token, and the field is absent so scripts reading it fail loudly.
Will I know if a message bounces?
No. There is no bounce handling; a message the relay refused shows as a failed row, and the relay’s logs cover the rest.