Email Forwarding Setup

QueueDesk supports inbound email forwarding, turning incoming support emails into structured tickets and updates automatically.

1. Setting Up Inbound Forwarding

Every QueueDesk workspace has a system email domain allocated: {slug}@mail.queuedesk.com (e.g. acme@mail.queuedesk.com).

• •To route your company support email (e.g. support@yourcompany.com) into QueueDesk:

1. Open your corporate email hosting provider (Google Workspace, Office 365, AWS WorkMail, etc.).

2. Create a forwarding rule that forwards all incoming emails sent to support@yourcompany.com to {slug}@mail.queuedesk.com.

3. Validate the verification code sent by your email host (it will appear as a ticket in your QueueDesk agent dashboard).

2. Outbound Domain Branding & DKIM

By default, outbound notifications are sent from support@queuedesk.com. To send emails from your own domain (e.g. support@yourcompany.com):

• •Navigate to Settings → Email (/admin/settings/email).

• •Register your support email domain.

• •QueueDesk will generate 3 DKIM CNAME records.

• •Add these CNAME records to your DNS provider (Cloudflare, GoDaddy, Route53, etc.).

• •Once DNS propagates, click Refresh status. Verification usually completes within minutes of the records going live.

Add the DNS records promptly

We only search for your records for 72 hours after you register the domain. If the records

go in after that — common when an MSP or a change-controlled DNS process has to make the

change for you — checking stops and the status shows Failed even though your DNS is

perfectly correct.

This is recoverable and costs you nothing:

• •Once the 3 records are in place, the button changes to Re-run verification. Click it.

• •Your DNS records stay the same. The 3 CNAMEs you already published remain valid — there

is nothing to re-enter and nothing for your DNS provider or MSP to redo.

If you know the DNS change will take a while to schedule, it's simplest to register the

domain in QueueDesk at the point your provider is ready to add the records.

3. Ticket Type on Inbound Email

Unlike the agent dashboard, the employee portal forms, and QueAssist chat, an inbound email has no type picker — there's nothing in an email for a sender to choose from. QueAssist reads the subject and body and classifies the ticket as an Incident, Service Request, Problem, or Change before the confirmation reply goes out, so the ticket number the sender sees is already final. See AI Triage & Categorization for how this compares to every other channel.

4. Email Threading

QueueDesk threads incoming email replies into existing tickets using:

• •In-Reply-To and References RFC headers.

• •Ticket number fallback checking in the subject line (e.g. matching Re: [INC-1002] original subject).

• •Thread matching ensures employees and agents can reply directly from their standard email client (like Gmail or Outlook) and have the full conversation recorded inside the ticket timeline.

5. Sender Identity

Under Settings → Email → Sender identity, separately from DKIM domain verification, you can set:

• •Reply-To email — where employee replies land if they hit "reply" in their inbox instead of the portal (defaults to QueueDesk's own address if left blank).

• •Sender display name — what shows as the "from" name in an employee's inbox (defaults to your workspace name).

6. Notification Routing and Templates

Under Settings → Email → Notifications, choose who receives ticket alerts and customize each email:

• •New tickets — notify all agents and admins, or follow group visibility.

• •Requester replies — notify the assignee and group, or the assignee only. An unassigned ticket falls back to its group.

• •Resolved reply — reopen the ticket or keep it resolved while adding the reply.

• •Resolution email — turn the requester email on or off.

Each template supports tokens like {{ticketNumber}}, {{title}}, {{requesterName}}, {{agentName}}, {{replyBody}}, {{ticketUrl}}, and {{orgName}} — plus a Preview using a sample ticket so you can check formatting before saving. Use Reset to default to undo any customization on a single template.

Closed tickets stay closed when someone replies. QueueDesk still adds the

message and alerts the assigned agent.

Forwarded messages and the requester

QueueDesk sends agent replies to the original requester when a forwarded

message supplies one clear Reply-To or forwarded From header. If the

message contains several possible addresses, QueueDesk does not guess: the

ticket asks an agent to confirm the requester email before replying.

7. Approval Emails

Approvals send their own emails, and they aren't in the template list above — there's nothing to configure. They still carry your logo, colours and sender identity, exactly like every other QueueDesk email.

Decision emails include the approver's comment and the date and time of the decision. Whether the employee who raised the ticket also sees the comment is up to you — see Closure Rules, Approvals & CSAT Surveys for that setting and the full approval flow.

8. Attachments on Emailed Replies

Files attached to an inbound email are saved onto the ticket and shown under the email that carried them, with no size cap or file-type restriction — a 9 MB scan or a .docx arrives intact. Outbound notifications list the filenames and link to the ticket rather than carrying the files. See Attachments & Screenshots.

9. Troubleshooting: mail leaves your server but no ticket appears

Forwarding and redirecting are both supported, from Microsoft 365, Google Workspace and gateways such as Proofpoint, and on both address shapes — your bare workspace address and any department mailbox. If your mail logs say "Delivered" and no ticket appears, check these in order.

1. Confirm the forwarding target is exactly right. The most common cause is a typo in the destination address. It must be your workspace address as shown at Settings → Email → Forwarding, and for a department, the tagged form with the correct tag:

{slug}@mail-sg.queuedesk.com          bare workspace address
{slug}+finance@mail-sg.queuedesk.com  Finance department

A wrong tag is not an error — mail on an unrecognised tag still becomes a ticket on your bare workspace address, so it lands in your catch-all queue instead of the department's. A wrong slug delivers nowhere.

2. Check the ticket isn't in a queue you weren't looking at. A department mailbox routes to that department's group. If you have only show tickets in my groups enabled at Settings → Groups, an agent who isn't a member of that group cannot see those tickets at all. Check as an owner or admin, who always see everything.

3. Look for it under the right department. If the tag matched, the ticket is in that department's queue in the sidebar, not the general list.

4. Genuine auto-replies are refused on purpose. Out-of-office replies, delivery failure notices and bounces will not open a new ticket, though they are still added to a ticket that already exists. Automated reports — monitoring alerts, quarantine digests, invoice notifications — are fine and do become tickets.

5. Don't forward QueueDesk's own emails back in. A rule that forwards everything from a mailbox QueueDesk also sends from will feed our notifications back to us. We detect and discard those, so they cost you nothing, but if you have a rule that copies your entire mailbox in, exclude messages from your own support address.

If mail still doesn't arrive, send us the message's Message-ID and the time it was sent, and we can trace it through the pipeline to the exact step.