Company email and public CC

CaseKit keeps your existing company mailbox. Forward incoming support mail to the route's private platform address, keeping your current MX records. By default, replies use the platform From address and your verified company alias as Reply-To.

Use a company From address

  1. A human Owner or Admin adds the exact company domain in Email settings. The connection starts disabled.
  2. Publish the returned ownership TXT record and check domain ownership. This is a public challenge for this connection, not a password or a shared secret.
  3. Contact support to finish sending setup for the proven domain and the exact addresses you want to use.
  4. Publish all returned DKIM CNAMEs. If using a custom return path, add its SPF TXT and MX at the dedicated subdomain. Keep your company mailbox MX and existing DMARC policy.
  5. Refresh the separate ownership and authentication checks, enable company sending, then explicitly select the ready company address on its verified support route.

Company mode requires current permission and successful signing. If these become unavailable, new delivery stops until restored; the platform address is not substituted. Setup checks do not prove inbox placement. A receiving-server IP allowlist cannot replace email authentication or guarantee delivery elsewhere.

Domain and sender administration require a current human Owner/Admin session. API keys cannot perform these operations. See Email routes for request bodies, If-Match, UUID idempotency keys and safe error responses.

Approve participants, then choose reply-all

Each ticket may have up to ten approved public CC addresses. Incoming CCs are suggestions until staff approve and save them. Replies default to the requester only. Choose requester and approved CC explicitly and review the To/CC preview before sending. CC recipients can see each other's addresses; BCC is not supported. 

PUT /v1/tickets/{ticketId}/participants
If-Match: "<current ticket version>"
Idempotency-Key: <stable retry key>

{"cc":["colleague@example.test"]}

POST /v1/tickets/{ticketId}/replies
If-Match: "<new ticket version>"
Idempotency-Key: <new stable retry key>

{"body":"A new public reply","audience":"reply_all"}

These addresses are local documentation examples. Use controlled deliverable inboxes for live acceptance. Every request needs authentication and the accessible tenant selector. Notes reject audience and remain staff-only. The dashboard keeps note and reply drafts and attachments separate.

Read delivery by recipient

One logical reply has independent recipient work. Queued means waiting; accepted means the email provider accepted a send; delivered means the recipient's mail server accepted it. Neither acceptance nor delivery guarantees inbox placement or reading. Failures, suppression and spam reports are shown per recipient. A failed CC does not resend successful siblings.

Removing a participant and saving prevents future eligible queued sends and new inbound appends. Already accepted messages cannot be recalled. New participants are not added to an earlier reply snapshot. Unknown or removed senders referencing a ticket start a separate ordinary ticket containing only their incoming content.

See Ticket conversation for the audience and recipient delivery contracts.