Email

Email channel with domain verification, inbound reply handling, thread continuity, and transactional and marketing use cases.

Sending Domain Setup

Before an email use case can send or receive messages, the workspace must register a verified sending domain. Each setup binds a logical tenant name to a domain identity, creating an isolation boundary for reputation and suppression management.

The registration process works in three steps:

1. Create the setup - Provide a tenant name and domain identity. The platform provisions the domain and returns a set of DNS records (DKIM, MX, and DMARC) that must be published at your DNS provider.

2. Publish DNS records - Add the returned records to your domain's DNS configuration. Each record has a type, address, and value.

3. Verify - Trigger a verification check from the Developer Console or API. The platform resolves each record against live DNS and marks it as verified or pending. All records must pass before the setup can back any email use case.

A single domain identity serves both outbound sending and inbound receiving. Setups that have not completed DNS verification cannot be used by email use cases.

Setups can be deleted when no longer needed, though active use cases referencing a setup will block deletion.

Email Channel Setup

The platform supports workspace-scoped email channel configuration. Each workspace can provision one or more verified email domains for sending and receiving messages. When a domain is added, the platform returns the DNS records (DKIM, MX, DMARC) that must be published at the customer's DNS provider. Subsequent verification checks confirm that the records are in place and the domain is ready for use.

Domain verification is live - every status check re-queries DNS rather than relying on cached results, so teams see up-to-date verification status without waiting for a background refresh cycle.

Each email domain setup is isolated to its workspace. Cross-workspace access is prevented at the API layer, and deletion is blocked while any active use case still references the setup.

Email sending, delivery tracking, and engagement analytics are available through the Platform API. See the Developer Guide for endpoint details.

The platform supports email as a communication channel alongside voice and text. Workspaces can set up verified sending domains, create email use cases, send messages through the platform API, and receive inbound replies that thread back into the original conversation.

Email Setup

Before sending email, a workspace configures an email setup by registering a sending domain. The platform provisions the necessary DNS records for domain authentication. Once the DNS records are verified, the domain is approved for sending.

Each email setup includes:

• Domain identity - The domain used for sending (e.g., notifications.example.com)

• DNS records - Records that must be added to the domain's DNS configuration for verification, including DKIM signing keys and inbound MX routing

• Verification status - Whether the DNS records have been confirmed

Email Use Cases

Once a domain is verified, you create email use cases that define how the domain is used. Each email use case specifies:

• Sender email address - The From address for messages sent through this use case

• Email type - Either transactional (triggered by user actions, like appointment confirmations) or marketing (bulk or promotional messages). The type determines sending rules and compliance handling.

• Entity name and use case name - Labels that identify the purpose of the use case for reporting and management

Email use cases are managed through the Platform API. See the Developer Guide for endpoint details.

Inbound Email

Attachment Handling

The platform extracts attachments from inbound emails by walking the full MIME tree depth-first, handling deeply nested structures produced by clients like Apple Mail and iOS Mail that wrap HTML alternatives and attachments together inside nested multipart branches. This ensures attachments are never silently dropped regardless of how the sending client structures its MIME parts.

Forwarded-as-attachment emails (enclosed as message/rfc822 parts) are treated as single opaque .eml files - the platform does not recurse into forwarded messages, so attachments inside a forwarded email are never incorrectly attributed to the outer message.

Inline images referenced from the email body via cid: URLs are identified by matching Content-ID headers against references in the HTML. These images are stored using their Content-ID as the filename, allowing frontend clients rendering the email body to resolve cid: image references directly to the attachment path without additional lookups. This also prevents inline images like signature logos from appearing as both rendered body content and separate downloadable attachments.

When a domain's MX records are configured, the platform receives and processes inbound email. Inbound messages are resolved back to the original outbound email that prompted the reply, linking the patient's response to the correct conversation context.

Reply resolution uses the standard In-Reply-To and References headers from the inbound message to find the parent outbound. When a match is found, the inbound email is associated with the same use case and workspace, giving downstream systems full thread context.

Reply Threading

Outbound emails can be sent as replies to inbound messages, maintaining thread continuity in the patient's email client. When sending a reply, the platform sets the In-Reply-To and References headers according to RFC 5322, so the patient sees a single threaded conversation rather than disconnected messages.

The platform maintains the full reference chain across multiple reply rounds. If a patient replies to an outbound, and the platform replies back, and the patient replies again, each message carries the complete thread history. Even when a patient's email client strips the References header (some lightweight mailers do this), the platform reconstructs the chain from its stored records so the next outbound reply still threads correctly.

Reply threading is scoped to the same use case and email setup. Cross-use-case replies are rejected to prevent confused-deputy scenarios where a reply intended for one context could be misattributed to another.

Delivery Tracking

The platform tracks delivery events for every outbound email:

• Delivery confirmation - When the receiving mail server accepts the message

• Bounce handling - Hard bounces (invalid address) and soft bounces (temporary failure) are recorded and influence future sending decisions

• Complaint tracking - When a recipient marks a message as spam, the platform records the complaint and can suppress future sends to that address

Unsubscribe Handling

Outbound emails include RFC 8058 one-click unsubscribe headers. When a patient clicks the unsubscribe button in their email client, the platform processes the opt-out automatically. Unsubscribe scope can be per-use-case (the patient stops receiving emails from one campaign but continues receiving others) or per-setup (the patient opts out of all email from that domain).