Your business email

By default a project sends from its subdomain as the address: [email protected]. This rides on the platform's already-verified domain, so it needs zero provisioning and every project gets one for free. Optionally, a project can be upgraded to its own dedicated subdomain (myshop.coagentic.site), which unlocks any-local-part addresses like [email protected]. Pro and Business tiers can additionally connect a fully custom domain (myshop.com). Both paths use the same delivery pipeline; only the From address differs.

The default [email protected] sender works everywhere. If you want any-local-part addresses on your own subdomain, upgrade the project from Project → Integrations → Platform email. We register <project-subdomain>.coagentic.site with our email provider, publish DKIM, SPF, DMARC, and bounce-MX records to the parent zone via our Cloudflare integration, and verify — usually within a minute or two.

While the dedicated subdomain is “Verifying”, sends still work — they keep using the default [email protected] sender so nothing blocks. As soon as it flips to “Ready”, mail starts going from [email protected].

Any local part works on a dedicated subdomain — no mailboxes to create in advance. [email protected], [email protected], [email protected] all send the moment you reference them. The DKIM signature covers the whole subdomain.

When the agent builds a workflow with a send_email action, it auto-defaults the From address to this project's own sender — <project-subdomain>@coagentic.site by default, or noreply@<subdomain>.coagentic.site once the project has upgraded to a dedicated domain. You only set from to override it (e.g. bookings@for the booking confirmation) — and an override is honored only if it's a domain the project has verified.

Trigger: form_submit (Contact form)
Action: send_email
  # no "from" needed — defaults to [email protected]
  to:   {{email}}   # form fields are top-level
  subject: "Thanks for reaching out!"
  text:  We received your message and will reply within 24h.

The display name ("Acme Cooking") is what recipients see in their inbox; the actual address can stay on the platform subdomain.

Save a subject + body once and reuse it. Go to a project's Email → Templates tab, create a template (the same {{variables}} apply — click a chip to insert one), then pick it from the Composeform or a workflow's Send email action to fill the subject and body. The agent can manage them too (list_email_templates, create_email_template).

Pro and Business workspaces can connect their own domain — say acme.com — and send as [email protected] instead. Recipients see zero coagentic.site branding; it's your domain start to finish.

Prefer to use the mailbox you already have — a Gmail, a Microsoft 365 account, or a mailbox on your own host — instead of a coagentic.site address? Connect it per project from Project → Email → Mailbox. The project then sends through your SMTP server as your real address, and receives by us polling your IMAP — so mail to your own inbox flows into Coagentic and back out under your own name.

This is the mirror image of the platform sender above: instead of sending as [email protected] through our shared relay, a connected project sends as [email protected] through your own server. Everything downstream is identical — arriving mail lands in the same Inbox, fires the same inbound_email workflows, and is handed to the same staffing agent as platform mail. One mailbox per project.

Sending and receiving are independent — turn on either or both. Send-only: fill just the Sending (SMTP) block and the project sends as your address while still receiving on its platform inbox. Receive-only: fill just the Receiving block and the project pulls mail from your server while still sending through the platform relay. At least one side is required. Sends made through your own SMTP don't count against your platform monthly quota — it's your server and your domain's reputation.

Your mail server must be reachable at a public address — hosts that resolve to private or reserved ranges are refused, on save and on every poll. The assistant can do all of this too: get_mailbox, configure_mailbox, test_mailbox, and set_mailbox_enabled (connecting or switching a mailbox live is a founder decision, so those two never run unattended).

Inbound mail to any address on your platform subdomain lands directly in your Coagentic dashboard. Open Project → Integrations → Platform email— the Inbox section sits between the “Your business email domain” panel and “Bring your own domain”.

For workflows that need to react to incoming mail (e.g. auto-reply, create-CRM-row, forward to a Generic HTTP webhook), use the inbound_email workflow trigger. It fires for both platform-provisioned mail and a connected mailbox, and an optional matchTofilter narrows a workflow to one address. If the project's inbox is staffed, the assigned agent also gets each new message to read and act on.

Limits: each message body is capped at 500 KB plain text / 2 MB HTML at the Cloudflare layer before reaching us. Larger messages get rejected at the SMTP handshake so the sender sees a clear bounce. Attachments aren't yet surfaced in the inbox — add this need to contact if it's blocking you.

Reply-To headers still work the way you'd expect: when you send a workflow email, set reply-to: [email protected] and replies land in this same inbox.

Every workspace has a monthly send cap that scales with the tier (see the table above). You can see the current month's usage on the same Platform email panel. If you cross 90% we surface a banner; at 100% we pause sends until the next reset.

We also monitor bounce rate and complaint rate per workspace. If either spikes (typically >3% bounces or >0.1% complaints) we throttle automatically so one bad send doesn't poison your sender reputation. The panel shows a Deliverability tile when this kicks in.