> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Convert emails to tickets with each Ravenna channel's unique inbound email address, supporting customer feedback and multi-channel support flows.

Each Ravenna channel gets a unique email address that automatically converts incoming emails into tickets. Use email integration to handle support requests, collect feedback, or manage inquiries from users who prefer email over other channels.

***

## Enable email for a channel

<Steps>
  <Step title="Open channel settings">
    Select your channel from the sidebar and click **Settings**.
  </Step>

  <Step title="Navigate to inbound email">
    In the left navigation, click **Inbound Email**.
  </Step>

  <Step title="Enable inbound email">
    Toggle on **Allow inbound emails to be sent to this Channel**.
  </Step>

  <Step title="Copy your channel email address">
    Your unique email address appears in this format:

    ```text wrap theme={"system"}
    PREFIX+CHANNEL_ID@mail.ravenna.ai
    ```

    Copy this address to share with users or configure email forwarding from your existing support inbox.

    <Callout icon="link" color="#6B7280">
      [Configure email forwarding](/integrations/email/configure-forwarding) from Google, Microsoft, or other providers
    </Callout>
  </Step>
</Steps>

<Info>
  Each channel has a unique email address. Emails sent to this address automatically create tickets in that specific channel.
</Info>

***

## How email-to-ticket conversion works

When an email arrives at your channel's email address:

1. **Ravenna receives the email** and extracts the sender, subject, and body
2. **Thread detection checks** if this email replies to an existing ticket
3. **New ticket creation** happens if no matching thread exists
4. **Guest user creation** occurs automatically if the sender is external to your organization
5. **CC recipients are added as followers** to keep stakeholders informed
6. **Notifications are sent** according to your channel's notification settings

The ticket inherits properties from your channel configuration, including assigned <Tooltip headline="AI agents" tip="AI assistants that handle requests automatically" cta="Learn about AI agents" href="/documentation/automate/ai-agents/overview">agents</Tooltip>, <Tooltip headline="Forms" tip="Structured intake forms with custom fields" cta="Learn about forms" href="/documentation/tickets/forms/overview">forms</Tooltip>, and <Tooltip headline="Workflows" tip="Automated actions triggered by ticket events" cta="Learn about workflows" href="/documentation/automate/workflows/overview">workflows</Tooltip>.

<Accordion title="CC recipients as followers" icon="users">
  When an inbound email includes CC recipients, Ravenna automatically adds them as <Tooltip headline="Followers" tip="Users who receive updates about ticket progress" cta="Learn about ticket roles" href="/documentation/tickets/roles">followers</Tooltip> on the ticket. This keeps stakeholders informed about ticket activity without requiring manual follower management.

  **How CC follower processing works:**

  * **Existing users** in your organization are added as followers immediately
  * **New external users** are created as guest users (if guest users are enabled) and added as followers
  * **System addresses** (`@mail.ravennahq.com`) are automatically filtered out
  * **The sender's email** is excluded since they're already the ticket author
  * **Duplicate emails** are deduplicated before processing

  **Interaction with channel settings:**

  | Setting                  | Behavior                                                                                 |
  | ------------------------ | ---------------------------------------------------------------------------------------- |
  | **Guest users disabled** | Only existing users from CC are added as followers. Unknown email addresses are skipped. |
  | **Guest users enabled**  | New guest accounts are created for CC recipients not in your organization.               |
  | **Allowlist configured** | CC recipients must match your allowlisted emails or domains to be added as followers.    |

  <Info>
    CC recipients are processed for both new tickets and replies to existing tickets. Each reply can add new followers from its CC list.
  </Info>
</Accordion>

***

## Forwarded emails

When a team member forwards an external email into your channel, Ravenna can identify the original sender and use them as the ticket requester. This is useful when customer requests arrive in a shared inbox first and get forwarded into Ravenna for triage.

<Accordion title="Extract forwarded requester" icon="forward">
  Enable **Extract forwarded requester** in your channel's **Inbound Email Settings** to set the original sender of a forwarded email as the ticket requester. When disabled, the person who forwarded the email becomes the requester.

  **When to use it**

  * Your team forwards customer emails from a personal or shared inbox into Ravenna.
  * You want replies, notifications, and CSATs to reach the original customer, not the internal forwarder.
  * You triage email outside Ravenna and want accurate requester attribution on the resulting ticket.

  **How it works**

  Ravenna parses the forwarded email body for standard forward markers and the `From:` header that follows. Supported formats include Gmail (`---------- Forwarded message ---------`), Apple Mail (`Begin forwarded message:`), and Outlook (`-----Original Message-----`).

  The extracted sender becomes the ticket requester. If the address matches an existing user, Ravenna uses that user. If the address is external and **Allow guest users** is enabled, Ravenna creates a guest user for them.

  **Requirements**

  * The email subject starts with `Fwd:`, `FW:`, or `Fw:` (pure forwards only — `Re: Fwd:` replies are not re-attributed).
  * The body contains a recognizable forward marker followed by a `From:` header with a valid email address.
  * For external senders, **Allow guest users** must be enabled to create the requester record.

  If extraction fails or the message is not a forward, the forwarder remains the requester.

  <Info>
    This setting only affects new tickets created from forwarded emails. Replies on existing tickets continue to use their original requester.
  </Info>
</Accordion>

***

## Email threading and replies

<AccordionGroup>
  <Accordion title="How email threads map to tickets" icon="message-square">
    Ravenna preserves email conversation context by mapping email threads to ticket threads:

    **New tickets are created when:**

    * The email subject doesn't match any existing ticket
    * The sender starts a new conversation
    * The email doesn't contain reply headers referencing an existing ticket

    **Existing tickets are updated when:**

    * The email replies to a previous message in the thread
    * Email headers (In-Reply-To, References) match an existing ticket
    * The subject line contains a ticket reference like `[HELP-123]`

    All replies appear as messages in the ticket timeline, maintaining the complete conversation history.
  </Accordion>

  <Accordion title="Outbound email replies" icon="reply">
    When team members reply to tickets created from email:

    * Replies are sent to the original sender's email address
    * The sender name appears as configured in your channel settings
    * Email formatting is preserved (plain text and HTML)
    * Attachments from Ravenna tickets are included in the email
    * Reply-to headers ensure responses thread correctly

    <Info>
      Team members can reply to email-based tickets from Ravenna, Slack, or any integrated channel. All replies route to the requester's email address.
    </Info>
  </Accordion>
</AccordionGroup>

***

## Outbound email configuration

<AccordionGroup>
  <Accordion title="Sender name" icon="user-pen">
    Customize the sender name that appears in the "From" field of outbound emails. This helps recipients identify where the email came from.

    By default, outbound emails use your workspace name. Configure a custom sender name in your channel's inbound email settings to:

    * Match your brand or team name
    * Distinguish between different support teams
    * Provide clearer context for external recipients

    Example: "Acme Support Team" instead of "Acme Workspace"
  </Accordion>

  <Accordion title="Email footer" icon="text">
    Add a custom footer that appears at the bottom of all outbound emails from a channel. Use email footers to include:

    * Legal disclaimers or confidentiality notices
    * Contact information for your team
    * Links to your help center or website
    * Brand-specific messaging

    The footer editor supports rich text formatting including bold, italic, links, images, lists, and headings. Footer content is separated from the email body by a horizontal line.

    To configure an email footer, navigate to your channel's **Inbound Email** settings and enter your content in the **Email footer** field.
  </Accordion>

  <Accordion title="Bounce email handling" icon="mail-x">
    Enable bounce email notifications to receive alerts when emails fail to deliver. Bounce handling helps you:

    * Identify invalid email addresses
    * Detect delivery failures
    * Update contact information for requesters
    * Monitor email deliverability issues

    When enabled, Ravenna sends bounce notifications to your configured notification channels or workspace administrators.
  </Accordion>

  <Accordion title="Agent form-link emails" icon="file-text">
    When the AI agent decides a request needs structured intake during an email conversation, it emails the requester a button that opens the matching <Tooltip headline="Form" tip="Structured intake forms with custom fields" cta="Learn about forms" href="/documentation/tickets/forms/overview">form</Tooltip> in the <Tooltip headline="Requester portal" tip="Self-service home where end users submit and track requests" cta="Learn about the requester portal" href="/documentation/platform/portal/requesters">requester portal</Tooltip>.

    This keeps complex requests on a single ticket instead of asking users to copy details into a new submission. The link opens the form scoped to the existing ticket, and any values the agent collected are prefilled so the user only fills in what is missing.

    **How it works**

    * The agent picks a published form referenced in one of its rules (for example, `@Hardware Request`).
    * Ravenna emails the requester a message titled *Action required: Please fill out a form for \<TICKET>* with a **Fill out: \<form name>** button.
    * The button deep-links to that form in the customer portal, scoped to the original ticket.
    * Values the agent collected during the conversation (text, numbers, dates, single- and multi-select options) are prefilled so the user only completes what is missing.
    * CC recipients on the ticket are included on the form-link email so stakeholders stay in the loop.

    **When it applies**

    * The active reply channel for the ticket is email.
    * The agent has a rule that references the form with `@Form Name`.
    * The form is in **Published** status. Draft and archived forms are skipped.

    If Ravenna cannot build a deep link (for example, the form was unpublished mid-conversation), it falls back to a regular email reply so the conversation is never dropped.

    <Info>
      The form opens scoped to the existing ticket, so submitting it updates that ticket rather than creating a new one.
    </Info>
  </Accordion>

  <Accordion title="Email delivery status on messages" icon="circle-check">
    Outbound email messages on a ticket display a delivery status badge so agents can see, at a glance, whether each email reached the recipient.

    The badge appears on the message card next to the sender details and updates as new delivery information arrives from the email provider. Use it to:

    * Confirm that a reply was successfully delivered
    * Spot bounced or failed emails directly in the ticket timeline
    * Decide when to follow up through another channel

    The badge applies only to outbound emails sent from Ravenna. Inbound emails and messages on non-email channels do not show a delivery status.
  </Accordion>
</AccordionGroup>

***

## Guest users

When inbound email is enabled with guest users allowed, emails from addresses outside your organization automatically create guest user accounts.

<AccordionGroup>
  <Accordion title="What are guest users" icon="user-plus">
    <Tooltip headline="Guest users" tip="Users from outside your organization who can interact via email" cta="Learn about members and groups" href="/documentation/collaborate/members-groups">Guest users</Tooltip> are external contacts who submit tickets via email. They receive:

    * A user record in Ravenna for tracking and identification
    * Email notifications when their tickets are updated
    * The ability to reply to tickets via email
    * No access to your Ravenna workspace or web interface

    Guest users appear in ticket requesters, notifications, and user searches, but cannot log in to Ravenna or view other tickets.
  </Accordion>

  <Accordion title="Guest user permissions" icon="shield-check">
    Guest users have restricted permissions:

    **What guest users can do:**

    * Create tickets by emailing your channel address
    * Reply to their own tickets via email
    * Receive email notifications about their tickets

    **What guest users cannot do:**

    * Access the Ravenna web interface
    * View other users' tickets
    * Use Slack integration features
    * Access internal notes or private information

    <Info>
      Guest user creation requires the **Guest users** setting to be enabled in your channel's inbound email configuration.
    </Info>
  </Accordion>
</AccordionGroup>

***

## Security and filtering

Control which email addresses can create tickets in your channel using allow lists and block lists. Configure both under your channel's **Inbound Email** settings.

<AccordionGroup>
  <Accordion title="Default behavior" icon="building-2">
    By default, Ravenna only accepts emails from addresses matching your organization's domain. This prevents unauthorized ticket creation while allowing internal users to submit requests.

    When guest users are enabled without allow lists or block lists configured, all external email addresses can create tickets.
  </Accordion>

  <Accordion title="How allow lists and block lists interact" icon="list-checks">
    Ravenna evaluates every inbound email against the block list first, then the allow list:

    1. **Block list check** - If the sender's email or domain matches an entry on the block list, the email is rejected immediately. The block list always takes precedence.
    2. **Allow list check** - If an allow list is configured and the sender does not match a blocked entry, the email must match an allowlisted email or domain to be accepted.
    3. **No lists configured** - With guest users enabled and no lists configured, all external senders can create tickets.

    Block list entries override allow list entries. For example, if `vendor.com` is on the allow list and `spam@vendor.com` is on the block list, emails from `spam@vendor.com` are still rejected.
  </Accordion>

  <Accordion title="Allowlisted emails" icon="mail-check">
    Specify individual email addresses permitted to create tickets. Use allowlisted emails to:

    * Grant access to specific partners or vendors
    * Allow select external users to submit requests
    * Create a controlled list of authorized senders

    Add email addresses one per line in the allowlisted emails field.

    Example:

    ```text wrap theme={"system"}
    partner@vendor.com
    consultant@external.org
    ```
  </Accordion>

  <Accordion title="Allowlisted domains" icon="globe">
    Specify entire domains permitted to create tickets. Use allowlisted domains to:

    * Allow all users from a partner organization
    * Accept emails from customer domains
    * Enable access for external teams

    Add domains using the `@domain.com` format, one per line.

    Example:

    ```text wrap theme={"system"}
    @partnercompany.com
    @customerdomain.org
    ```

    Domain entries match the exact domain and any subdomain. For example, `@company.com` allows `user@company.com` and `user@mail.company.com`. Unrelated domains that share the suffix, such as `user@mycompany.com`, are not allowed.
  </Accordion>

  <Accordion title="Blocked emails" icon="mail-x">
    Specify individual email addresses that should always be rejected, even if they match the allow list. Use blocked emails to:

    * Stop known spam or abusive senders
    * Reject automated mailers that create noisy tickets
    * Override a broad allowlisted domain for specific addresses

    Add email addresses one per line in the blocked emails field.

    Example:

    ```text wrap theme={"system"}
    spam@vendor.com
    noreply@marketing.example.com
    ```
  </Accordion>

  <Accordion title="Blocked domains" icon="ban">
    Specify entire domains that should always be rejected, even if they match the allow list. Use blocked domains to:

    * Block known spam domains in bulk
    * Reject email from a former vendor or partner
    * Exclude a domain that would otherwise be implicitly allowed

    Add domains using the `@domain.com` format, one per line.

    Example:

    ```text wrap theme={"system"}
    @spam.com
    @bulk-mailer.net
    ```

    Domain entries match the exact domain and any subdomain. For example, `@spam.com` blocks `user@spam.com` and `user@mail.spam.com`. Unrelated domains that share the suffix, such as `user@notspam.com`, are not blocked.
  </Accordion>

  <Accordion title="Workflow email replies bypass queue settings" icon="shield-off">
    When a <Tooltip headline="Workflow" tip="Automated actions triggered by ticket events" cta="Learn about workflows" href="/documentation/automate/workflows/overview">workflow</Tooltip> sends an email to an external recipient, replies to that email bypass certain queue security settings.

    **How it works:**

    Workflow-sent emails include a special reply address in the format `ticket+TICKETID@mail.ravenna.ai`. When someone replies to this address (either in the To or CC field), Ravenna processes the reply regardless of:

    * **Guest user settings** - Ravenna accepts the reply even if guest users are disabled for the queue
    * **Email allow lists** - Ravenna processes the reply regardless of configured email and domain allow lists
    * **Email block lists** - Ravenna processes the reply regardless of configured email and domain block lists

    **Why this behavior exists:**

    When a workflow explicitly sends an email to someone, that action represents an intentional decision to communicate with that person. Blocking their reply would break the expected email conversation flow. Because the workflow chose to email them, their reply is allowed through.

    <Info>
      This bypass only applies to direct replies using the `ticket+TICKETID@` format. New emails to your channel's standard address still respect all queue settings.
    </Info>
  </Accordion>
</AccordionGroup>

<Warning>
  If allow lists are defined, Ravenna only processes emails from specified sources and rejects all others. Block list entries always override allow list entries. Ensure your lists include the right addresses and domains before enabling.
</Warning>

***

## Troubleshooting

<AccordionGroup>
  <Accordion title="Emails not creating tickets">
    If emails aren't creating tickets, check:

    * **Inbound email is enabled** in channel settings
    * **Email address is correct** and matches your channel's unique address
    * **Sender is allowlisted** if allow lists are configured
    * **Sender is not blocked** by an email or domain block list entry
    * **Guest users are enabled** if the sender is external to your organization
    * **Email isn't being rejected** by allow list or block list rules

    Review your channel's inbound email settings and verify the sender meets all requirements.
  </Accordion>

  <Accordion title="Email replies creating new tickets">
    If email replies create new tickets instead of updating existing ones:

    * Ensure the subject line includes the ticket reference (e.g., `[HELP-123]`)
    * Check that reply headers (In-Reply-To, References) are preserved by the sender's email client
    * Verify the email is sent from the same address as the original ticket requester

    Some email clients strip reply headers. Ask senders to preserve the subject line with the ticket reference for reliable threading.
  </Accordion>

  <Accordion title="External users not receiving notifications">
    If external users aren't receiving email notifications:

    * Verify **Guest users** is enabled in channel settings
    * Check that the sender's email address is valid
    * Look for bounce notifications indicating delivery failures
    * Ensure the user's email provider isn't blocking emails from `@mail.ravenna.ai`

    Ask external users to check spam folders and add `@mail.ravenna.ai` to their allowed senders list.
  </Accordion>
</AccordionGroup>
