# Email {% hint style="info" %} Email sending, delivery tracking, and engagement analytics are available through the Platform API. See the [Developer Guide](https://docs.amigo.ai/developer-guide) for endpoint details. {% endhint %} 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](https://docs.amigo.ai/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). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.amigo.ai/channels/email.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.