Email is complicated. Hundreds of billions of messages are sent every day. Zendesk alone receives and processes millions. Over time, email's mission has changed. It's not just for person-to-person communication but also for mass mailing and machine communication. Complication introduces several threats, including mail loops, which Zendesk Support takes into account for email management.
This article contains the following sections:
What's a mail loop?
Automatic acknowledgment of messages is a common practice for software that receives email. The default trigger Notify requester and CCs of received request is one example. When a ticket is created in Zendesk Support, the user is notified by email. This kind of behavior, while common, can result in a problem when two machines email each other.
It's not a problem for machines to receive email from one another. For example, if one system receives an email from another then sends an automatic reply, that's fine. But if that system also replies automatically, this can kick off a mail loop. In this scenario, each system will continue to reply automatically to the other every time a notification is received, creating a never-ending loop until someone or something intervenes.
Loops can occur in other ways, as well. Ticket updates may come from the API, ticket sharing, an app, or a web interface. These updates can cause emails sent by trigger notifications such as Notify requester and CCs of comment update. Sometimes, those emails can cause another update, not by email, but by some other means.
How Zendesk prevents mail loops
There are several different things Zendesk does to prevent mail loops. It should be stated clearly that we can't prevent all mail loops all the time. They're a part of the ecosystem now, and we're doing what we can, but just like spam messages, they will occasionally happen.
Here are some of the measures in place to prevent mail loops:
To learn how Zendesk prevents Zendesk-to-Zendesk email loops, see Understanding how mail loops are prevented between Zendesk accounts.
Unique support addresses, not used for users
Your users contact you at your support addresses. If you use external support addresses (for example, support@mycompany.com), Zendesk Support prevents mail loops by disallowing users with one of your support addresses as their email. In other words, if you have an end-user whose email address is support@example.com, you cannot enable support@example.com as a support address. If you have support@example.com as a support address, you cannot create a user with that address.
We do this to prevent notifications being sent to your support addresses. If we did send email to one of them, they would automatically forward that email back to Zendesk Support, creating another ticket. This process would continue to loop, resulting in many tickets or comments.
Bulk mail and no-reply addresses do not create tickets
Certain emails don't create tickets by default, such as bulk mail or messages that identify as machines.
Tickets also aren't created when the sender is a no-reply address. These are mostly governed by suspended tickets. You can add the address to the allowlist if you know the sender is safe; however, doing so will increase the rate limits for that specific email address and the number of suspensions by a factor of ten. At that point, Zendesk will start to drop the traffic. Zendesk reserves the right to suspend or block any traffic exceeding safe levels. The email channel isn't designed for programmatic or automated traffic; that is the exclusive purpose of the API. Using the email channel for this type of traffic should be regarded as a temporary workaround.
When a ticket is created on behalf of a bulk sender, Zendesk suppresses automatic notifications. Agent comments will still trigger notifications, but to avoid mail loops, Zendesk suppresses any message that is sent when no comment is added. This is true when you recover these messages from suspension or add such users to the allowlist.
Fall-back limitations for ticket updates by a user within an hour
As a last resort form of prevention, Zendesk limits the number of updates a single user can make within an hour. There's a limit of 20 emails from the same user within an hour. Beyond that, the following 20 updates will be suspended. If more than 40 are received, all additional updates within that hour will be rejected (meaning they won't even create suspended tickets). This serves as a way to prevent mail loops from becoming a serious problem.
This limitation won't work if the other system doesn't use the same email address every time. Some systems use a new email address for each automated message.
You can add the address to the allowlist if you know the sender is safe; however, doing so will increase the rate limits for that specific email address and the number of suspensions by a factor of ten. At that point, Zendesk will start to drop the traffic. Zendesk reserves the right to suspend or block any traffic exceeding safe levels. The email channel isn't designed for programmatic or automated traffic; that is the exclusive purpose of the API. Using the email channel for this type of traffic should be regarded as a temporary workaround.
24 comments
Tuomas Savonius
Hi Sean, this is human to human communication. The partner uses 1 email address for all external communication, and there have been many instances where the limit has been hit.
How much does the allowlist increase the limits?
I understand that this is a bit of a special case, but even so, I think it is a big oversight not being able to whitelist a few email addresses to ignore the limits.
1
levati.luca
I am also in "over 20" situation.... It's very difficult for us, we have a lot o f suspended ticket, most of all caused by light agents/internal notes
Imagine a light agent receiving in the evening a lot of internal notes, he start to work the next morning, sequentially answering to all mail from zendesk, passing the 20 mail limit in very short time.
This is a big problem for us, we have several light agents working in this way
Please help to find a solution or workaorund
Thanks
1
Ben Van Iten
Greetings,
If the issue is being caused by a light agent, we would encourage them to work from inside of the Zendesk instance instead of sending those via email. This will get around the sending limits.
Please let us know if we can assist further!
0
Chris Stewart
Hi - Zendesk already identifies (via the above mentioned flag within the ticket..."this comment auto generated from another ZD...")
How can we identify these for tagging/triggers etc? We get tons of tickets where we have sent an informational email in a new ticket then we get an auto-reply from the receivers Zendesk asking us to rate their service
0
DJ Buenavista Jr.
Thank you for reaching out to Zendesk Support.
In regards to your concern, unfortunately, at the moment it cannot be selected from the conditions available inside the triggers. The following flag that was mentioned in the article is hard-coded into our system, and unfortunately cannot be defined right now in triggers/tagging. The triggers that were mentioned in the statement above refer to the existing and available "Received at" trigger condition which is defined by selecting the specific support email address.
I would highly encourage you to post this as product feedback on our Zendesk Support Feedback page.
Thank you and have a wonderful day ahead!
Kind regards,
0
Chris Stewart
Hi @... - Are there plans on the roadmap to address this? If ZD is able to identify and update the ticket with the message, then you should also be able to able to feed this info elsewhere ... like add a tag for example.
9 times out of 10 these auto-reply messages would have been filtered as spam if they originated outside of ZD, so it is strange that you have chosen to prioritize and force these into people's instances.
1
DJ Buenavista Jr.
Thank you for the update. We don't have any information as of the moment, but you can get an update or information if you can post this as product feedback.
Kind regards,
-1
Sylvia King
Commenting here to add that the Fall-back limitations for ticket updates by a user in an hour rule has consistently been a pain for our company. As we grow, we have customers and suppliers that will often send over 40 emails in the span of an hour (Fedex.com notifications, for example). We spend many man-hours recovering these suspended tickets and it often results in delayed information, which impacts our customers' experience. I really hope there is a fix in the pipeline that allows us to "whitelist" certain domains that can be excluded from this email loop rule.
1
Sonali Maunick
Hi. We have customers that regularly exceed the 20 emails in an hour limitation and at times exceed the 40 emails an hour. We would like the ability to either change the number of emails we allow through and/or whitelist domains as we can with other suspended tickets rules.
0
Robert Kehoe
Is this still an issue almost two years later? We're getting tons of customer emails routed into our Suspended Tickets. That is a deal breaker for us.
EDIT: Adding the customer email to the Allow List appears to have fixed the problem for us. But I'm still not clear why Zendesk started blocking the messages in the first place when we previously were receiving them. Thanks for the reply Brett.
0
Brett Bowser
If you're having legitimate emails go to your Suspended view I would recommend reaching out to our Customer Support team as mentioned in the article I linked.
They should be able to dig into this and figure out the cause.
0
Justin Clute
Hello,
We have a large number of customers that will contact us by sending in 20+ emails with emails that will be mostly the same except for identifying information like customer names and serial numbers. Otherwise most of these emails are word for word the same. They'll be able to get about 20 emails through before it starts dumping the remaining tickets into our suspended queue.
Adding to the allowlist does fix the issue but it would be great if there was a way to allow exceptions to the spam policy similar to the sorting methods that Zendesk uses for Triggers. While we have a reactive solution, it would be nice to have a more proactive one.
0
Shawna James
0
Julie Guno
Hi, how can we avoid getting 2 tickets with the same subject and same message from a sender with no-reply address?
0
Gabriel Manlapig
Duplication of tickets occurs when your mail provider doesn't correctly process the email headers of the forwarded emails to Zendesk. For your reference, kindly refer to the following article:
Why do I see duplicated tickets in my account?
I hope that helps. Thank you!
0
Julie Guno
Hi Gabriel,
Duplication of tickets only occurs with a requester with noreply address, though the emails coming from that noreply address are legitimate. I'm wondering, if the email headers of the forwarded emails to Zendesk is not correctly process why does it only happens with a sender with noreply address and not with other addresses.
0
Gabriel Manlapig
Are you using another system to send those no-reply emails and forwarding them to Zendesk, or are you using external forms that use the no-reply address and send it to generate a ticket?
We would suggest asking your system administrator or IT team to investigate how the email headers are processed when forwarded in Zendesk from the no-reply address.
0
Dominik Kaczmarczyk
Hello Zendesk Team,
unfortunately I receive a lot of tickets which are important to me but as they have similar subjects and content, a lot of them are being suspended as email loop. Allow List solution doesn't work for me, do you know any way to solve that issue?
0
Carmelo Rigatuso
Gabriel Manlapig or anyone else @zendesk
Does added a domain to the allow list override the 20 emails/hour limit?
0
Gabriel Manlapig
Hi Carmelo,
Upon checking, adding a domain to the allowlists would not override the 20 emails per hour limit. Would you mind explaining your use case? Why do you need to receive multiple (20 or more) emails in an hour with a specific email domain?
A core principle for Zendesk and the email channel is that it's designed for end-users to send email communication. Meaning, an email is supposed to be a channel for actual people to send emails, not just to receive system-generated or no-reply messages. So the only supported way to get those kinds of notifications into Zendesk is to not use email at all and instead go to the source and set up an integration to push that information to Zendesk via the API.
0
Carmelo Rigatuso
Hi Gabriel Manlapig ,
Thanks for replying so quickly. I don't want to get too detailed here on a public forum, but these are not system generated emails, these are legitimate orders from some of our larger resellers. So, this can potentially block many thousands of dollars of sales per day, so it's a big problem.
As for the APIs - yes we certainly would like to set that up for them, but A) this is a new team that still needs to work while we plan and roll that out, and B), you can lead a horse to water, but you can't make it drink (a lot of these sales people are old school).
I was posting here in hopes that there was an easy setting or config in the admin center to account for this. I'll take this up with my account exec.
thanks,
Carmelo
0
Gabriel Manlapig
Hi Carmelo,
We can offer a temporary workaround. Instead of adding the domain, you can add the sender's email address to the allowlist (see Using the allowlist and blocklist to control access to Zendesk Support), which causes the email rate limit to increase by a factor of ten. This means 20 emails allowed per hour could potentially become 200. But we would recommend testing this since this might be an unsupported workflow.
Thank you, and we hope that this helps moving forward!
0
Carmelo Rigatuso
Gabriel Manlapig
Awesome! This will hold us over until we update our processes. Thanks!
0
Rachel Mooney
hi Sean Cusick!
i got to this article via your post here about emails from netsuite being intentionally suspended to avoid email loops. since our accounting team uses ZD to intake invoices, we run into this daily.
just so i understand, the concern is that if ZD sends an auto-response to the requester, like “thanks for your request!” to netsuite, netsuite might send back their own auto-response in a similar fashion, correct? if so, is sending the email to the suspended queue stopping the auto-responses from happening all together? i'm just unsuspending these (and not changing the requester in anyway), and as far as i can tell, we've never run into an email loop. (and i've seen non-netsuite “but clearly from some sort of ticketing system” auto-responses get suspended accurately as well.)
i'm trying to wrap my head around why suspending these is preventing the loop if i'm only going to unsuspend it. i've thought about using the API to auto-recover these & others (i keep a spreadsheet of safe-but-commonly-suspended senders so my folks know what's ok to action) to save myself wasted time, but i dont want to inadvertently cause a giant problem.
0