Application Email

Your apps can send their transactional email (sign-up verification, password resets, invites, notifications) through Kuploy — with no SMTP server, API keys, or DNS to configure. You turn it on by adding a Transactional Email service to the app.

note

Available on Kuploy Cloud (licensed) instances, on every plan. Self-hosted deployments continue to use the app's own email settings.

Adding it to an app

1. Open the project environment your app lives in.
2. Choose Create Service → Transactional Email.
3. Pick the application that sends the mail.
4. Confirm the env var prefix — the names your app already reads for its mail settings. Kuploy suggests one from the app's name; for the LearnHouse template, use LEARNHOUSE.
5. Save. Kuploy writes the variables into the app and redeploys it so they take effect.

Your app needs to know how to use them — it must support sending via Kuploy's relay. The LearnHouse template does out of the box; for your own app, read the endpoint and token from those variables and POST your messages to the endpoint with the token as a bearer credential.

The service page also shows the endpoint and the token itself — the token stays hidden until you reveal it — so you can copy either without going through the app's environment settings.

tip

Apps that were already sending mail through Kuploy before this became a service were carried over automatically — they keep working, and now appear as a Transactional Email service you can inspect or remove.

How it works

Kuploy hands the app an endpoint of its own and a token scoped to that one app, then relays each message on the app's behalf.

• No credentials in your app. Your app never holds a shared mail account or license key. It hands each message to Kuploy, which sends it on your behalf.
• Branded from your app's own domain. Mail is sent from no-reply@ at the domain your app is reached on. If that's a Kuploy-managed .kuploy.app address it's verified automatically (no DNS for you to set up); if it's your own custom domain, it becomes branded once that domain is verified. Until then, messages still go out from a default Kuploy address, so nothing is ever dropped waiting on setup.
• Survives redeploys. The wiring persists across redeploys — you don't need to reconfigure anything.

The name recipients see

Mail is addressed from no-reply@ at your app's domain, with a display name beside it — for most recipients, the part they actually read.

It defaults to the application's name, which is often an infrastructure name (app, learnhouse-app) rather than something your users would recognise. Set it on the service page under Sender → From name: use whatever your recipients should see, such as your product's name.

Two things worth knowing:

• It applies to the next message sent — unlike the variable names, changing it does not redeploy your app.
• Leave it empty and Kuploy falls back to the application's name, and then to your organization's name. That fallback is why an unset name can show up as your billing entity rather than your product.

Verifying it's active

After the app has deployed, send yourself a test from the app (for example a password-reset email). If you received it, the path works. The sender address tells you which stage you're at:

Sender you see	Meaning
no-reply@ at your app's domain	Branded sender verified — fully set up
A default Kuploy address	Working; branded sender still verifying

Check the display name next to the address at the same time — that is the quickest way to spot a From name you have not set yet.

Using your own provider instead

If you'd rather send from your own domain or provider, set the app's own email configuration (e.g. SMTP or Resend) in its environment. An explicit provider configured on the app takes precedence, so you keep full control when you want it.

To stop sending through Kuploy entirely, open the Transactional Email service and delete it — the variables are removed from the app and it redeploys without them.

If the token leaks

The token lets anything holding it send mail as your organization, so treat it like a password. If it ends up somewhere it shouldn't — a screenshot, a shared terminal, a pasted log — open the service and choose Rotate.

Rotating invalidates the old token immediately and redeploys the app with a new one. The app can't send in between, usually a minute or two. Services created before rotation existed show a prompt to rotate once: their original token can't be displayed or revoked, and rotating replaces it with one that can be.

To confirm the new token is live, send a test message — that is the only check that distinguishes "the app has a token" from "the app has a token that still works". A health or status flag in your own app usually reports whether the variable is set, which stays true while a revoked token is in place, so it cannot tell you the redeploy landed.

Open tracking

Messages sent through Kuploy are relayed by our email provider, which adds an open-tracking pixel and a List-Unsubscribe header to outgoing mail, and delivers them as HTML. This happens at the provider, not in your app, and it cannot currently be switched off for an individual message or an individual app.

This matters if your own privacy policy promises no third-party tracking: as things stand, that promise and this service are in conflict, and you should either adjust the policy or send through your own provider instead (see above). We would rather tell you here than have you find it in a message header.

Troubleshooting

• No email arrives: confirm the app finished deploying, then re-send. If you recently changed the app's email settings, redeploy so they take effect.
• The app doesn't see the variables: they're written to the app's environment, which a running container only picks up on deploy. Creating or editing the service redeploys for you; if you cancelled that, redeploy the app.
• Wrong variable names: the names must match what your app reads. Open the service and correct them — saving rewrites the app's environment and redeploys it.
• Sender never becomes branded: a Kuploy-managed .kuploy.app address verifies on its own. A custom domain becomes branded only after that domain is verified — finish its verification in the app's domain settings. Mail keeps delivering from the default sender in the meantime.

Related

• Platform email (operators): see SMTP Setup for configuring the platform's own delivery and managed vs. bring-your-own mode.
• Custom mailboxes: see Email & Mailboxes to host full inboxes (IMAP) on your own domain.