Getting started with email - Part 2: Incoming email requests and notifications

Fastpath: Admin () > Channels > Email

In Part 1 of this getting started with the email channel guide, we explained essentials of how the email channel works. Here in part 2 we explain how incoming support requests via email are handled and how to customize the incoming email channel workflow.

• Choosing the email addresses you want to use to receive support requests
• Understanding how incoming emails set the ticket requestor
• Understanding how incoming emails are matched to tickets
• Spam filtering and suspended tickets
• Controlling who can use email to create tickets
• Managing user accounts created by email requests
• Disabling rich content in incoming email notifications
• How a customer’s language is detected
• Including other people in a support conversation via CC

In parts 3 and 4 of the getting started guide, you’ll learn how to customize and manage your outgoing email notifications and understand and handle common email channel problems.

• Part 3: Outgoing email notifications
• Part 4: Understanding and troubleshooting common email channel problems

Choosing the email addresses you want to use to receive support requests

One support address is created for you by default when you create your Zendesk Support account. This system support address is [e-mail] (where, of course, myaccount is the name you selected for your Zendesk Support account). However, you can provide your users with alternative email addresses for submitting tickets by adding other support addresses and by forwarding email into your Zendesk Support account from external email systems.

You can receive support requests through multiple email addresses simultaneously. The email addresses you use to receive support requests in Zendesk Support are referred to as support addresses. If you use multiple support addresses, one of them is set as the default support address.

Here are the things you can do to customize the email addresses that you use to receive support requests using support addresses.

Anatomy of an email address

Before showing you how you can customize your support email addresses, here’s a quick refresher showing the elements of an email address.

The friendly name (referred to in Zendesk Support simply as ‘name’) is optional and is, usually, the full name of your business or organization. The username (technically known as the local-part) is the word that precedes the @ character. The domain can be either your Zendesk Support domain or an external domain. You’ll see how you can modify these in the following sections.

Changing the username of your default support email address

You can easily create new support email addresses if you want variations of the email username, as shown here:

By using different email addresses for different situations, you can manage and track your tickets based on the email address at which the support request was received. For example, if your end-users send email to [e-mail], you can create a trigger to route tickets received at that address directly to the Sales team. You can also track, via views and reports, tickets received at those different addresses.

Zendesk Support provides a simple wizard for creating new support email addresses. For more information, see Using Zendesk email addresses as support addresses.

Allowing any username to be a valid support email address

You can also allow any variation of the username to be a valid support address. For example, if a customer misspelled your support email address (for example, [e-mail]) the email can be accepted and a ticket created. These types of variations are referred to as wildcards.

Wildcards are there as a way to handle incoming support address errors (as in the example above). When they are received, the default support address replaces the incorrect address. Also, wildcard addresses cannot be used in business rules.

To enable wildcards for incoming support requests, see Accepting wild card email addresses for support requests.

Using an external email domain instead of your Zendesk Support email domain

You can also add external email domains as support email addresses in Zendesk Support. You can forward all the email that’s coming into your external email account (Gmail, for example) into Zendesk Support. Your customers can continue to use the same email address you had before you starting using Zendesk Support and there’s no ‘Zendesk’ in the email Send To and Reply From addresses.

There are three steps to using an external email domain.

1. First, you need to set up email forwarding by configuring your email account outside of Zendesk Support (see Forwarding incoming email to Zendesk Support).
2. Then once that’s done, you create a new external email-based support address in Zendesk Support (see Adding an external support address).
3. Finally, you need to add an SPF (Sender Policy Framework) record to verify that Zendesk can send outgoing email on behalf of your email server (see Setting up SPF for Zendesk to send email on behalf of your email domain).

Agent email forwarding and redirecting

Setting up a support email address from an external email system allows you to automatically forward customer email into your Zendesk Support account (see Adding an external support address). It’s also possible do this manually, for one-off support requests that you may receive at an email address that has not been added as a support address. You do this by forwarding or redirecting the email.

You can allow your agents to forward email to your support address to create a ticket on behalf of the original sender. To do this, you need to enable the email forwarding option for agents (see Enabling the forwarding option for agents in Zendesk Support). Agents can also set the original sender of the email as the requester using a simple text command in the forwarded email (see Specifying the requester in the forwarded email).

The other option is to redirect the email using the email application where it was received. For example, in Microsoft Exchange an email message can be redirected using the Actions > Resend this Message command. For more information about redirecting, see Redirecting an email.

Understanding how incoming emails set the ticket requestor

The email body is not used in any way to assist in identifying the requester of a ticket. Zendesk uses information from the email headers to determine ticket requester. Specifically, the main way a requester is set is by the reply-to: header flag. If the reply-to: header is not present, from: is used in its place. This functionality is hardcoded into the system and unchangeable.

Agents can use the mail API #requester syntax to set the requester on a ticket. For more information, see the article: Using the Mail API to update ticket properties from your inbox.

For more information on email threading, see the articles: Why are incoming emails threading to the wrong ticket? and Ticket threading issues.

Understanding how incoming emails are matched to tickets

As mentioned earlier, a ticket in Zendesk Support is similar to a threaded email conversation. Keeping the thread together as part of the same ticket is done using references embedded in both the outgoing and incoming email notifications. For example, when a customer replies to an email notification, the reply includes references to the ticket so that the incoming email can be matched to the correct ticket in Zendesk Support.

Email notifications include ticket references in the following places:

• A reply back from a customer contains ticket references in the email header using In-Reply-To and References
  Note: You can view the source (including the header) of any email that you receive (see Viewing the HTML and original source for incoming tickets).
• The email body includes a hidden reference to the ticket
• The Reply To email address includes the ticket ID, if you are using an address in your Zendesk domain. For example:
  • MondoCam Support <[e-mail]>

Note: If you're using an external domain for email, the ticket ID is not included in the Reply To email address.

After an email conversation has been started and ticket references have been embedded into the thread, any replies back and forth are tied to that ticket. If you wanted to create a new ticket from that email thread (for some reason), you’d need to copy the content of the email message and create a new email message. Forwarding the email thread to one of your other support email addresses will, because of the embedded ticket references, tie it back to the original ticket.

Spam filtering and suspended tickets

Zendesk uses spam filtering to prevent your Zendesk Support account from getting cluttered with bogus tickets. Spam email is caught and may be held in the suspended tickets queue or completely rejected (meaning that you’ll never see them) if there's a high probability that the email is spam.

Keep in mind that spam filtering is not perfect and that legitimate support requests may end up in the suspended tickets queue. When that happens, you can manually retrieve them. For a detailed explanation of why some incoming email ends up in the suspended tickets queue, read What does "Detected as spam" mean?.

All of your suspended tickets are listed in a system-generated view that will appear in your list of views for the first time when a suspended ticket is created. Using this view, you can review the emails and accept them as legitimate tickets or reject them as spam.

For more information, see Understanding and managing suspended tickets and spam for more details.

Controlling who can use email to create tickets

Another way to prevent bogus or unwanted tickets, is to prevent specific users or groups of users from creating tickets with email. To do this, you add their email domains or individual email addresses to a blocklist. This causes their emails to be suspended or completely rejected (not even included in the Suspended Tickets view).

If you want to allow exceptions to your blocklist, if for example specific users within a blocked email domain are allowed to submit support requests via that email domain, you can add their email addresses to a allowlist. For more information, see Using the allowlist and blocklist to control access to your Zendesk.

You can also set up a closed Zendesk where only the users that you add to your Zendesk Support account can submit support requests. For more information, see Permitting only added users to submit tickets.

When you place access restrictions like this on your Zendesk Support account, you’re creating a restricted account. You can read more about this in Configuring how end-users access and sign in to Zendesk Support.

Managing user accounts created by email requests

All of the customers that you support have a user account in Zendesk Support. Unless you restrict or close access to your Zendesk Support account, new user accounts are created when you receive a customer’s first support request via email (this is not true for suspended or rejected email). A customer’s user account tracks of all their support requests, contains their contact information, and all of the data that’s gathered in the course of interacting with them.

Because most people use more than one email address, you may receive support requests from an existing customer who has used one of their other email addresses. When this happens, a new and separate user account is created. Because you don’t want customers to have duplicate accounts, you can merge the newly created account into the customer’s original user account (see Merging a user's duplicate account).

Using more than one email address is supported, as long as the customer’s other email addresses are also added to their user account. Customers can add other email addresses to their user account themselves, if you’ve given them access to it via the customer portal you can provide using Zendesk Guide. They can view and edit their own profiles.

One of their email addresses is set as their primary email addresses, and other contact email addresses that are added to their profile route support requests from those email addresses to their user account. All outgoing email notifications to customers use the primary email address.

Assigning email requesters to organizations

When you receive an email support request from a customer for the first time, which creates their user account, you can also assign that customer to an organization based on their email domain. For example, you might want to segment your customers based on the company the work for, which you’ll know by their email domain. This is referred to as user mapping and an administrator can set this up by editing an organization's settings.

For more information, see Automatically adding users to organizations based on their email domain.

Disabling rich content in incoming email notifications

By default, Zendesk Support uses the rich content formatting contained in incoming HTML-based email messages (bold, italic, underline, tables, and so on). The rich content is retained and displayed in tickets. You have the option of using the plain text version of the email message instead if you prefer. For more information, see Disabling rich content in incoming emails.

How a customer’s language is detected

Zendesk Support provides a number of ways for identifying a customer’s language and replying to them in their language. A language setting is included in the user profile (for users that are already registered into your Zendesk Support account) and we also detect their language from incoming email support requests from new customers. For more information, see Configuring Zendesk Support for your locale and language and Detecting an end-user's language from an email message.

Including other people in a support conversation via CC

Support conversations aren’t always limited to the customer who needs support and the assigned agent to provide that support. It’s also possible to include and to notify other people.

You can allow agents and your registered and signed-in customers to add CCs to tickets. When agents add other agents as CCs, those agents receive email notifications for all ticket updates and new public and private comments added to the tickets they’ve been CC’d on. Any customers that have been CC’d only receive email notifications for public ticket updates and public comments.

CCing others has its restrictions and can also involve some complexity because of increased number of recipients. For more information about CCing other people, see Configuring CC permissions and notifications.

You can also include other people on a ticket using @mention within the body of a ticket comment (rich text formatting must be enabled). For more information, see Copying (CC) or @mentioning someone else on a ticket.