Protecting your company from spam and abuse is inevitably a task all companies are confronted with. While there is no silver bullet to stop all spam, there are some commonly used options that can help.
To ensure your account is as spam-free as possible, applying active protections to forms, emails and API calls that send to your account should be maintained. This article describes some great methods for protecting your account.
This article contains the following sections:
- Using CAPTCHA on forms
- Protecting your domain from email abuse, via SPF, DKIM and DMARC records
- Zendesk Support-specific features
- Further Reading
Using CAPTCHA on forms
Using a "Completely Automated Public Turing test to tell Computers and Humans Apart" (better known as CAPTCHA) is touted as one of the best ways to prevent incoming spam on any sort of public facing submission to your system. This presents a challenge to anyone submitting a ticket before they are able to successfully submit. In many cases, this will outright stop any attempts to abuse your system.
Within Support, this is natively supported, through the use of Google's ReCAPTCHA. This feature is enabled by default.
It's highly recommended to implement a CAPTCHA solution on any public facing submission page, to deter abuse. If you're concerned about deterring customers, you may want to consider invisible reCAPTCHA or similar solutions.
If you're looking for other forms of webform protection, there is a great article from lifewire.com, which explores more, titled 6 Modern Solutions to Protect Web Forms from Spam.
Protecting your domain from email abuse via SPF, DKIM, and DMARC records
Most commonly, abusive email messages come from a forged or fake address which can be accomplished easily in many programs and scripts. Using SPF, DKIM, and DMARC in tandem will help build your domain’s reputation, and avoid having your mail end up in your customer’s spam folder. We make it easy to use on your account, as we support all three records. Here's a quick recap of all records:
An SPF record is a policy which is set up within your DNS record that allows the email receiver's email client to validate if the server is allowed to send messages on its behalf. In layman's terms, SPF acts like an allowlist for email servers, dictating what can and cannot send on your domains behalf. This can cut down significantly on forged emails. You can read more about setting up records for Zendesk in our article, Setting up SPF for Zendesk to send email on behalf of your email domain.
DKIM records are a protocol which validates a message’s cryptographic signature against a public key placed in the DNS record of sender’s domain. This helps ensure that there was no deviation within the path of the email, and shows if a message has been altered in anyway prior to the receiver getting the message. Due to this, servers tend to find any domain or email more reputable, and less likely to end up in a spam folder (or outright rejected). You can setup the DKIM records needed for Zendesk by following the article, Digitally signing your emails with DKIM or DMARC.
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a policy which attempt to tie SPF and DKIM together, by telling servers how to handle an email if SPF and/or DKIM records aren't present within an email. It can also send email reports on failures, to help you gain insight into how your domain is being used and handling email. For more information on DMARC and how to set one up, see the overview on Dmarc.org.
Zendesk Support-specific features
While the previously-mentioned actions will help your domain in general, Zendesk Support offers a few additional tools at your disposal.
Sender Authentication (Inbound DMARC protection)
Sender Authentication is a relatively new feature which helps you control spoofed and illegitimate emails from reaching your account. This feature looks to authenticate the senders DMARC, and sends to your suspended queue if it fails. You can find this feature on the Email admin page, at Admin > Channels > Email. For more information on the feature itself, see our support article, Authenticating incoming email using DMARC for further information.
Blocking emails and domains
If you're past the point of proactively protecting your account and spam has been coming through email, you can outright block incoming emails from specific addresses or entire domains. This can be an efficient way to stop spam in its tracks. See our article, Using the allowlist and blocklist to control access to Zendesk Support.
As spammers continue to get more creative and sophisticated with their methods, it is important to take advantage of all possible spam fighting tools at your disposal, as no one solution will be completely effective. With the combination of the methods listed here implemented for your business, spammers will be less likely to target your business.
Further Reading
If you're looking for more documentation to combat spam, check out the following:
4 Comments
This covers protecting our Zendesk support from spam ticket from the help centre and email, but does not cover API. With the anonymous feature anyone could create a ticket in zendesk support (if the setting "anyone can submit tickets" is on). If we need that setting on because we may not know where our customers are coming from but how do we stop an attack via API?
Hey Heather,
For spam tickets created via the API, you'll want to take a look at this article: Combating spam submitted via web service
I hope this helps!
Brett Bowser
Thank you for the suggestion. But to be honest that isn't actually helpful. If a help desk agent raises a ticket on behalf of a customer, the solution in that articles means the customer wouldn't get a notification. Additionally in general it seems odd that Zendesk don't have tighter control over the anonymous API feature. This could allow someone to DDOS Zendesk. Quite a big security concern that it appears zendesk is not concerned by.
Hey Heather Cook,
We have various protections that protect customers from DDOS attacks, you can read more about it under "DDOS mitigation" HERE. If you're concerned over being spammed (which is separate from a DDOS), please follow the instructions in that article mentioned above.
Step 2 (Creating a trigger for proactive messages) covers the use case you're concerned about (and is a default trigger for newer accounts). We do this in support [at] zendesk.com -- Feel free to write in to see how we've tackled it.
As for tighter controls, there is presently a way to turn off --- https://developer.zendesk.com/rest_api/docs/support/requests#create-request
If you believe there needs to be more, I highly encourage you to reach out to your account manager with your concerns and product feedback.
Feel free to write into Support if you have any additional questions or concerns, we would be glad to help.
Please sign in to leave a comment.