Outbound mail

Outbound mail

Keystone sends a lot of email — every ticket reply, every approval request, every SLA breach notification, every digest. The mail settings page configures how and from where.

Supported providers

• SMTP — generic; works with anything (Office 365 SMTP, Google SMTP, an in-house relay)
• Microsoft Graph — for trusts using Microsoft 365; OAuth-authenticated, no SMTP password
• Amazon SES — high-volume, cheap; for trusts at scale
• Mailgun / Postmark / SendGrid — managed transactional providers
• Log driver — captures emails to the system log instead of sending; useful for staging/dev

Configuration

Per-workspace settings:

• Provider — pick from the list
• From address — helpdesk@<your-trust>.org
• From name — typically the trust or workspace name
• Reply-to — usually the same as from; sometimes a no-reply pattern with a clear “raise a ticket” message
• Subject prefix — appears on every outbound email, e.g. [Helpdesk]
• Bounce handling — webhook URL the provider hits when a delivery fails; updates user’s email_status so the platform stops retrying

Provider-specific fields appear when you pick the provider. For SMTP, that’s host/port/username/password/encryption. For Microsoft Graph, OAuth client ID + secret.

Test send

Before saving, use the Test send button. Enter your own email; the platform sends a test message with the current settings. If it doesn’t arrive within a few minutes, fix the config before saving — it’s much easier than diagnosing why nobody got the SLA breach notification.

Inbound mail

Keystone can also receive email — turning emails sent to helpdesk@<your-trust>.org into tickets. Configured separately under Inbound mail:

• A mailbox the platform polls (IMAP) or
• A webhook from the provider that pushes new mail (SES + SNS, Mailgun, etc.)

The polling/webhook lands the message, parses the headers, and creates (or threads onto an existing) ticket. Replies on the ticket go back via outbound mail to the same address.

Threading

Threading uses standard headers: Message-Id, In-Reply-To, References. Almost every mail client respects them. If you reply via the agent UI and the requester replies via their mail client, the thread holds together.

The exception is when a user starts a new thread by sending a fresh email referencing the ticket number in the subject. That’s parsed as a new ticket — confusion ensues. Train staff to “reply” to ticket emails rather than start fresh ones.

Why threading matters

A broken thread looks like “five separate tickets about the same issue from the same person” in the agent queue. Frustrating for the agent, frustrating for the requester, terrible for reporting accuracy.

If you’re seeing thread breakage, check: are reply-to and from on the same domain? Is the SPF/DKIM aligning? Check the deliverability log on the platform’s sent mail page.

Templates

Outbound emails use templates that respect the workspace branding. You can override individual templates (e.g. the new-ticket-confirmation email) per workspace. Don’t override unless you have a clear reason — the defaults are well-tested.