Issue symptoms
- An email message was not delivered to or from Zendesk.
- An email was detected as spam.
Resolution steps
This article covers some of the more common issues related to email deliverability in Zendesk Support.
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.
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:
3 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.
When you see the error message "the uploaded file exceeds the upload_max_filesize directive in php.ini", it means that the file you are trying to upload is larger than the maximum file size limit set in the php.ini file on your server.
To fix this error, you can try the following steps:
Increase the maximum file size limit in php.ini:
Locate the php.ini file on your server. This file is usually located in the root directory of your website or in the /etc/ directory.
Open the php.ini file in a text editor.
Search for the "upload_max_filesize" directive and increase its value to a higher value, e.g. "upload_max_filesize = 64M" for a maximum file size limit of 64 megabytes.
Save the changes to the php.ini file and restart your web server.
Edit the .htaccess file:
If you do not have access to the php.ini file, you can try editing the .htaccess file instead.
Add the following line to your .htaccess file: "php_value upload_max_filesize 64M" (or any other value you want to set as the maximum file size limit).
Save the changes to the .htaccess file and try uploading the file again.
Contact your hosting provider:
If you are unable to edit the php.ini or .htaccess files, you may need to contact your hosting provider and ask them to increase the maximum file size limit for you.
By following these steps, you should be able to fix the "the uploaded file exceeds the upload_max_filesize directive in php.ini" error and upload your files successfully.
Please sign in to leave a comment.