Email

For whoever is running the desk.

Email is two separate jobs: sending (notifications, replies, campaigns) and receiving (clients answering, or writing in). You can do either without the other.

Sending

How it is configured

• Settings → Email: the desk-wide mode, and how long inbound originals are kept.
• Brand → Email: the identity clients see: from-name, from-address, and either an SMTP server or one of the brand’s own mailboxes to send through.

Sending through a mailbox is usually what you want when you have one: Google and Microsoft mailboxes send through the provider with the same sign-in, the provider keeps a copy in Sent, and the address clients see matches the address they can reply to. It falls back to the brand’s SMTP if the mailbox is switched off or signed out, and “Send test” uses whichever is active.

Deliverability

The desk hands mail to your relay; everything after that is domain reputation. Set SPF, DKIM and DMARC for every brand’s from-address before you go live. A desk that sends a few thousand mails a month from an unauthenticated domain will be filtered, and the symptom is “clients say they never got it”.

What gets sent

New tickets, replies, closures, rating prompts, mentions, reminders you asked to be emailed, mass-mail campaigns, status updates, report verification. Almost all of it is a queued job: no worker, no mail.

Every message carries a header marking it as ours, and machine-made mail is Auto-Submitted: auto-generated, which is what stops two desks talking to each other forever.

Templates

Per brand: subject and Markdown body with placeholders, and a footer. The brand’s colour and logo are applied, with a neutral fallback where none is set. Preview and send-to-self before you commit.

The reply delay

Outgoing staff replies can be held for a configurable number of seconds so a reply can be recalled, the “sent it to the wrong ticket” window. Set it to something small (10–30s); it delays nothing else.

Receiving

Connecting a mailbox

Brand → Mailboxes → add one per address you want read:

• Plain IMAP with a host and a password.
• Microsoft 365 or Google Workspace by signing in. The brand registers its own OAuth client, because a tenant or Workspace only authorises its own accounts. The desk refreshes the tokens.

Each mailbox has its own page with Connection, Routing, New tickets and Status, a connection test, and a polling switch. Mailboxes are polled every minute by the scheduler.

What happens to a message

1. Is it automated? Auto-replies, out-of-office, bounces and list mail are dropped without a ticket, recognised by headers and by subject in seven languages.
2. Is it ours? Mail from a brand’s own sender address, a department address, any mailbox or alias, or carrying the desk’s own header is dropped. This is the loop guard.
3. Does it carry a reply token? Then it belongs to that ticket, full stop. The token is in the Reply-To address (support+t-NUMBER-TOKEN@) or in the subject for mailboxes that cannot sub-address. A token reply reopens the ticket and fires the usual notifications and rules.
4. Does it thread by Message-ID onto something we sent? Then it joins that ticket, but as a sender, not as the account holder, unless the address is one the ticket already knows.
5. Otherwise it opens a new ticket in the department mapped to the address it was sent to, or the mailbox’s default, as an unlinked guest sender. Or, with “open new tickets” off, it is declined with a branded email, at most once a day per sender.

A sender address on its own never links a message to an account. Headers can be forged and addresses are shared; see Clients for why this matters more than it looks.

Routing

• A department’s public address routes mail sent to it into that department.
• A mailbox’s aliases map any other address to a department.
• A rule on “ticket opened” can move it by content afterwards.

Cleaning the message

Bodies are converted from HTML to Markdown and stripped of quoted history and signatures, per mail-client dialect (Gmail, Outlook desktop and web, Apple Mail and iOS, Thunderbird, Yahoo, Proton, Android) in English, German, French, Spanish, Italian, Dutch and Portuguese. Attachments go through the usual file checks.

The original is kept, so if a cleaner gets something wrong you can re-import: from the ticket (Re-import, beside “via email”) or in bulk with php artisan mail:reimport --days=30. Originals are pruned after the retention you set (default 90 days).

Sender authentication

Per mailbox: when the receiving server reports that the sending domain disowns a message (DMARC fail, or SPF fail with no DKIM), the mailbox can reject it, accept without sending a confirmation, or accept as normal. Token replies are never affected; they carry their own proof.

Flood protection

One address may open at most five tickets an hour by email; replies are unaffected. Decline messages go out at most once a day per sender.

After import

Per mailbox: leave the message on the server, mark it read, move it to a folder, or delete it. The desk keeps its own copy either way.

Watching it

• Logs → Email: everything sent, with its state.
• Logs → Inbound: everything received, the outcome, the drop reason, the ticket it landed on, and the original .eml one click away. A ticket that arrived by email shows a “via email” badge.
• Administrators are alerted when a mailbox stops polling for fifteen minutes, which is the failure that otherwise goes unnoticed for a week.

Layouts that work

• One address for everything.
• One inbox, several addresses routed to departments (billing@ → Billing).
• A mailbox per department.
• Replies only: clients open tickets in the portal and answer by mail.
• Different providers per brand.

Outgoing mail replies to the department’s own address when a mailbox serves it, so the conversation stays in one place.