Issue symptoms
- An email message was not delivered to or from Zendesk.
- An email was detected as spam.
- I received a bounce-back email notification.
Resolution steps
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
- When you get a bounce-back notice
- 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. Click the following sections to see solution steps for your email setup.
Setting up an SPF or DKIM record
Click this section for an explanation of SPF and DKIM records and their purpose.
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 email services
Click this section if you or the recipient uses a free email service, such as Gmail.
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
Click this section if multiple emails are not delivered from your Zendesk account to various recipients.
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.
When you get a bounce-back notice
There is usually a reason for the delivery failure contained within a bounce-back message. The following information helps to understand the cause for the issue.
- The server from which the notice was generated.
- The address to which the attempted delivery was made.
- The SMTP failure code.
- The contents of the
.eml
file if there was a returned.eml
file.
- If the reporting server was Zendesk as in the example above, the
From:
address shows zdsys.com. This means that Zendesk attempted to send an outbound email notification but it was not received. - If the reporting comes from a different server, then there is a likelihood that this bounce-back email came through your external support address, forwarded to Zendesk Support, and ended up in your suspended tickets because it is an automated email. It may not be related to Zendesk, but is the result of a returned message. If this is the case, you can also find the email in your external support address inbox,
support@yourcompany.com
. - If the recipient email address is non-existent, then the result would be a bounce-back email message. This sometimes happens when a typo was introduced into the system at the time of entry. You can verify the email address with any number of online tools.
- This non-existent error may also be the result of spammers exploiting your online contact form. For more details on how to manage spam, see the article: Marking a ticket as spam and suspending the requester.
- The SMTP error code. This is a three-digit code in 1 of 5 categories ranging from 100-500, then a hyphen, followed by three numbers separated each by decimal points. Each number gives more granular insight into the nature of the failure. The reporting also shows a category of generic failures. 500, 550, 551, and 544 are all common permanent or fatal errors. This means that the relay server has rejected the attempt and will not try again.
- For more information, see the reference guide: RFC 3463. The visual example in the screenshot above lists 550-5.5.1 in the screenshot of the email. The three numbers represent
[class].[subject].[detail]
. The classes are 2: Success, 4: Temporary Failure, 5: Permanent or Fatal failure. The results from 4s and 5s are shown as bounce-back notices.
- For more information, see the reference guide: RFC 3463. The visual example in the screenshot above lists 550-5.5.1 in the screenshot of the email. The three numbers represent
The returned .eml
file is particularly valuable in understanding what caused the failure. This is the result of the bounce-back coming from Zendesk's servers. Use this information to determine which ticket experienced the problem. If a correction in the email address is necessary, make the correction to the email and make a public ticket update to attempt another outbound email to the new address.
It is not uncommon to get more than one bounce-back from the same email. It is helpful to examine the bounce-back messages in the order that they appear in your suspended queue, and keep notes regarding the intended recipients.
Below is an example response from an email verification link.
These results from this example are from a test domain. These results show that the email domain exists, but the address does not exist. Common results are:
User Unknown
: a bad email address.Host Unknown
: domain does not exist.Mail Could Not Be Delivered
: possibly a server outage.
Test your own email address and you should see a blue result. If not, consult with your email admin or email service provider.
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.
It can take a few recovery attempts as the system is self-learning and should allow the email to come through. However, there are several common causes of ticket suspension which will always be flagged as a suspended ticket. For more information on these causes, see the article: Causes for ticket suspension.
For more information, see the articles:
2 Comments
Hi there! We suggest Email Tracking app to bypass a non-confirming message delivery protocol. It helps to track the delivery of emails, see the exact time the email opens, and see the best time for reply. Also, there’s a statistics tab where you can check an email performance converted in charts. The reports are divided into blocks with numerical indicators such as Average Bounce Rate, amount of sent/open emails, Opened average Rate, and Average Time from Sent to Open. Besides, it is compliant with GDPR and CCPA.
But the real problem with Zendesk is that we DON'T get notifications when an email fails to deliver, rendering impotent any attempt to assure confirmation of emails.
Please sign in to leave a comment.