Ticket Email Routing

Ticket emails support notification delivery, inbox routing, and reply-based workflows.

Public ticket forms are available without Pro.
Email routing and reply-by-email require a Pro workspace. Customer-owned ticket mailboxes also require Pro and scale with your Pro seats: one hosted mailbox per Pro seat.

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

Ticket emails use the logo, display name, and primary color from the Pages domain used for public ticket links. If that branding is not configured, the email falls back to the Bnder logo and default accent color.

When a Pages display name is available, the footer includes a sender context line such as "Sent for your workspace via Bnder.", with the Bnder label linked to bnder.net. It also keeps the Bnder legal company details and legal links.

Reply-To behavior

Ticket emails first use the project Customer mailbox when one is connected and the workspace has Pro seats.

Examples:

  • support@your-company.com
  • helpdesk@customer.com

When a customer mailbox is active, participant/reporter ticket emails are sent from that address and replies go back to the same inbox.

If no customer mailbox is connected, Ticket emails set Reply-To per project to the configured Bnder fallback 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 on Pro.

Sender behavior

Ticket emails use the connected customer mailbox as sender when possible. If outbound sending from that provider fails or is not configured, they fall back to the project Bnder address:

  • <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.

Customer mailbox setup

In Project Settings -> Tickets, use Customer mailbox to:

  • Configure standards-compatible SMTP/IMAP mailboxes
  • Bind one mailbox to the current project
  • Enable or disable inbound sync and outbound sending separately
  • Replace SMTP/IMAP credentials when they rotate
  • Delete mailbox connections that should no longer be used
  • Test the connection and view separate receiving and sending health

Use shared team addresses, not personal agent mailboxes. Each Pro seat adds one customer mailbox slot. If the workspace reaches the limit, add another Pro seat or remove an unused mailbox connection. For Microsoft 365 or Google Workspace, use SMTP/IMAP settings if your workspace admin allows those protocols. For v1, one inbound-enabled mailbox should be bound to one project so new-ticket routing stays unambiguous.

SMTP/IMAP credentials are stored server-side only and are never shown again in the app. You can still change mailbox labels or enable/disable inbound and outbound handling without re-entering credentials. Very large inbound attachments may be omitted from a ticket reply if they would exceed the internal email processing limit. The ticket message will include a note when that happens.

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. If a mail app rewrites the subject and removes the marker, Bnder can still match replies from standard email thread headers such as In-Reply-To and References when the original Bnder ticket email is still part of the mail thread.

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 the subject marker is missing but the mail thread points to a Bnder ticket email, it is handled as a reply
  • If not, it can create a new ticket on Pro
  • New inbound tickets are routed by the connected customer mailbox or, for fallback routing, 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 reply-capable 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.