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. 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 agent can reply to whoever emailed it, including external addresses, using the Send Email step's Reply to original 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 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. 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 record, up to three DKIM CNAMEs, a MAIL‑FROM MX and SPF TXT, a 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 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 enabled, the Automatic blocking control can add a sender the moment one of your policies BLOCKs 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 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:

Plan	Inbound email triggers / hour
Personal	5
Starter	20
Team	60
Pro	200

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.

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).

Email alerts

Two alert 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 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.

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 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.
• 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.
• 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 that answers from a knowledge base and replies to the sender.
• Triage and routing. An agent that reads incoming mail, classifies it, and forwards or files it — see Email triage.
• 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 — turn an agent into an inbox (addresses, allowlists, metadata, reply‑to‑sender, conversations).
• Alerts — configure alert delivery, scopes, and recipients.
• Governance — policy‑based screening that can auto‑block senders.
• Credits & Usage — how agent runs (including email‑ triggered ones) consume credits.