Skip to Content
CraftBot Docs v1 — internal preview

Email servers

CraftBot uses outbound email servers to send transactional messages from the platform: auth invites, password resets, in-app email notifications, nudge escalations, and scheduled-report deliveries.

Supported providers

ProviderAuth
Microsoft 365OAuth2 (popup consent flow)
Gmail / WorkspaceOAuth2 (popup consent flow)
Generic SMTPUsername + password

OAuth2 is supported here because outbound email needs durable delegated access to a real mailbox. (This is a carve-out from the workspace-wide “static credentials only” rule that applies elsewhere.)

Adding a server

  1. Settings → Channels → Email Servers → + New email server.
  2. Pick the provider mode (M365 / Gmail / Generic SMTP).
  3. Name — a recognisable label (e.g. Tenant outbound (M365)).
  4. From address — the mailbox the message will appear from.
  5. From filter — a pattern that decides which outbound emails route through this server. Useful when you have more than one server for different from-addresses.
  6. Active — only active servers participate in routing.
  7. For M365 / Gmail: click Connect to launch the consent popup. CraftBot exchanges the authorisation code, stores the resolved mailbox identity, and marks Auth = OK.
  8. For Generic SMTP: enter host, port, username, and password directly. The form validates and completes on Save.

If you need the exact Azure App Registration or Google Cloud OAuth client steps, the Setup guide panel at the top of the page expands inline with the up-to-date instructions for each provider.

Authentication state

Each server shows one of three states:

  • OK — connected and ready to send.
  • Not authenticated — newly created, has never completed the OAuth dance. Click Connect to finish setup.
  • Re-auth needed — the stored token expired or was revoked at the provider side. Click Connect to reconnect.

A server cannot send while it shows anything other than OK.

Default server

One active server can be marked Default. The default is used when:

  • No from-filter on any other server matches the outbound message.
  • Auth invites and password-reset emails fire from the platform (these always use the default).

Promote another server to default with the Make default link on its row (only available on servers whose auth state is OK).

Send test

The Send test action on each row fires a synthetic message to the configured from-address. Useful for verifying the server reachability and SMTP response without waiting for a real auth invite or notification.

Where email servers are used

  • Authentication invites — new-user invite emails.
  • Password resets — forgotten-password flow.
  • Notifications — per-user email delivery for in-app notification types that have email enabled.
  • Nudge rules — email-channel nudges.
  • Scheduled report delivery — analytics-export “your report is ready” emails.

Deleting a server

Soft-delete via the Delete button. The row is hidden from active routing; historical audit-log entries are preserved. Outbound emails that previously routed through this server (via from-filter) fall through to other active servers.

Best practices

  • Use a single default server per workspace. Add additional servers only when a specific from-address must use a separate mailbox.
  • Prefer OAuth2 (M365 or Gmail) when available — token rotation is handled automatically. Generic SMTP requires manual credential rotation.
  • Watch the Auth state column. A server stuck in Re-auth needed silently breaks every consumer that routes through it.
Last updated on