> ## Documentation Index > Fetch the complete documentation index at: https://docs.anyreach.ai/llms.txt > Use this file to discover all available pages before exploring further. # Configuring an email agent > Set how an agent composes and sends email replies. Email properties control how an agent renders and sends an outbound email — the subject, body, HTML wrapper, signature, footer, and the rules that decide when to reply or close a thread. They live in the agent's per-channel `channel_properties` under the `email` key and do not change what the agent says, only how the reply is delivered. To steer what the agent *says* on email (instructions, greeting, tool budget), use `channel_overrides` instead — see [Per-channel configuration](/agents/per-channel-configuration). ## EmailProperties reference Every field is optional; omit a field to take its default. The full block lives at `channel_properties.email`. | Field | Type | Default | Description | | ---------------------------- | ------------------------------------ | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | `channel` | `"email"` | `"email"` | Fixed discriminator for the email block. | | `enabled` | boolean | `true` | Whether the email channel is active for this agent. | | `body_template` | string | `{{agent_response}}` | Wraps the model's reply. Rendered with Jinja; `{{agent_response}}` is the generated text. | | `body_format` | `multipart` \| `html` \| `plaintext` | `multipart` | Which MIME parts to send. `html` drops the plaintext part; `plaintext` drops the HTML part; `multipart` sends both. | | `subject_template` | string | `Re: {{subject}}` | Subject used once a thread exists. `{{subject}}` is replaced with the original inbound subject. | | `default_subject` | string \| null | `null` | Subject for an agent-initiated email when none is supplied and no thread exists yet. | | `from_display_name` | string \| null | `null` | Friendly name on the `From` header, rendered as `Name
`. Also registered as an alias the reply gate recognizes when the agent is only CC'd. | | `signature` | string \| null | `null` | Markdown signature appended below the reply body, before the footer. | | `template_wrapper` | string \| null | `null` | Branded HTML shell with a `{{body}}` slot. The rendered HTML body is substituted into `{{body}}`. | | `include_unsubscribe_footer` | boolean | `true` | Appends a `Reply STOP to unsubscribe.` line to the body. | | `quote_history` | boolean | `false` | Quotes the prior inbound beneath the reply, mail-client style. | | `cc_reply_policy` | `conditional` \| `never` \| `always` | `conditional` | What to do when the agent was only CC'd, not a direct `To` recipient. | | `require_dmarc_pass` | boolean | `false` | When true, the agent only replies to mail that passed DMARC. | | `auto_close_on_conclusion` | boolean | `true` | When true, close the conversation as soon as the reply gate judges it complete, instead of waiting for the idle timeout. | ### How the body is assembled The renderer reuses the real delivery path, so the order is fixed: ``` 1. body_template -> body (Jinja, with {{agent_response}}) 2. + signature (if set) 3. + "Reply STOP" footer (if include_unsubscribe_footer) 4. + quoted history (if quote_history) 5. template_wrapper wraps the HTML body via {{body}} 6. body_format selects which MIME parts ship ``` The Markdown body is converted to HTML automatically. `signature` is also rendered from Markdown. `subject_template` only applies once a thread exists — that is, when there is a prior inbound message to reply to. For the first message of a brand-new thread, the original subject is kept as-is, or `default_subject` is used for an agent-initiated send with no subject. ### Reply and close behavior `cc_reply_policy`, `require_dmarc_pass`, and `auto_close_on_conclusion` feed the reply-eligibility decision on every inbound message: | Setting | Effect | | -------------------------------- | ------------------------------------------------------------------------------------------------------------- | | `require_dmarc_pass: true` | Inbound mail whose DMARC result is not `pass` is skipped — no reply. | | `cc_reply_policy: never` | When the agent is only CC'd (not in `To`), skip the reply. | | `cc_reply_policy: always` | When the agent is only CC'd, always reply. | | `cc_reply_policy: conditional` | When the agent is only CC'd, defer to the reply gate, which decides whether the agent is addressed or needed. | | `auto_close_on_conclusion: true` | If the gate judges the conversation complete, close it proactively. | When the agent is a direct `To` recipient, it replies regardless of `cc_reply_policy`. Any uncertainty defaults to replying and not closing. For more on threading, recipients, and gating, see [Threading and replies](/email/threading-and-replies). ## Per-channel overrides `channel_properties` governs delivery; `channel_overrides` governs the model. The email override block (`channel_overrides.email`) accepts: | Field | Type | Default | Description | | ------------------- | --------------------- | -------- | --------------------------------------------------------------------------------------- | | `instructions` | string \| null | `null` | Extra steering for the email channel. | | `instructions_mode` | `append` \| `replace` | `append` | `append` adds to the base instructions; `replace` swaps them out entirely. | | `starting_message` | object \| null | `null` | Per-channel greeting, used in place of the base starting message. | | `max_tool_steps` | integer \| null | `null` | Tool-call budget per turn for this channel. Falls back to the base config, then to `3`. | See [Per-channel configuration](/agents/per-channel-configuration) for the override model in full. ## Preview the rendered email `POST /core/messaging/preview` runs the real renderer against a sample agent response and returns exactly what would be delivered — subject, HTML, and plaintext — without sending anything. The agent editor uses this for the live preview. Requires either the `agents:read` or `agents:manage` scope. ```bash theme={null} curl -X POST https://api.anyreach.ai/core/messaging/preview \ -H "Authorization: Bearer " \ -H "X-Anyreach-Org: " \ -H "Content-Type: application/json" \ -d '{ "channel": "email", "properties": { "signature": "Best,\nThe Acme Team", "include_unsubscribe_footer": true, "body_format": "multipart" }, "sample_agent_response": "Yes — we ship to Canada in 3-5 business days.", "context": { "subject": "Do you ship to Canada?" } }' ``` ### Request body | Field | Type | Default | Description | | ----------------------- | -------------------------- | ----------------------------------------------- | --------------------------------------------------------------------------------- | | `channel` | `email` \| `text` \| `sms` | required | Channel to render. | | `properties` | object | `{}` | The channel properties block (here, `EmailProperties` fields). | | `sample_agent_response` | string | `Yes — we ship to Canada in 3-5 business days.` | The model output to wrap and render. | | `context` | object \| null | `null` | Template variables. For email, `subject` seeds the original-subject substitution. | ### Response ```json theme={null} { "subject": "Re: Do you ship to Canada?", "html": "

Yes — we ship to Canada in 3-5 business days.

...", "plaintext": "Yes — we ship to Canada in 3-5 business days...." } ``` For `text` and `sms` channels, `subject` and `html` are `null` and only `plaintext` is populated. Steer instructions, greeting, and tool budget per channel. How threads, recipients, and the reply gate work.