---
title: "Emails"
description: "Email adapters, notification emails and custom email templates."
requested_language: nl
language: en
translation_notice: "This page isn't translated yet"
url: https://docs.systhema.app/nl/next/payload/forms/emails
version: unreleased (main)
docs_index: https://docs.systhema.app/nl/next/llms.txt
---
> This page isn't translated yet. Showing English.


When the project configures `emails:` in plugin options **and** wires an email adapter (e.g. `@payloadcms/email-resend`) into the Payload config, `@systhemaui/payload` registers an **Emails** tab inside the `general-settings` global. The tab carries four editor-facing fields:

| Field              | Type   | Purpose                                                                            |
| ------------------ | ------ | ---------------------------------------------------------------------------------- |
| `emailFromName`    | text   | The sender name shown in the recipient's inbox.                                    |
| `emailFromAddress` | text   | The email address emails are sent from. Must be verified with your email provider. |
| `replyTo`          | text   | Address for replies. Falls back to `emailFromAddress` if not set.                  |
| `logo`             | upload | Image displayed at the top of the Systhema-branded email template.                 |

Resolution order for outgoing email defaults is **per-form override → general-settings.emails → plugin `emails:` option → adapter defaults / env**. At runtime, Systhema wraps `payload.sendEmail` so every outgoing message (system + custom) picks up the global settings and the branded template; no per-call configuration is needed.

If neither `emails:` is set nor an email adapter is configured, the tab is not registered, no `general-settings.emails.*` columns are created, and `payload.sendEmail` keeps the adapter's default behavior untouched.

**The per-form notification emails are a separate thing from the `emails:` templates module.** A form's own **Emails** array — the recipients, subject and body a form sends on submission — appears on the Forms collection whenever the Payload config has an **email adapter**, with or without `emails:`. The templates module only adds the General Settings defaults on top. Without it, a form's notifications resolve from the form's own values and then the adapter's `defaultFromAddress`/`defaultFromName`; nothing queries General Settings. The array is only removed when there is no adapter at all, since there would then be no way to send.

## Upgrading from the standalone Emails global

Projects upgraded from a version that shipped the old standalone `Emails` global get their existing data copied into the new tab automatically as part of `systhema upgrade` — the CLI runs `pnpm payload migrate-emails-to-general-settings` (a Payload bin script registered by `@systhemaui/payload`) right after `pnpm install`. The script is idempotent: it no-ops if there's nothing in the old `emails` table/collection, and re-running after success reports "already migrated" without overwriting. Pass `--force` to overwrite the new tab from the old data. The old `emails` DB table/collection is left in place after migration — drop it manually with a SQL `DROP TABLE` (Postgres) or `db.emails.drop()` (Mongo) if you want a clean schema. Custom roles defined in non-`.ts`/`.tsx` files (JSON, YAML, DB rows) that reference `global.emails.read` or `global.emails.update` are NOT touched by the auto-codemod — sweep them manually.

## Access

Capability for editor access: `global.general-settings.emails.update`. See [Access control → Built-in roles](https://docs.systhema.app/nl/next/payload/access-control.md#built-in-roles) above for how to grant it to a custom role.