> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tallwatch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Email

> Send Tallwatch alerts to one or more addresses. The simplest channel, and the one every workspace ships with.

Email is Tallwatch's default channel. Every workspace ships with an auto-created one called [Default Alerts](/alerts/default-alerts), seeded with the creator's address. You can add more email channels whenever you like, with up to 50 recipients each. Delivery runs through [Resend](https://resend.com).

Before you rely on email in production, verify a sending domain (covered below). Until then, the sandbox sender only reaches your own address.

## 1. Add the channel

<Steps>
  <Step title="Open the channels page">
    Go to **Settings → Alerts → Channels** and click **Add channel**.
  </Step>

  <Step title="Pick Email">
    Choose the Email kind and name it for the audience, like `Billing stakeholders` or `Infra on-call`.
  </Step>

  <Step title="Add recipients">
    The recipient field takes one address per chip. Type an address, press **Enter** or comma, and it becomes a chip. Up to 50 per channel. Click the × to remove one, or hit **Backspace** in an empty field to drop the last.
  </Step>

  <Step title="Save and test">
    Click **Save**, then **Send test alert**. Every recipient should get the test within a few seconds.
  </Step>
</Steps>

<Info>
  The whole list goes out in one Resend call with every address in the `to` field, so recipients can see each other. If you need stealth delivery to certain people, put them on a separate channel.
</Info>

## What the alert looks like

A transactional HTML email:

* The monitor name and incident status in the subject and heading
* A summary with the failing regions, when it started, the last status code, latency, and error, and the monitor URL
* **View incident** and **Acknowledge** buttons linking to the incident
* A `List-Unsubscribe` header (RFC 8058) so inboxes can offer one-click unsubscribe

A plain-text fallback is generated for clients that don't render HTML.

## Custom sending domain

By default, alerts come from `onboarding@resend.dev`, Resend's sandbox sender. The sandbox can only deliver to the address that owns your Resend account, so set up a real domain before production.

<Steps>
  <Step title="Verify a domain in Resend">
    Add your sending domain (for example `tallwatch.yourcompany.com`) in the Resend dashboard, then add the SPF, DKIM, and DMARC records it gives you to your DNS.
  </Step>

  <Step title="Set the from address">
    In **Settings → Email**, set **From address** to something like `Alerts <alerts@tallwatch.yourcompany.com>`. The `Name <addr>` form renders a friendly sender name.
  </Step>

  <Step title="Confirm">
    Send another test. Resend's dashboard shows the delivery result, and the new sender should appear in the inbox.
  </Step>
</Steps>

<Warning>
  Until your domain is verified, alerts to anyone other than the Resend account owner fail silently. Resend marks them bounced in its dashboard, but the failure is opaque from Tallwatch. Verify a domain before trusting email for production alerts.
</Warning>

## Troubleshooting

<AccordionGroup>
  <Accordion title="The test dispatched, but no email arrived">
    Check the Resend dashboard for the send. Usual causes:

    * You're still on the sandbox sender and the recipient isn't your Resend account owner. Verify a domain (above).
    * The inbox flagged it as spam. Check the spam folder, and set up SPF, DKIM, and DMARC on your domain to improve deliverability.
    * A recipient address has a typo. Open the channel and confirm each chip.
  </Accordion>

  <Accordion title="Some recipients get it, others don't">
    Usually a per-recipient bounce: a misspelled address, a closed mailbox, or a corporate filter. Resend's dashboard shows per-recipient state. Remove dead addresses from the channel.
  </Accordion>

  <Accordion title="Someone clicked unsubscribe and now gets nothing">
    Resend honors the unsubscribe through its account-wide suppression list, which blocks every email to that address, including alerts. To undo it, the recipient opts back in or you remove the suppression in Resend.
  </Accordion>

  <Accordion title="Should I make one channel per recipient?">
    Rarely. One channel with 50 chips is a single Resend call; 50 single-chip channels are 50 calls and 50 rows to manage. Split only when recipients need different escalation routing.
  </Accordion>
</AccordionGroup>

## Reference

| Property        | Value                                                                         |
| --------------- | ----------------------------------------------------------------------------- |
| Channel kind    | `email`                                                                       |
| Required config | `to` (1 to 50 addresses)                                                      |
| Sending domain  | `onboarding@resend.dev` by default; verify your own per workspace             |
| Delivery        | Immediate, no proactive rate limit                                            |
| Retry           | Up to 3 inline attempts on a Resend 5xx, 429, or network error, then `failed` |
| Outbound to     | Resend API                                                                    |
