Ticket Email Routing

Ticket emails support both notification delivery and reply-based workflows.

Email-to-ticket creation is available on all plans.
Reply-by-email requires a Pro workspace.

Outbound notifications

Ticket emails are sent for key events such as:

  • New ticket created
  • New public message
  • Ticket moved into closed states (for example resolved/rejected)
  • Ticket auto-closed after waiting on reporter timeout
  • SLA warning became active

For update mails with a new public message, the message content is rendered in a dedicated message box for better readability.

Recipients are derived from reporter + notify emails, excluding:

  • Unsubscribed addresses
  • The actor address that triggered the event

Reply-To behavior

Ticket emails set Reply-To per project to the configured mailbox local-part:

  • <your-project-local-part>@tickets.bnder.net

If no project mailbox is configured yet, the system falls back to the default inbox address.

Replies can be routed automatically from these inboxes into ticket updates.

Sender behavior

Ticket emails also use the project mailbox as sender when a mailbox local-part is configured for the ticket project:

  • <your-project-local-part>@tickets.bnder.net

If no mailbox local-part is configured yet, the system generates one from the workspace and project names, stores it in the project ticket settings, and reuses it for future replies until a user changes it manually.

Subject format and ticket matching

Notification subjects include a ticket marker:

  • Example pattern: [Ticket <ticket-id>]

New numeric ticket ids are only unique within one workspace, so reply-by-email resolves them primarily from the dedicated project mailbox local-part instead of relying on extra workspace hints in the subject.

Inbound create vs reply behavior

When an inbound provider forwards an email:

  • If subject contains an explicit ticket marker, it is handled as a reply
  • If not, it can create a new ticket
  • New inbound tickets are routed by recipient mailbox local-part (<local-part>@tickets.bnder.net)
  • Customer mapping is optional and used to auto-assign customer + SLA; if a mapped customer has a default project, that project is preferred for creation
  • On successful inbound ticket creation, CC recipients are added to the ticket notify list
  • The ticket-created confirmation sent to the sender is threaded as a reply to the inbound mail (when message id is available)
  • If reply-by-email is not available on the workspace plan, inbound reply emails are ignored and the sender receives a guidance email

Recipient requirements for new inbound tickets

The inbox local-part must exist for the target project. It can be set manually in the ticket settings or generated automatically the first time the project sends a replyable ticket email.

If the local-part is unknown, no ticket is created and the sender receives a dedicated guidance email. When the inbound mail contains a message id, this guidance email is sent as a thread reply in the sender mailbox.

Common inbound errors

  • Unknown ticket mailbox local-part
    No ticket is created. The sender receives a guidance email.
    Configure the project inbox local-part in Project Settings -> Tickets or send one replyable ticket email first so the system can generate and persist a dedicated route automatically.