Email addresses

An email address of the desk, like [email protected], lets requesters start a case by email. An email to it that isn't a reply to a case opens a new case in the address's unit, with the email's subject, text and attachments. You manage them under Platform → Email → Addresses.

[!NOTE] The desk doesn't run a mail server: the email service under Platform → Email → Receiving must deliver the address to the desk. See Setting it up first, and Getting the address to the desk below.

Adding an address

Choose New address and fill in:

Field	What
Address	The address the email service delivers to the desk. Lower case; an address can be on only one desk.
Unit	Where its cases go. The unit decides the brand on emails, who sees the cases, and who may send requests.
Name (optional)	For the list, like Customer support.
Priority and Labels	What the new cases start with.
Open cases from email	Off: email to it goes to Email review instead.

The list shows each address's unit and when it last received an email, so you can see that mail reaches the desk. Remove in the dialog removes it; cases it opened stay.

What happens to an email

Email to the address → Desk checks the email → A reply to a case? → Added to that case
Desk checks the email → Not a reply → New case in the address's unit → Confirmation to the sender
Desk checks the email → Sender looks forged, or too many → Email review
Desk checks the email → Sender not proven, or not let in by the unit → Held case, waiting for an agent

• A reply still goes on its case. An email that answers one of the desk's emails is added to that case, even when it is also sent to the address.
• The new case has the email's subject, its text with quotes and signature removed, and its attachments (the same checks as on the case page). It shows emailed and the address on the case page, and its source is Email in filters, automations and webhooks.
• The confirmation goes to the sender in the same conversation in their mail program, from the unit's brand. It's marked as an automatic answer, so another desk or an out-of-office doesn't answer it back. Answers to it, and to every later email, land on the case as email replies.
• Replies go back to the address. The confirmation and agent replies have the address as Reply-To, so the requester answers [email protected], not an address of the case's own. Cases from forms in a unit with an address do the same.
• People in copy follow the case, as they would in a mail program, when the sender's domain vouches for the email (DMARC, SPF or DKIM pass). The desk's own addresses are left out.
• Ignored: automatic replies, the desk's own email coming back, and email from one of the desk's addresses (a forward set up in a loop).

Who may start a case by email

The desk checks SPF, DKIM and DMARC on every email, as it does on replies.

The email	What happens
The sender's domain vouches for it, or a trusted forwarder saw it vouch	A case, like one from a form.
The sender's domain says it didn't send it (DMARC fails, or SPF fails without a valid DKIM signature)	Email review, marked Sender not verified.
Nothing vouches for the sender	A held case that waits for an agent to accept or reject it, with no confirmation until then. With Hold email replies whose sender isn't verified off (Platform → Email → Receiving), a case, but the confirmation doesn't repeat what they wrote.
The unit only takes requests from known contacts (Platform → Organization → Who can submit) and the sender isn't one	A held case: an email can't be refused back, so it waits for an agent.
More than 10 new cases within an hour from one sender	Email review, marked Too many.

In Email review, an email that asked for a new case shows New, to the address. Open case opens the case it asked for, as if it had gone through; Add to case adds it to an existing case instead. Such emails belong to no case yet, so only Platform Administrators see them.

Getting the address to the desk

The email service receives the domain (or subdomain) it is set up for. Two ways to use it:

• An address on the reply domain, like [email protected]. Nothing more to set up, but requesters see the subdomain.
• Your normal address, forwarded. Keep [email protected] in your mail system (Google Workspace, Microsoft 365 …), and have it forward to an address the email service receives, like [email protected]. Add [email protected] here: the desk recognises it in the email's To, and requesters' replies go back to it. Your other addresses on example.com are untouched.

Forward without changing the email: a forward that rewrites the sender (like a Google Group, for domains with a strict DMARC policy) hides who wrote. The two common mail systems:

Google Workspace

Use a routing rule that changes the envelope recipient. In the Admin console, go to Apps → Google Workspace → Gmail → Routing, and add a rule:

1. Email messages to affect: Inbound, and Internal - receiving so colleagues can email it too.
2. Envelope filter: tick Only affect specific envelope recipients, Single recipient, [email protected].
3. Also deliver to is not needed. Under Envelope recipient, tick Change envelope recipient and Replace recipient with the address the email service receives, like [email protected].
4. Account types to affect: if [email protected] is a user, alias or group, the matching type. If it is none of them, tick All inactive and unrecognized accounts; otherwise Google bounces the email as unknown before the rule runs.

Then add google.com as a trusted forwarder.

[!WARNING] Without the envelope filter, the rule sends everyone's email to the desk.

Microsoft 365

Use a mail flow rule that redirects the message. [email protected] must exist in Microsoft 365 (a shared mailbox is enough), or Exchange refuses the email as unknown.

1. In the Exchange admin center, go to Mail flow → Rules, and add a rule.
2. Apply this rule if: The recipient is [email protected].
3. Do the following: Redirect the message to the address the email service receives, like [email protected].

The shared mailbox stays empty: a redirect delivers only to the new address. Then add microsoft.com as a trusted forwarder.

With either, send a test email from your own mail program to the address, and check that a case opens. The list shows the last email it received.

Forwarded email and sender checks

A forward breaks SPF: the email now comes from your mail system's servers, not the sender's. Most senders also sign with DKIM, which survives a forward that doesn't change the email, so the desk still sees who wrote. For a sender without DKIM, the desk would see a forged email.

Mail systems that forward (Google Workspace, Microsoft 365, and email services like Cloudflare Email Routing) add an ARC seal: a signed note of what they saw when the email reached them. Under Platform → Email → Receiving, list the ones you use in Trusted forwarders, like google.com, email.cloudflare.net, separated by commas; a seal by a subdomain of one counts too. Only a Platform Administrator changes the installation's receiving settings, so ask one to add yours. The desk then accepts the sender when:

• every seal on the email is valid, and
• every seal from the newest back to the one that vouches is by a trusted forwarder: a seal by anyone else in between ends it, since they could have changed the email, and
• that forwarder saw SPF, DKIM or DMARC pass for the domain in the email's From.

Sender → Your mail system (seals: SPF passed) → Email service (seals) → Desk → Both trusted → A case
Desk → A seal by someone not trusted → Checked as without a forward

An email held as Sender not verified in Email review shows who sealed it on the way, newest first. Trust only the mail systems you forward through: a trusted forwarder's word is taken for the sender.

Sending from your own address

Replies already go back to [email protected]. To have the desk's emails also come from it, so From and Reply-To match:

1. Verify example.com with the email provider the desk sends through (Platform → Email → Sending). The provider gives the DNS records, usually an SPF include, DKIM keys and a return-path record; add them where the domain's DNS is.
2. Set the brand's From address to [email protected] (Platform → Brands), or the installation's Default sender for brands without one.

Emails then go out from [email protected], with the same address as Reply-To. If the domain's DMARC policy is p=quarantine or p=reject, every system that sends as example.com must be in its SPF record or sign with DKIM.

Through the API

The addresses are under /api/v1/email-addresses, for tokens with the email.settings permission. See API tokens.