- An email message was not delivered to or from Zendesk.
- An email was detected as spam.
This article covers some of the more common issues related to email deliverability in Zendesk Support.
- Problems with sending email to a specific domain or user
- Setting up an SPF or DKIM record
- Working with free online services
- Troubleshooting when Zendesk's servers become blocked
- Detected as spam
Email is a common non-confirming message delivery protocol. This means that there is no guarantee that any email you send will be delivered to its intended recipients. The delivery is based on assumption and acceptance by the relay server. Once the relay server accepts the email for delivery there are still several variables that can prevent the email from reaching the recipient.
Occasionally, an email server provides a bounce-back email which lets the sender know that the email could not be delivered and the reason for the failure. Many servers don't provide bounce-back emails as part of an effort to hide information about their internal processes from potential spammers.
Due to the high volume of spam messages through email, an increasing number of internet service providers implement stricter restrictions on email delivery to filter out this spam traffic. This makes it difficult to effectively filter spam without occasionally suspending a legitimate email.
Fortunately, these systems can be self-correcting and some steps can be taken to assist them in the difficult job that they do. The open nature of email as a communication method suggests that spam will very likely always represent a problem.
Problems with sending email to a specific domain or user
If your emails are not delivered to only one specific domain, such as a company email address, it is possible that they are blocked as spam. Based on how the recipient server is configured, you may or may not receive a bounce-back notification in your suspended tickets.
If a server suspects that you are trying to send unauthorized communications to someone within their organization, the server may suspend, reject, or route your email to a spam folder without notification.
Setting up an SPF or DKIM record
For Zendesk to send an email on your behalf, it is recommended to set up an SPF record as part of your domain's DNS record. SPF records are a listing that permits Zendesk to send an email as if Zendesk were you. For example, when an email arrives at another server from an IP address outside of your domain, the server runs a check to make sure that you approve the process. An SPF record asks the recipient server to lower their spam score for this transmission because you are aware and you want Zendesk to act on your behalf.
Sometimes an email arrives as expected in the inbox of one member of a company, but not for another member. This can occur because there are different permissions and security settings within any company's email server. For example, the likelihood of reaching the CEO is not the same as reaching somebody in the marketing department. Marketing departments typically expect unsolicited emails from a much wider variety of vendors and contacts.
An alternative to an SPF record is DKIM. This protocol performs a very similar role, except that it signs the outbound email with an encrypted key. The other half of that key is provided by your domain so when those keys match, the likelihood that the email will be accepted is greatly increased because the confidence in the email receipt is verifiable.
Working with free online services
Free email services such as Gmail, Yahoo, or MSN add an additional variable for email delivery. These email servers receive more traffic, so their spam filters are tuned differently than when an email arrives from a single recognized domain. These email services generally do a good job at filtering spam, but occasionally you may find a missing email in the spam folder. Have the user check the spam folder and click on the "Not spam" button to recover the email to their inbox. This recovery action will send a message to the email service that the recipient wishes to receive these emails, and helps prevent the problem from occurring again.
Troubleshooting when Zendesk's servers become blocked
A less likely email delivery issue is when Zendesk's servers become blocked. This can happen for several reasons and the Zendesk Operations team is always interested to discover a listing with any listing service. Some examples of listing services include RBL, SORBS, and DNSBl.
Many subdomains use the outbound email servers of Zendesk, at any given time there is the risk of occasional misuse. An attempt to use Zendesk for something outside of its intended use, such as a large scale email marketing campaign, can trigger a temporary spam listing.
For example, an account sends out bulk emails from their account, letting their customers know about a new feature or product they offer. If they sent out 1000 emails and 10 of those people decided that they didn't ask for this email and they clicked on the "This is spam" button, then there is a likelihood of one or more of our IPs getting listed. This can cause delivery issues for other accounts.
These ratings are dynamic and often don't last long, because there are more legitimate email messages going out and being received than illegitimate email messages. However, the effects can still be prohibitive and this behavior is something that our team would want to investigate.
Use the Zendesk status page to stay informed on service incidents.
Detected as spam
This affects your incoming email. This means that one of Zendesk's spam detection thresholds was exceeded by a component on the incoming email. This can occur if the IP address that the email was sent from is flagged as spam, or if "spammy" links are within a signature file.
If you recover an email from the suspended queue, this action sends a message to our spam filtering service that you believe the email to be legitimate. This action is similar to the function of the "Not Spam or Junk" button in your email.
For more information, see the articles: