# Email (/en/docs/platform/features/alerting/channels/email)



An email channel sends each alert to a list of 1 to 10 addresses. It is the only channel type with no platform-side setup; the constraint is on who can receive.

## Prerequisites [#prerequisites]

* The website **Manager** role in CentralCSP.
* Every recipient must be a workspace member with access to the website. An outside address is rejected when you save.

## 1. Add the channel [#1-add-the-channel]

1. In the dashboard, go to **Alerts** > **Configuration** > **Add channel**.
2. Name the channel and choose the **Email** type.
3. Enter the recipient addresses, comma separated, up to 10.
4. Save.

## 2. Test the channel [#2-test-the-channel]

Select **Test** on the new channel. A sample alert built from a fake CSP violation is sent immediately. If it lands in spam, have recipients mark it as not spam before wiring real rules to the channel.

## How recipients are resolved [#how-recipients-are-resolved]

Recipients are stored as workspace members, not as address strings, and resolved when each alert is sent. Two consequences worth planning around:

* A member who changes their email address keeps receiving alerts at the new one.
* A member who loses access to the website is silently dropped from the list. If nobody is left, the delivery fails.

For a distribution list, a shared inbox, or an on-call alias, email is the wrong type: use a [Webhook](/en/docs/platform/features/alerting/channels/webhook) channel or a chat destination such as [Slack](/en/docs/platform/features/alerting/channels/slack) instead.

## Next steps [#next-steps]

* [Create a rule](/en/docs/platform/features/alerting/rules) that delivers to this channel.
* [Channels overview](/en/docs/platform/features/alerting/channels) for auto-disable behaviour and limits.
* [Delivery history](/en/docs/platform/features/alerting/deliveries) to audit what was sent.