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 given 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 has accepted the email for delivery there are several things that may prevent the email from making its way to the recipient.

Occasionally, a server will provide what is known as a "bounce-back" email, letting the sending server know that the email can not be delivered and why. Many servers will not 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 have been 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. Both individual providers and the Federal Trade Commission have made efforts to reduce the overall effect of spam. However, the open nature of email as a communication protocol suggests that it will very likely always represent a problem.

Below, we'll explore some of the more common issues related to email deliverability in Zendesk Support.

This article contains the following sections:

• 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 being delivered to a specific domain, then there is a good likelihood 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/junk folder and never let you know, as this might only encourage you to try a different way.

Setting up an SPF or DKIM record

For Zendesk Support to send an email on your behalf, it is best for you to establish an SPF record as part of your domain's DNS record. This is a listing that permits us to send an email as if we were you. That is, 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 basically asks the recipient server to please lower their spam score for this transmission because you are aware of it and you want us to act on your behalf.

This can be tricky. Sometimes an email will arrive as expected at the inbox of one member of a company, but not at another. This is because there are cascading permissions and security settings within any company's server environment. The likelihood of you reaching the CEO is not the same as you reaching somebody in the marketing department where they may 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 that 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 like Gmail, Yahoo, MSN, etc. Because they receive so much more traffic, their spam filters have to be tuned differently than when an email is arriving from a single recognized domain. They generally do a tremendous job at this, but it is not uncommon to find a missing email in the spam/junk folder when it should have arrived in the inbox. This is easily corrected. Just have the user click on the "Not Junk/Spam" button, which recovers the email to the inbox and sends a message to the service they are using that they wish to receive these 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 our Operations team is always interested to discover a listing with any listing service (RBL, SORBS, DNSBl, etc.). Because many subdomains are using our outbound email servers, at any given time there is the risk of occasional misuse. Many times this is not intentional, but even an attempt to use Zendesk Support for something other than what it was designed, like an outbound pro-active marketing burst, can trigger a temporary spam listing.

As an example, let's say that 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 Junk" button, then there is a likelihood of one or more of our IPs getting listed, possibly causing delivery issues for other accounts. Because these ratings are dynamic 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 Ops team would want to look into.

When you get a bounce-back notice

It happens, to everybody, sooner or later. Don't panic! There is usually an easily discernible reason for the failure contained within the bounce-back message.

These can be a little bit daunting to learn to read, at first, but if you give it a try a couple of times it becomes much easier, as there are really only a few things you are looking for within them.

• What server was the notice generated from?
• What address was the attempted delivery made to?
• What was the SMTP failure code that was given?
• Is there a returned .eml? If so, what are the contents of that file?

• If the reporting server was Zendesk (as it is in the example above, evidenced by the zdsys.com found in the From: address), then this is very likely an outbound email notification that we attempted to send that was not received.
• If it 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, and that's where it should be. It might not have had anything at all to do with Zendesk, but is the result of a returned message that you would also find in your Support Address inbox, support@yourcompany .com (example).
• If the address that delivery was attempted to is non-existent, then the result would be the same. This can happen because a typo was introduced into the system at the time of entry, or it may be the result of spammers exploiting your online "Submit a Request" form. Here is the article that outlines how to manage spam. For the other, the inadvertent typo, you can verify the email address with any number of online tools. The one linked is my favorite. The information provided in that response can give you an idea of what the problem might be.
• The SMTP error code. This is a 3 digit code in 1 of 5 categories (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, hopefully. There is also a category of generic failures. 500, 550, 551, and 544 are all common permanent/fatal errors, meaning that the relay server has rejected the attempt and will not try again. Here is RFC 3463, which outlines this system. 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. You will generally only ever see 4s and 5s as bounce-back notices.
• The returned .eml file might be of interest to you and valuable in understanding what might have caused the failure. This will usually be the result of the bounce-back coming from Zendesk's servers. You can 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 also not entirely uncommon to get more than one bounce-back from the same email. This can make it seem as if the problem is much farther reaching than it is. If it is helpful to examine them in the order that they appear in your suspended queue, keep notes as to the intended recipients. This can sometimes calm what might otherwise be an unnerving experience.

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

These results are from a test domain that I use, so I knew that the domain was real, but the address was not. Common results are: User Unknown (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, then you may want to 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 be because of the IP that it was sent from, or relayed through, or even "spammy" links within a signature file.

If you believe that the email is legitimate, recovering an email from the suspended queue sends a message to Cloudmark letting them know, similar to clicking the "Not Spam/Junk" button in Gmail or Hotmail. You might not notice results on the first or second effort, but the system is self-learning and in time it should allow the email to come through (unless the nature of the sender is persistently more than acceptable sending behavior).

This was just one of many suspension examples. Another common cause of suspensions is that the incoming email is detected as being automated. It is best to reference our article on the process.

We hope this helps resolve some of the mystery around the processes which affect and allow the delivery of emails. If you believe that your issues fall outside of these areas, or within them but still problematic, then please contact Zendesk Customer Support.