Operating Modes | Owlat Docs

The different ways to run Owlat at a company — read external mailboxes over IMAP, send transactional or marketing email through a delivery provider, host your own mail server, or run a team inbox with AI — and the rules that keep each combination coherent.

Owlat is modular: every product surface is a feature flag, and you turn on only the ones you need. This page catalogs the common operating modes — coherent combinations of those flags plus the infrastructure each one requires — so you can pick the shape that fits your company and skip the rest.

The setup wizard's first step ("How will you run Owlat?") offers these as one-click presets. You can always fine-tune the individual flags afterwards from Settings → Features.

The three axes

Every mode is a point along three axes:

Receiving — where mail comes in. None, an external mailbox over IMAP (mail.external — read Gmail / Fastmail / a company server), a hosted Postbox (postbox — Owlat is your mail server, MX-based), or a shared team inbox (inbox).
Sending — how mail goes out. Nothing, 1:1 replies through your own SMTP (the external-mailbox path), or a delivery provider (the built-in MTA, Resend, or Amazon SES) for programmatic and bulk mail.
Message type — what you send. Transactional (transactional — receipts, password resets, API sends) and marketing (campaigns + automations — broadcasts, drip series).

The rule that keeps modes coherent

Bulk sending needs a delivery provider — an IMAP mailbox is not one

Campaigns, transactional, and automations send through a delivery provider (MTA, Resend, or SES) with a verified, authenticated sending domain. You cannot send them with IMAP-only: a connected external mailbox sends personal 1:1 replies through your own provider's SMTP, never bulk mail.

Owlat enforces this. The setup wizard requires a provider when any of those flags is on, and the backend refuses such sends (no rows are written) until one is configured.

A second, quieter rule: system and auth email (password reset, team invitations, double opt-in) also needs a transport. It goes through whichever delivery provider you configure. A deployment that configures no provider can read mail and reply 1:1, but cannot send password resets or invitations — so it only suits a single admin set up at install or an external identity provider.

Choose your mode

If you want to…	Mode	Delivery provider?
Read your existing Google/IMAP mail in a better client	IMAP-only	No
Send receipts / password resets from your app	Transactional API	Yes
Run newsletters, forms, and drip campaigns	Marketing platform	Yes
Run Owlat as your company mail server	Hosted mail server	Yes (MTA)
Triage shared support mail as a team	Team inbox	Yes
…with AI classification + draft replies	Team inbox + AI	Yes
Everything at once	Full stack	Yes
Just manage contacts/data, no mail	CRM-only	No

The mode matrix

Always-on built-ins (no flag): the Convex backend, Redis, and the automations runtime. "Flags on" lists only what you enable beyond the defaults. Provider is the email delivery provider; profiles are the Docker Compose profiles that activate.

Mode	Flags on	Provider	Docker profiles	What works
IMAP-only	`mail.external`	none	`external-mail`	Read external mailboxes, search, CRM/timeline, reply 1:1 via your own SMTP
Transactional API	`transactional`	required	`mta` if provider = MTA	Programmatic sends via the API/SDK; verified domain required
Marketing platform	`campaigns` (+ `.archive`), `automations`, `transactional`	required	`mta` if provider = MTA	Campaigns, drip/broadcast automations, forms → double opt-in, transactional
Hosted mail server	`postbox`	MTA + verified domain	`personal-mail`, `mta`	Per-user mailboxes, webmail + IMAP/SMTP clients, MX delivery
Team inbox	`inbox`, `transactional`	required	`mta`	Shared inbox, threaded conversations, replies via provider
Team inbox + AI	`inbox`, `ai`, `ai.agent`	required	`mta`, `ai`	+ AI classification & draft replies (needs an LLM provider)
Full stack	marketing + receiving + AI	required	`personal-mail`, `external-mail`, `mta`, `ai`	everything
CRM-only	none of the sending flags	none	—	Contacts, segments, imports, forms; no send

IMAP-only, in detail

Owlat as a better client on top of Google

Enable mail.external and each user connects their own mailbox over IMAP+SMTP. Owlat syncs their mail (including a full-history backfill — see Migrate from Google), indexes it for search and AI, and lets them reply 1:1 through their own provider's SMTP.

No delivery provider, no sending domain, and no MTA container are required. What you cannot do in this mode: send marketing campaigns, automations, or transactional API mail — those need a delivery provider. Connecting an external mailbox does not give you one.

How to run each mode

Self-hosters pick a mode in the setup wizard, or set the flags in Settings → Features. The built-in MTA is now opt-in: it runs only when it is the delivery provider (EMAIL_PROVIDER=mta) or when postbox/inbox need it for inbound mail. The default .env.selfhost.example ships COMPOSE_PROFILES=mta; switch EMAIL_PROVIDER to resend/ses and drop mta from COMPOSE_PROFILES to stop running it. See Self-hosting configuration.
Delivery providers (MTA vs Resend vs SES) and how routing picks one are covered in Providers.
Sending domains (SPF/DKIM/DMARC) are only required when you send through the built-in MTA — see DNS & email.

Invalid combinations Owlat prevents

Combination	Why it's incoherent	What Owlat does
Campaigns / transactional / automations on, no delivery provider	Bulk mail has no transport	Blocked: wizard requires a provider; sends are refused (no rows written)
Treating an external mailbox as a bulk sender	It's personal 1:1 SMTP, never bulk	The capability check never counts `mail.external` as a provider
`inbox` on with no inbound source	The inbox stays empty	Warned — add the MTA or a channel webhook
`postbox` on with an unverified domain	No MX in, no DKIM out	Warned + the per-domain send gate blocks until verified