The way it’s commonly used, email is 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 a number of 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 there are steps that 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.
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 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 gives us permission to send 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 isDKIM. 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 then when 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 at 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 blacklisted
Less likely, though still an occasional issue, is when Zendesk’s servers become blacklisted. This can happen for a number of reasons and our Operations team is always interested to discover a listing with any listing service (RBL, SORBS, DNSBl, etc.). Because there are many subdomains 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.