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 it's also for mass mailing and machine communication. Complication introduces a number of 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 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 other ways, as well. Updates to tickets may come from the API, ticket sharing, an app, or web interface. These updates can cause emails sent by trigger notifications such as Notify requester of comment update (or a CC notification). 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:
Suppression of automated notifications for Zendesk-to-Zendesk email
Most Zendesk accounts employ triggers to automatically let users know that their email was received and a ticket was created. However, if the user is another Zendesk account, those triggers can create an infinite email loop, with one Zendesk account automatically creating a ticket and sending a message to the other account, which then automatically creates a ticket and sends a message to the first account, and so on.
To avoid this problem, Zendesk Support differentiates between automatic email notifications and all other email notifications:
- Automatic email notifications are emails generated by Zendesk Support without any action on the part of an agent. When a ticket is automatically created from an incoming email, an automatic message is sent.
- All other email notifications include emails generated by Zendesk Support based on an action performed by an agent. When an agent adds a comment to a ticket, for example, an email notification is sent.
When your instance of Zendesk Support receives an email from an end-user that it identifies as another Zendesk account, it performs the following steps:
- Creates a ticket from that email, or threads the reply back into their original ticket, using the sending email address of the requester.
- Suppresses the triggers for automatic messages.
Email notification triggers are left intact, so when an agent adds a comment to a ticket, an email notification is still sent to the Zendesk account that submitted the original email, and the following flag is added to the comment:
Partner addresses list for Zendesks you have sharing agreements with
When you send email to another Zendesk, automatic emails notifications are suppressed, but email notifications generated by an agent action are sent. This can cause problems if you have a ticket sharing agreement with the other Zendesk. In that case, it's possible to create an endless loop of notifications if the email address for the user in the CC or Requester field is the support address of a Zendesk you have a sharing agreement with.
To prevent endless loops, Zendesk Support automatically maintains a list of Zendesk partner addresses—that is, a list of all the support addresses for each Zendesk Support you have a sharing agreement with.
When a user is created in Zendesk Support, the email address is checked against the list of partner addresses, and if the address is on the list, then all email notifications, including those generated by agent action, will be suppressed to that user. On a ticket, you'll see a flag when a user on your list of Zendesk partner addresses is in the CC or Requester field. The warning flag lets you know that email will not be sent to that user.
Likewise, email sent to Zendesk Support from any email address on your partner addresses list will be rejected by Zendesk Support, because there is already a sharing agreement in place. If you need to, you can create a ticket with this user as requester and share the ticket back to the Zendesk you already have sharing agreement with.
Unique support addresses, not used for users
Your users contact you at your support addresses. If you use external support addresses (i.e. firstname.lastname@example.org), 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 email@example.com, you cannot enable firstname.lastname@example.org as a support address. If you have email@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 then continue to loop, resulting in many tickets or comments.
Bulk mail and no-reply addresses do not create tickets
We prevent certain email from creating tickets by default. These might be things that are clearly bulk mail or messages that identify as machines. We also do not create tickets by default when the sender is a no-reply address. These are mostly governed by suspended tickets. You can add these to the allowlist if you know that the sender is safe.
When a ticket is created on behalf of a bulk sender, we suppress automatic notifications. Agent comments will still trigger notifications, but to avoid mail loops we'll suppress any message that is sent when no comment is added. This is true when your recover these messages from suspension, or when you add such users to the allowlist.
Fall-back limitations for ticket updates by a user in an hour
As a last resort form of prevention, Zendesk limits the number of updates a single user can make within an hour. We have a limit of 20 emails from the same user within an hour. Beyond that, the next 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 we don't catch from becoming serious problems.
This limitation won't work if the loop other system doesn't use the same email address every time. We have seen systems that use a new email address for each automated message, for example.
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.
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
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!
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
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!
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.
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.
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.
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.
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.
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.
Please sign in to leave a comment.