To decrease the number of spoofed email and spam you receive, you can add an additional layer of security on your inbound emails by enabling authentication with SPF, DKIM, and DMARC alignment.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a technical specification that allows email message senders and message receivers to cooperate and better detect when messages don't actually originate from the Internet domain they appear to represent. Sender Policy Framework (SPF) is a path-based email authentication technique. DomainKeys Identified Message (DKIM) is a signature-based email authentication technique. For more information, see SPF, DKIM, and DMARC.
This article includes the following topics:
Related articles:
Enabling sender authentication
The task of enabling SPF, DKIM, and DMARC alignment authentication is handled through the Email channels page.
To enable this feature
- In Zendesk Support, click the Admin icon (
) in the sidebar, then select Channels > Email. - Scroll down to the section Sender authentication with DMARC.
- Select Enable, then click Save at the bottom of the page.
Most emails that do not pass this type of authentication are suspended. You can view them in your Suspended tickets view. Tickets suspended for failing to pass SPF or DKIM authentication have Failed email authentication as the cause of suspension.
Checking for false positives
After you enable this feature, it's important to regularly monitor your Suspended tickets view for false positives, valid emails from customers that are marked as spam.
To check your Suspended tickets view
- In Zendesk Support, click the Views (
) icon in the sidebar and then click the Suspended tickets view.
If you find that many valid emails are suspended, disable this feature and contact Zendesk Customer Service.
10 Comments
It should be noted that if you workflow includes auto-forwarding email in to a Zendesk, the DKIM signatures may not be correct.
Before enabling this feature, you might look at the "original message" in a few recent tickets, and ensure that emails forwarded to your zendesk do not have "dkim=fail" in the list. If they do, you'll want to reconsider how you get messages in to Zendesk before enabling this feature.
Hi Allen, a DKIM failure on a forwarded email alone should not cause any change in behavior on our end. If that failure also included an SPF failure then there might be a flagged comment or a suspension, depending on whether it was a soft or hard-fail.
"Most emails that do not pass DMARC authentication are suspended. You can view them in your Suspended tickets view. Tickets suspended for failing to pass DMARC authentication have Failed email authentication as the cause of suspension."
If I understand correctly, if DMARC fails the email may be rejected instead of being 'Suspended'. Is there a way for these emails to never be downright rejected and always end up in the Suspended view? Some users do have SPF/DKIM set up for their domain but do not always send in emails the normal way, an example would be PHPmailer on a webserver with an IP address that is not covered by their SPF record.
Basically, we want to manually review each message that does not pass DMARC authentication so we don't miss legitimate emails. When we identify those users, we'll just add them to the whitelist.
Hi Hasan, Based on your description the arriving emails would become suspended. Only emails that purport to be from Zendesk.com might possibly be rejected. This policy can not be configured at the individual account level. Recovering or deleting from the suspended view is the only moderating tool available at this time for this purpose. Any change in this behavior would be a Feature Request.
It seems that Zendesk filter spam from non-gmail addresses but processes letters with fake gmail addresses.
i.e. letter from Vasya@mail.ru went to spam but letter from vas.ya@gmail.com has resulted in the ticket being created...
I will add here that most (if not all) of the SPAM I have been getting via the standard support e-mail provided by Zendesk has sky-rocketed over the past 3 weeks. All of them seem to be from GMAIL. Therefore the DMARC check is not able to be used. I cannot blacklist any domain and my e-mail Channel has to be Open. You can see more of my comments on this at this post
My theory is that the move to the AWS mailer has exposed our domain IDs.
As a test. I am un-selecting the use GMAIL servers to send.
Hi Forrest,
I looks like Sean was able to address your question in the post you provided. His response indicates that he's reaching out to our Dev team to confirm whether or not outbound sending changes would have increased spam in your account.
Appreciate you taking the time to share this with us!
Hi Forrest, We have not moved to Amazon SES for outbound sending yet and as far as I know there is no process on our end that would expose your native Zendesk support addresses, though there are also no authentication limitations to inbound relaying to those addresses. Accounts being hit by spam is a normal thing that happens to email addresses from time to time. It is nearly impossible for us to find out why an account has been targeted, we are only able to help address the issue once it has been. As long as the emails are being suspended then there is not very much that can be done beyond that. If you'd like to open a ticket with us at support@zendesk.com then we can take a closer look and verify that the suspension process is happening as is expected. Regards, Sean
I have opened a support ticket with Zendesk and with their help we have reduced the scope of spam impact from thousands getting through to single digits that end in the "suspended" queue. That being said, the ones that end in "suspended" all are as-if from gmail accounts and it is very unlikely that they are real by the way they are looking - being Joe Smith, you would not create an email joesm.ith@gmail. So yes, there is a hole in the incoming email processing of the alleged gmail senders that does not catch some fakes.
The problem is that there is no CAPTCHA for incoming email requests like they have for users using web forms.
For example a person can send an email and the click on the link to set a password. The ticket gets sent. No CAPTCHA needed which makes Zendesk SPAM protection pretty weak.
Please sign in to leave a comment.