Repository navigation
Email and Invitations
Three features depend on working SMTP: inviting users, self-service password reset, and emailed sign-in codes. None of them work until mail does.
Settings → Email. Fill in host, port, encryption, credentials and the from address, then use the test send. It delivers a real message and reports the provider's own error text on failure, which is almost always the fastest route to a fix.
Administrators are warned in the console while SMTP is unconfigured, because account recovery quietly depends on it — a user who forgets their password with no mail configured has no self-service path back in.
Your from address must be one the relay is permitted to send as. Most delivery failures are the relay rejecting the sender, not CortenDesk.
Microsoft and Google have been retiring basic-authentication SMTP: Exchange Online is moving tenants to OAuth or the Graph API, and Google dropped "less secure apps" some time ago. If your mail provider will no longer hand out a username and password for submission, you do not need OAuth support here — you need a different relay.
Use a transactional email provider. Amazon SES, Postmark, Resend, Mailgun and Brevo all issue ordinary SMTP credentials, and their submission endpoints are unaffected by what Microsoft and Google are doing to theirs. Paste them into Settings → Email like any other relay. Free tiers cover this comfortably: a console sends invitations, password resets and the occasional sign-in code, which is a handful of messages a week, not a mailing list.
| Provider | Host | Ports |
|---|---|---|
| Amazon SES | email-smtp.<region>.amazonaws.com |
587 STARTTLS, 465 TLS |
| Postmark | smtp.postmarkapp.com |
587 STARTTLS, 2525 |
| Resend | smtp.resend.com |
587 STARTTLS, 465 TLS |
| Mailgun | smtp.mailgun.org |
587 STARTTLS, 465 TLS |
| Brevo | smtp-relay.brevo.com |
587 STARTTLS |
The username is usually an API key or a generated SMTP credential rather than your account login — generate it in the provider's console, not from your password.
Expect to prove you own the sender. This is the step that actually catches
people out, and it is not something CortenDesk can do for you. Every one of these
providers requires you to verify a domain with DNS records (SPF and DKIM, usually
DMARC too) or at minimum verify a single sender address, before it will deliver
anything. If you were hoping to send as you@gmail.com, you will hit that wall —
you need a domain you control. Verify the domain, then set the from address in
Settings → Email to something on it.
Other options that still work:
- An app password. Gmail still issues them with 2-step verification on, as do many smaller providers. Nothing special is needed at this end.
-
A local smarthost. Run Postfix or msmtp on the host, relay through any of
the above, and point CortenDesk at
localhost:25. Useful when several applications on one box need mail and you would rather configure it once.
Invite by email instead of setting a password by hand. The recipient follows a link, chooses their own password, and lands with the account already configured.
Invitations expire after 48 hours by default. Expired and long-accepted invitations are cleaned up automatically by a scheduled job.
If you cannot send mail, create the user directly with a password instead — the invitation flow is a convenience, not the only way to add someone.
Users request a reset from the sign-in page. The link is single-use and valid for 60 minutes.
Completing a reset revokes that user's other sessions and RustDesk client tokens, so a reset cannot leave a stale session alive somewhere.
Self-service reset is unavailable when password sign-in is turned off in favour of SSO — in that case, passwords live with your identity provider.
Settings → Security → emailed sign-in verification, off by default.
With it on, signing in from a browser CortenDesk does not recognise triggers a one-time code by email, in addition to the password. The code is valid for 10 minutes.
A browser that passes is remembered for 30 days by default (trusted device days), after which it is challenged again. Expired trusted-device records are cleaned up by the same scheduled job as invitations.
The RustDesk client asks for the code too, in its own dialog, every time it signs in with a password: it has no cookie to be remembered by. If mail cannot be sent, client sign-in is refused rather than let through. Users with 2FA get the authenticator prompt instead. Since 1.14.0.
This is not a replacement for two-factor authentication. It verifies control of the mailbox, which is weaker than a TOTP app — but it is useful where enrolling everyone in TOTP is impractical.
It can be turned on and off from the command line as well, which is the way back in if mail breaks while it is required:
php artisan cortendesk:email-verification offSee the command-line reference.
Email is optional on a user account. Someone with no address cannot be invited, cannot reset their own password, and cannot receive sign-in codes — an administrator has to set their password directly.
Add addresses before turning on anything that depends on them.
Alerts do not have to go through email. System and fleet events — a device going offline, a security alarm, a device waiting for approval — can be delivered to Slack, Telegram, Discord, ntfy and the rest through a self-hosted Apprise API. That is a broadcast channel, and it suits alerts well.
Invitations, password resets and sign-in codes stay on email deliberately. Each one is addressed to one person and has to reach only that person: a reset link in a shared channel is an account takeover waiting to happen, and an invitation goes to somebody who does not have an account yet, so there is no chat identity to send it to. A working relay is required for those three, and no chat integration replaces it.