Common issues with email deliverability

Email is commonly used as a non-confirming message delivery protocol. This means that there is no guarantee that any email sent from you will be delivered to its intended recipients. Delivery is based on assumption and acceptance by the relay server to complete the function. Additionally, once the relay server accepted the email for delivery there are several things that may prevent the email from making its way to the recipient.

Occasionally, a server provides a bounce-back" email, letting the sending server know that the email can not be delivered and why. Many servers don't provide these as part of an effort to provide potential spammers with as little information as possible about their internal processes.

With a proliferation of spam emails, an increasing number of ISPs were forced to implement more stringent restrictions on delivery, as well as focus more on filtering out spam traffic. This makes it increasingly difficult for them to effectively do their jobs without occasionally suspending a legitimate email along the way. Luckily, 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 protocol suggests that it will very likely always represent a problem.

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

Problems with sending email to a specific domain or user

If your emails are not delivered to a specific domain, it is likely that they are being blocked as spam. Depending on how the recipient server is configured, you may or may not receive a bounce-back notification in your suspended queue. The reason for this is that if a server suspects that you are trying to get unauthorized communications to somebody within their organization, they will suspend, reject, or route your email to a spam folder without notification. Notifications of these unauthorized notifications may only encourage you to try a different way.

Setting up an SPF or DKIM record

For Zendesk to send an email on your behalf, it is recommended to establish 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 outside of your domain, they run a quick check to make sure that you are aware of this and 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 will arrive as expected at the inbox of one member of a company, but not at another. This can occur because there are cascading permissions and security settings within any server environment of a company. 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 having 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, as confidence in the email receipt is verifiable.

Working with free online email services

An additional variable in this equation occurs when you are sending to one of the free online email services, for example, Gmail, Yahoo, and MSN. These email services receive more traffic, so their spam filters have to be tuned differently than when an email arrives from a single recognized domain. They generally do a good job at this, but it is not uncommon to find a missing email in the spam folder when it should have arrived in the inbox. Have the user click on the "Not spam" button to recover the email to the inbox. The recovery action will send a message to the email service that they wish to receive emails from this sender.

When Zendesk's servers become blocked

Less likely, though still an occasional 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, for example, RBL, SORBS, or DNSBl. Many subdomains use the outbound email servers of Zendesk, at any given time there is the risk of occasional misuse. Many times this is not intentional, but even an attempt to use Zendesk for something other than what it was designed, like an outbound pro-active marketing burst, 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, possibly causing delivery issues for other accounts. These ratings are dynamic and they often don't last very long, as there is much more legitimate email going out and being received, but the effects can still be prohibitive and something that our team would want to look into.

Use the Zendesk Status page to stay informed on service incidents.

When you get a bounce-back notice

There is usually a discernible reason for the failure contained within the bounce-back message. Further information helps to understand the reason for the issue.

• The server from which the notice was generated.
• The address to which the attempted delivery was made.
• The SMTP failure code.
• If there was a returned .emlfile, the contents of that 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 came through your external support address, forwarded on to Zendesk Support, and ended up in your suspended queue because it is an automated email. It may not be related to Zendesk, but is the result of a returned message that you can also find in your support address inbox, [e-mail].
• If the address that delivery was attempted to is non-existent, then the result would be the same. This 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. In the example above 550-5.5.1, the three numbers represent [class].[subject].[detail]. The classes are 2: Success, 4: Temporary Failure, 5: Permanent/Fatal failure. 4s and 5s results are shown as bounce-back notices.
• The returned .eml file is valuable in understanding what caused the failure. This is the result of the bounce-back coming from Zendesk's servers. Use this to determine what ticket experienced the problem. If a correction in the email address needs to be made then that can happen easily, and another update will attempt another outbound notice.

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, keep notes as to the intended recipients. 

Below is an example response from the email verification link. (Here is a different, though similar site):

These results are from a test domain. The results show the domain is real, but the address is not. 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 provider.

Detected as spam

This affects your incoming email. This means that one of our spam detection system's thresholds was exceeded by a component on the incoming email. This can occur if the IP that the email was sent from or if "spammy" links within a signature file.

Recovering an email from the suspended queue sends a message to our spam filtering service that you believe the email to be legitimate.  This action is similar to clicking the "Not Spam/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.  

This was just one of many suspension examples. Common causes of suspensions can be found in the article: Causes for ticket suspension.

For more information, see the article: Email troubleshooting guide.