# Email

Seclai agents can both **receive** email (an agent becomes a virtual inbox) and
**send** it (replies and notifications). This page covers the account‑level email
configuration that shapes all of that: your branded sender identity, custom and
vanity sending domains, DMARC monitoring, recipient opt‑outs, the blocked‑senders
list, the inbound rate limits and quotas, and the email‑specific alerts.

For turning an individual agent into an inbox — addresses, allowlists, metadata,
replying to the sender, and multi‑turn conversations — see
[Email Received triggers](https://seclai.com/docs/agent-triggers#email-received). This page is the
home for the settings that apply **across every email‑enabled agent on the
account**.

## The Email settings page

Account email settings live under **Settings → Email**, organized into four tabs
(deep‑linkable — the active tab is in the URL):

| Tab                 | What it controls                                                                                      |
| ------------------- | ----------------------------------------------------------------------------------------------------- |
| **Branding**        | The sender display name, logo, brand color, and footer on outbound agent email (and white‑label).     |
| **Domains**         | Vanity (`<slug>.seclai.com`) and custom (`agent.mycompany.com`) sending domains, verification, DMARC. |
| **Opt‑outs**        | Recipients who unsubscribed from your agents' email; review and opt them back in.                     |
| **Blocked senders** | Inbound senders whose mail is rejected before a run — manual and automatic.                           |

Managing these settings requires an account **owner or administrator**.

## Who agents can email

By design, Seclai **does not let agents initiate email to arbitrary external
recipients**. You can't type a free‑form "To" address into a **Send Email** step.
This is deliberate — it prevents Seclai from being used to send unsolicited mail
and protects the reputation of your sending domains. There are exactly two ways an
agent sends email:

- **Reply to an inbound sender** — an [Email Received](https://seclai.com/docs/agent-triggers#email-received)
  agent can reply to whoever emailed it, **including external addresses**, using
  the Send Email step's [**Reply to original sender**](https://seclai.com/docs/agent-triggers#email-reply-to-sender)
  (`reply_to_sender`) option. This is allowed because emailing the agent is treated
  as **voluntary opt‑in to receive a reply** — the recipient started the
  conversation. The reply target is resolved at run time from the message's
  [SPF/DMARC‑authenticated](https://seclai.com/docs/glossary#sender-authentication) sender (a spoofed
  or unauthenticated sender gets no reply), so it can never be pointed at an
  arbitrary third party.
- **Notify a Seclai user in your organization** — every other Send Email step
  (any non‑email‑triggered agent, or an email agent notifying a teammate rather
  than replying) can only send to a **registered Seclai user within the account's
  organization**, chosen by user — never a free‑form address. On a personal
  account the recipient defaults to the account owner; on an organization account
  you pick from the organization's members. A recipient that isn't a user in the
  account is rejected.

So an agent can hold a back‑and‑forth with an external correspondent who wrote in
first, and can notify your own team — but it cannot be used to cold‑email people
who never contacted you.

## Branding your agent email

By default, outbound agent email is sent from a Seclai address with Seclai
branding. On a qualifying plan you can co‑brand it as your own. Branding applies
only to **agent** email (replies and notifications your agents send) — Seclai's
own system mail (billing, security, account notices) always keeps Seclai
branding.

On the **Branding** tab you can set:

- **Sender display name** — the friendly name recipients see (e.g. `Acme Support`).
  This changes only the display name; the underlying address stays a verified
  Seclai address unless you also add a [custom domain](#domains). Control
  characters and quotes are stripped to prevent header injection.
- **Logo** — a PNG, JPEG, GIF, or WebP image, up to **1 MB** and **16–2000 px**
  per side. It's embedded directly into the email (no external hosting), so it
  renders even in clients that block remote images.
- **Brand color** — an accent/link color (hex, e.g. `#581c87`).
- **Footer text** — replaces the default footer copy.
- **Remove all Seclai branding (white‑label)** — drops the "Powered by Seclai"
  footer line entirely. Available only on the white‑label plan.

A live **Preview** panel shows how a message will look as you edit.

### Plan availability

| Plan         | Co‑branding (display name, logo, color, footer) | White‑label (remove all Seclai branding) |
| ------------ | :---------------------------------------------: | :--------------------------------------: |
| **Personal** |                        —                        |                    —                     |
| **Starter**  |                        —                        |                    —                     |
| **Team**     |                        ✓                        |                    —                     |
| **Pro**      |                        ✓                        |                    ✓                     |

Co‑branding keeps a small "Powered by Seclai" footer line; white‑label removes
it. If your plan doesn't support a feature, the tab shows an upgrade prompt naming
the qualifying plans. The white‑label toggle only takes effect on a plan that
supports it, even if it was set earlier.

## Sending domains

A branded **display name** still sends from a Seclai address. To send from your
own domain — and to receive mail at your own domain — add a sending domain on the
**Domains** tab. There are three shapes:

- **Vanity** — a subdomain of Seclai, e.g. `support.seclai.com`. DNS lives in
  Seclai's zone, so it's **auto‑provisioned and verified** with nothing for you to
  configure.
- **Custom, Seclai‑managed (delegated)** — your own domain, e.g.
  `agent.mycompany.com`, where you delegate the subdomain to a dedicated Route 53
  zone Seclai manages. You add **one NS record**; Seclai does the rest.
- **Custom, self‑managed** — your own domain where **you** publish the full DNS
  record set and keep DMARC reporting under your control.

### Plan availability

Domains reuse the branding entitlements:

| Domain type                        | Requires    | Plans     |
| ---------------------------------- | ----------- | --------- |
| **Vanity** (`<slug>.seclai.com`)   | Co‑branding | Team, Pro |
| **Custom** (`agent.mycompany.com`) | White‑label | Pro       |

A Team account can therefore use a vanity subdomain but not a fully custom
domain. You can configure one domain of each kind — so up to one vanity subdomain
and one custom domain.

### Adding and verifying a domain

1. **Vanity:** enter a subdomain under **Vanity subdomain**, click **Add**, and
   it verifies automatically within a few minutes.
2. **Custom:** under **Custom domain**, choose **Let Seclai manage DNS
   (recommended)** (delegated) or **I'll add the records myself** (self‑managed),
   enter your domain, and click **Add**.
3. Seclai shows the DNS records to publish. Use **Copy all** or **Copy as zone
   file** to hand them to your DNS provider:
   - **Delegated custom:** a single **NS delegation** record for the subdomain.
   - **Self‑managed custom:** the full set — an inbound
     [**MX**](https://seclai.com/docs/glossary#mx-record) record, up to three
     [**DKIM**](https://seclai.com/docs/glossary#dkim) CNAMEs, a **MAIL‑FROM** MX and
     [**SPF**](https://seclai.com/docs/glossary#spf) TXT, a [**DMARC**](https://seclai.com/docs/glossary#dmarc) TXT,
     and an **ownership** TXT (`_seclai-challenge.<domain>`).
4. Click **Check now** to re‑verify. Status moves through **Pending DNS →
   Verifying → Verified** (or **Failed**, which auto‑recovers once the records are
   correct). Verification runs automatically every few minutes too.

The ownership TXT is required for **self‑managed custom** domains because Seclai
shares one DKIM identity per domain — the challenge record proves your account
controls the domain. Vanity and delegated domains are already account‑bound by
their zone, so they don't need it.

**DMARC policy:** for domains whose zone Seclai controls (vanity and delegated
custom) the published DMARC policy is `p=reject`; for self‑managed custom domains
it's `p=quarantine`.

**Rate limits:** adding domains is limited to **10 per account per hour**, and
verification/test‑email checks to **30 per account per hour**.

### Choosing the primary domain

Once a domain is **Verified**, use **Make primary** to send agent email from it.
**Use shared domain** reverts to the shared `agent.seclai.com` address while
keeping the domain configured. **Send test email** delivers a sample from the
domain to the account owner. If you downgrade to a plan that no longer supports
the domain type, Seclai automatically reverts the primary to the shared domain
but keeps your domain rows so you can re‑promote them after upgrading.

### Email authentication (DMARC monitoring)

For verified domains whose zone Seclai controls (vanity and delegated custom),
Seclai automatically monitors **DMARC** — the standard that tells receiving mail
servers to reject anyone spoofing your domain. Mailbox providers send aggregate
reports over the following days, so the panel fills in within roughly 24–72 hours
of a domain going live.

Each domain card shows an **Email authentication** panel and a header health
badge:

- A **DMARC** badge showing the percentage of mail passing authentication over
  the last 30 days. Green ≥ 98% with no failing messages, yellow ≥ 90%, red below,
  and gray **"awaiting reports"** before any data arrives.
- A pass‑rate bar (passed vs. failed), the report count, and a **Top sources
  failing authentication** table (source IP, the "from" domain, and failed
  message count).

If Seclai sees a meaningful volume of failing mail that uses your domain, it
emails the account owner. If a failing source is a sender you legitimately use (a
newsletter tool, CRM, or help desk that sends "from" your domain), fix its
SPF/DKIM setup before your policy starts rejecting it; otherwise the failures are
spoofing attempts your policy is already blocking, and no action is needed.

(Self‑managed custom domains don't get a DMARC summary — their reporting stays
under your own control.)

### Removing a delegated domain

When you remove a Seclai‑managed (delegated) custom domain, Seclai deletes the
Route 53 zone it created. The **NS delegation** record you added at your own
registrar is on **your** DNS, so you must delete it yourself. **Recommended
order:** delete the registrar NS record for the subdomain first, then remove the
domain in Seclai. Leaving the NS record after the zone is gone is a _dangling
delegation_ (a subdomain‑takeover risk), so don't skip it.

## Recipient opt‑outs

Every outbound agent email carries an **unsubscribe link** in its footer (and a
one‑click list‑unsubscribe header for mail clients). When a recipient uses it,
Seclai records an opt‑out and stops sending them agent email — no agent has to
handle this.

Opt‑outs have two scopes:

- **Per‑agent** — the recipient opted out of one specific agent's email.
- **Account‑wide** — the recipient opted out of email from **all** of your
  account's agents. An account‑wide opt‑out always wins over a per‑agent one.

On the **Opt‑outs** tab, owners see each opt‑out with its **Recipient**, **Scope**
(the agent name, or an **All agents** badge for account‑wide), **Reason**, and
**Date**. Use **Opt back in** to remove an opt‑out and resume sending — do this
only when you're certain the recipient wants your mail again.

Hard [bounces](https://seclai.com/docs/glossary#bounce) and spam complaints reported by mail
providers are also scoped to an **account‑level** opt‑out (never a global block),
so one bad address on one account never affects another.

Opt‑outs are also available programmatically: REST
`/api/agents/agent-email-optouts` and the `list_agent_email_optouts` /
`remove_agent_email_optout` MCP tools.

## Blocked senders

The **blocked‑senders list** applies to every email‑receiving agent on the
account. Mail from a blocked sender is **quietly rejected before any agent runs**
— no run, no credits, no notification — and shows up only as a **Blocked sender**
rejection in the agent's Traces.

- **Block an address or a whole domain.** Choose **Address** to block one sender
  (`spammer@example.com`), or **Domain** to block every address at a domain **and
  its sub‑domains** (`example.com` also covers `mail.example.com`) — handy when a
  spammer rotates the part before the `@`.
- **Only authenticated senders are matched.** A block applies to a sender whose
  message passes SPF or DMARC (the same authentication the allowlist relies on).
  An unauthenticated "from" is forgeable, so it can't be reliably blocked — if you
  run an open inbox with **Require sender authentication** off, blocking an address
  won't stop a spoofed copy of it.

### Manual and automatic blocking

- **Manual.** Add an entry (with an optional note) on the **Blocked senders** tab,
  or remove one to unblock.
- **One click from a rejection.** Open a rejected inbound‑email trace and use
  **Block sender** or **Block domain** — no need to retype the address.
- **Automatic (governance).** With [content governance](https://seclai.com/docs/governance)
  enabled, the **Automatic blocking** control can add a sender the moment one of
  your policies `BLOCK`s their message: **Off**, **On input** (block when a policy
  blocks the incoming email), or **On input & output** (also block when a policy
  blocks a step's output). Auto‑block only ever adds an **authenticated** sender
  (an attacker can't spoof a victim's address to get them blocked).
- **Automatic (overload safeguard).** If the [inbound‑email overload
  safeguard](#alerts) auto‑pauses an agent and a single authenticated sender is
  responsible for the flood, that sender is auto‑blocked so re‑enabling the agent
  doesn't immediately re‑flood.

Automatically‑added entries are tagged **Auto** with an explanatory note; remove
one if the block was a mistake. Managing the list — including the automatic
mode — requires an account **owner or administrator**. Account deletion hard‑
deletes these rows (the addresses are personal data).

The blocked‑senders list is exposed over REST (both the authenticated
`/authenticated/agents/blocked-email-senders` and the external, API‑key/OAuth
`/api/agents/blocked-email-senders`) and over MCP — `list_blocked_email_senders`
(read‑only) plus `block_email_sender`, `unblock_email_sender`, and
`set_email_auto_block_mode`. All of them require an account **owner or
administrator** — the list read included, since the rows contain sender
addresses — and the mutating tools are blocked for agent‑originated (loopback)
MCP calls, so a prompt‑injected agent can never manage the blocklist.

## Rate limits & quotas

Inbound email is bounded at two levels: a **per‑plan hourly quota** and a
**per‑trigger hard ceiling**.

### Per‑plan hourly quota

Each account can trigger a limited number of inbound‑email agent runs per hour,
per plan:

<table>
  <thead>
    <tr>
      <th>Plan</th>
      <th style={{ textAlign: "center" }}>Inbound email triggers / hour</th>
    </tr>
  </thead>
  <tbody>
    {EMAIL_TRIGGER_LIMITS.map((limit) => (
      <tr key={limit.plan}>
        <td>
          <strong>{limit.plan}</strong>
        </td>
        <td style={{ textAlign: "center" }}>{limit.perHour}</td>
      </tr>
    ))}
  </tbody>
</table>

An account with no active plan can't run inbound‑email agents at all. The window
is a rolling hour.

**When the quota is exceeded**, the default is to turn the message into a
**failed** run so you can see it ("Inbound email rate limit exceeded…"). If you
enable **Queue over‑limit email** (`queue_on_quota`) on the trigger, over‑limit
mail is instead parked in a **Queued** run and caught up automatically as capacity
frees over the following minutes — in arrival order, one slot per plan window,
never bypassing the limit. A message with **insufficient account credits** always
fails immediately (queuing can't conjure a balance). See
[Email Received → Configuration Fields](https://seclai.com/docs/agent-triggers#email-received-fields).

### Per‑trigger hard ceiling

Above the plan quota, each email trigger has a hard flood ceiling (**500
messages/hour** by default). Mail beyond the ceiling is shed as a `flood`
rejection — a backstop against a runaway sender, independent of the plan quota.
Because credits are the real limiter, an open address that becomes known publicly
can still consume credits up to the plan quota, so set a sender allowlist when the
address might leak (see
[Security & Limits](https://seclai.com/docs/agent-triggers#email-received-security)).

## Email alerts

Two [alert](https://seclai.com/docs/alerts) types are specific to inbound email.

### Inbound email overload (mandatory)

If mail keeps arriving faster than your plan can process it and the queued backlog
grows beyond what can realistically catch up, Seclai:

1. Sends a mandatory **inbound email overload** alert to the account owner, and
2. Automatically **pauses** the worst‑affected agent to stop the backlog from
   growing (its queued mail is then not run), and
3. If a **single authenticated sender** caused the flood, adds them to your
   [blocked‑senders list](#blocked-senders) so re‑enabling the agent doesn't
   immediately re‑flood.

The block is the recovery mechanism, not a punishment: a sender flooding faster
than your plan can process creates a backlog that can **never** drain, so blocking
their inflow is what lets the account catch up. If that sender is legitimate (a
monitoring system, a forwarder, a high‑volume partner), you can unblock them — but
they were sending faster than your plan can process, so **unblocking without
upgrading your plan or reducing their volume will simply overload the agent
again**. The durable fix for a genuine high‑volume sender is a larger plan (a
higher hourly rate) or batching their mail.

Re‑enable the agent from its page once the volume subsides or your plan is
upgraded (re‑enabling is manual — there's no auto‑flapping). This safeguard is the
one alert you **can't turn off**, but you can change its **cooldown** (default
3 hours) and **recipients** on the account **Alerts** page. A paused agent shows a
**Paused** badge; see [Troubleshooting](https://seclai.com/docs/troubleshooting#agent-not-triggering).

**Account‑wide pause (last resort).** The per‑agent pause above handles a flood
concentrated on one agent or one sender. If instead a flood is spread thin across
many agents or many senders — so no single one crosses the threshold — but your
account's **total** queued backlog grows far past what your plan can process,
Seclai temporarily **pauses all new inbound email for the account** as a last
resort. While paused, incoming messages are **turned away without running an
agent** (you'll see `Account overloaded (inbound paused)` rejections in the
Traces tab) and the owner is emailed once. This is **self‑healing**: acceptance
**resumes automatically** as soon as the backlog drains — there's nothing to
re‑enable. The durable fix is the same as above: a larger plan or less inbound
volume.

### Inbound email turned away

The **Inbound Email Turned Away** alert (enable it on an agent's Alerts tab)
notifies you when legitimate mail is rejected before a run — for example a sender
your allowlist doesn't include, so you can add a correspondent you forgot. Every
turned‑away message also appears as a `rejected`‑status trace in the agent's
**Traces** tab (filter the status to **Rejected** to see only these), and via
`GET /api/agents/inbound-email-rejections` and the `list_inbound_email_rejections`
MCP tool.

## Best practices

- **Authenticate your senders.** Keep **Require sender authentication** on so only
  [SPF/DMARC‑passing](https://seclai.com/docs/glossary#sender-authentication) mail can trigger an
  agent (and so the allowlist and blocked‑senders list are meaningful). Only turn
  it off for a closed integration that genuinely can't authenticate.
- **Set an allowlist for known addresses.** If an agent's address might become
  public, add a sender allowlist so strangers can't trigger runs and consume
  credits. See [Security & Limits](https://seclai.com/docs/agent-triggers#email-received-security).
- **Brand from your own domain for external‑facing agents.** A support inbox or
  newsletter reads as more trustworthy from `agent.mycompany.com` than from a
  shared address — and a custom domain lets you monitor DMARC.
- **Watch the DMARC panel after adding a domain.** A pass rate below ~98% usually
  means a legitimate tool sends "as" your domain without proper SPF/DKIM — fix it
  before your `p=reject`/`p=quarantine` policy starts bouncing that mail.
- **Turn on queueing for bursty inboxes.** If you expect spikes (a campaign reply
  wave, a nightly batch), enable **Queue over‑limit email** so bursts catch up
  instead of failing.
- **Enable the "turned away" alert on allowlisted agents.** It surfaces legitimate
  correspondents you forgot to allow, before they give up.
- **Keep multi‑turn state keyed to the authenticated sender**, not the quoted
  reply chain — see [Email conversation
  memory](https://seclai.com/docs/agent-triggers#email-conversation-memory).
- **Honor opt‑outs.** Don't opt a recipient back in unless they asked; repeated
  mail to someone who unsubscribed drives spam complaints that hurt your domain's
  reputation.

## Common use cases

- **Branded support inbox.** A custom domain (`help@support.mycompany.com` shape)
  - a co‑branded sender + an [Email Received
    agent](https://seclai.com/docs/agent-triggers#email-support-inbox-example) that answers from a
    knowledge base and [replies to the
    sender](https://seclai.com/docs/agent-triggers#email-reply-to-sender).
- **Triage and routing.** An agent that reads incoming mail, classifies it, and
  forwards or files it — see [Email
  triage](https://seclai.com/docs/agent-triggers#email-triage-example).
- **Locked‑down internal automation.** An allowlist limited to your own domain +
  **Require sender authentication** on, so only staff can drive the agent.
- **High‑volume intake with catch‑up.** A public intake address with **Queue
  over‑limit email** on, so campaign spikes are processed in order without losing
  messages, and the overload safeguard protects you if a sender floods it.
- **White‑labeled client‑facing agents.** On the Pro plan, remove all Seclai
  branding and send entirely from the client's domain.

## Related

- [Email Received triggers](https://seclai.com/docs/agent-triggers#email-received) — turn an agent
  into an inbox (addresses, allowlists, metadata, reply‑to‑sender, conversations).
- [Alerts](https://seclai.com/docs/alerts) — configure alert delivery, scopes, and recipients.
- [Governance](https://seclai.com/docs/governance) — policy‑based screening that can auto‑block
  senders.
- [Credits & Usage](https://seclai.com/docs/credits-usage) — how agent runs (including email‑
  triggered ones) consume credits.