Verification for anonymous help center requests

How can we test how this flow works and what notifications users get? Just to be prepared for the change.  
UPDATE:
(The updated announcement has screenshots) 

We also only allow anonymous users, as members were already confused about having to sign into a separate site to submit requests for support. And now there is no way to opt-out, no way to add additional text to our form to warn them, cant add a note on the email field… You're just not giving us any options here and I'm 1000% sure this will now cause an increase in support for our super small team, as we have no way to warn our 700k+ users. 

This announcement affects our chat workflows, our auto replies, API requests we use, how our form works, our suspended ticket process, and so much more. Considering the vast majority of our end users are not signed in to the help center when submitting a ticket, this is going to greatly decrease our ticket volume, upset our end users, cause a sudden change in process for all of our Support teams, and disable our end user's ability to chat with us. I've also reached out to ZD support for clarifications on some of these changes, and have been met with conflicting or unclear information. 

How can we adequately prepare for a change that isn't clear on the ZD side what will be impacted, how it will be impacted, and be able to test out these changes ourselves before it gets released? I've seen other announcements that state “this workflow is enabled automatically for your account” and it impacts nothing to our account. This has significant impact. 

Joining in to add impact. This absolutely should be optional as it will create a large issues with our current deployment. 

This launch seems extremely rushed and not very well thought out at all

Other customers should be aware of this aspect of the rollout, which is NOT made clear in the announcement. End users who aren't signed in won't just need to verify their email addresses once, but EVERY time they submit a ticket in the help center. This creates endless admin overhead unless we implement SSO for all end users. I haven't found another path forward that doesn't permanently increase our overhead/labor costs.  Zendesk should immediately pause this rollout and take the time to think through major product decisions going forward. 

We get some spam from having email submissions enabled (we choose to handle that manually for the benefit of real users) but we don't get any spam through the support form. All of our customers submit tickets anonymously, so this change will negatively impact them and us. Please provide an option to disable it. Thank you.

Disappointed with the mandatory email verification.  We need an On/Off toggle.

This change has a significant negative impact on our support operations. While I understand the importance of security, forcing every customer to go through email verification leads to a direct drop in customer satisfaction.

The announcement for this was insufficient, and the implementation feels rushed. At the very least, please provide an option to toggle this feature ON or OFF so that we can choose what works best for our customers.

Hi, everyone. I want to start by thanking you. I understand that this is an abrupt change, and that we haven't provided enough information or time to react here. The clarity and specificity with which you've all replied is crucial for us. We are trying to enhance security while also preserving the value you get out of Zendesk, and obviously this change has significant impact on you. The issues we saw with spam attacks over the past few months were also deeply painful for many people, and have forced us to make some significant changes. While we do not plan to offer a way to turn this feature off permanently, I want to address some of the feedback we are hearing in this thread and through tickets and other outreach.

First, we will be extending our roll out schedule for this feature. The rollout will still begin next week, but will continue over a longer time period. It will begin March 10th and end April 14th.  This will give most more time to prepare. We will monitor impacts and respond accordingly. We are also opening this form in which you can request a deferral until May 7th, four weeks after the final roll out date. For anyone who needs additional time to prepare, you can make that request. Once the new schedule is published, you will also be able to determine your specific roll out date by looking at the announcement post, which will show a schedule for pod by pod releases. (How to find your pod)

A number of posts also called out a lack of clear details on how this change functions. We've added more information, screen shots, and details to our announcement post. We would gladly add more detail or answer further questions as well. You can comment in this thread or submit a ticket. 

A number of other posts here understandably call attention to change and potential disruption to existing workflows or added work to manage suspended tickets. These are completely reasonable responses, and we're working to address them with some much needed enhancements to the Suspended Tickets interface. This will include additional filtering, bulk actions, and more visible detail. We can't comment on timelines quite yet, but this is a very high priority and will be released as soon as possible to make this process simpler. We have plans to further improve on suspended tickets later in 2026 as well. If you have specific workflows which are disrupted by this change, we want to hear about them. Comment in the thread or reach out to our support team. We will continue to improve this experience.

The last category of response I see is the most difficult to alleviate at this moment. Many of the posts here address added customer friction, or an impact to your quality of customer support. We've made this change with the aim to protect your accounts and our ability to continue delivering email to recipients successfully. We're taking a multi-pronged approach, and this is the surest way to stop mail relay attacks that have caused a different form of major pain for our customers and unsuspecting individuals on the internet over recent months. We've tried to make this experience as simple and brief as possible, and we'll continue to improve on it with your feedback. We are instrumenting the impact of this change and will monitor and look for the ways we can improve. As I've said before, we need your feedback to improve this. 

I know this post won't end all your concerns and won't deliver the main request here. We don't go into a change like this without significant discussion and thought, and we want to continue to improve this experience for everyone. We're leaving this channel open and will continue to communicate about our process.

One of our support workflows allows anonymous users to submit requests through the mobile channel (Support SDK for iOS and Android). Tickets of this type typically have the requester name set to “Mobile App User” and do not include an email address. As a result, there is no user information available to validate.

Given that we receive approximately 50–100 anonymous mobile tickets per day, this change would introduce significant friction into our support process and could result in legitimate tickets being suspended or remaining unverified.

Could Zendesk please confirm whether our workflow will be impacted by this change?

The form is not shared, I have requested access, but not been granted yet.

I appreciate you offering this option to defer this update, but would also like to reaffirm our preference to make this optional. Reading over the article, I'm still not able to understand why it will be mandatory, only the anticipated impact for customers having these issues. Whoever made this decision need to rethink it.

Almost 100% of our volume comes from the request form, and we do not ask users to create an account to submit a ticket - our customers are the general public, and we already have our own platform for user accounts via our website, so it makes no logical sense to require sign-in.

Adding a banner to our help center will do little to reduce friction (as Customer Service professionals, we all know people don't read things carefully), plus verification emails may not be delivered to inboxes, filtered to spam or simply not noticed by our customers. It's impossible to get around the fact that this extra step will lead to a considerable volume of tickets caught in the 'suspended' state due to user error.

As a lean team we are already pushed to max bandwidth, and it seems that Zendesk's tooling has not evolved with businesses like us in mind. Our contract renewal is coming up in April, and if this update is made mandatory, it would be a huge factor pushing us faster in the direction of moving platform.

Should this remain mandatory, I'd like to advocate for the following solutions to reduce friction: 
- Ensure that the email verification step is only required for first-time submitters, not returning customers who are not signed in to our help centre

- The ability to add a custom message to the top of the request form itself - not just a  pop-up or banner - we have customers a global customer base who use browser translation tools to read our form, so this is essential.
- Do not stop offering answerbot replies with suggested articles to anonymous users - we want all of our customers to receive suggested information instantly
 

In addition, the proposed enhancements to the Suspended Tickets interface (incl. additional filtering, bulk actions, and more visible detail) would need to be rolled out BEFORE this is switched on for us. Otherwise, it will be impossible for us to sort through our suspended tickets view to locate legitimate requests, leaving affected customers with no way of reaching us.

Thank you for your time and attention.

@max30 I appreciate the update but this does not answer a large part of the concerns we are expressing.

Our company has several types of contacts that CANNOT BE MISSED. Failure to respond to these can result in legal and monetary culpability… so you can see, adding something like this with this short of a time frame causes us to scramble for solutions, especially when Zendesk is not providing any framework for any solutions! Still cant run triggers on suspended tickets, and sorting and searching suspended tickets is an exercise in futility. 

Not providing a way to disable this, or at least exempt certain types of contacts, is incredibly shortsighted and makes this entire change feel rushed and panicked. We as customers pay a lot of money to be on a premier platform, and a rushed and panicked forced change makes me reconsider whether it's even worth it to stay on the Zendesk platform if this is how customers feedback is considered.

So the big questions no one has answered:
What is the solution to make sure very sensitive tickets don't get lost in Suspended ticket purgatory? Manual review by Agents is really our only solution? Are we getting a reduction in our bill to offset all of the extra hours we need to have Agents combing Suspended tickets? What about the engineering hours needed to account for this through all our integrations that will now be broken? Per the announcement API Tickets need to reverify for EVERY TICKET CREATED?

We have a separate deployment for internal requests, time off, HR, WFM etc, so that means   an employee submits a ticket they have to re verify their company email address since we use a web form? Do you see how this is not good? Why are we forced to use this system for an instance that never receives any SPAM since its internal only?

Real talk, this is going to break a lot of things in our multiple instances, and while I am 100% in support of anything that reduces SPAM,  this seems not very well thought out at all.

I genuinely expect more from Zendesk, and full transparency this and other recent decisions are making us explore alternatives to ZD for the first time ever.

Looking forward to responses with actionable steps on how to mitigate the damage this will cause, as our time is limited to implement them.

@emma25 

 I would like to know what happens when a suspended ticket is recovered following this change? Specifically, will the pre-filled webform fields be retained or removed?

• When a ticket is recovered from suspension it goes through all the same processes as a ticket creation. All the data from the form is preserved (fields, attachments, etc) in the resulting ticket, and triggers are executed, including notifications. This validation pause is a critical step in our defense against mail relay attacks, it ensures automated scripts can’t inject malicious content or phishing links into your active queue. By verifying the human behind the request first, we ensure your automated workflows only interact w/ legit users. 

@sally15 

• I hear you, and we agree that security needs to be multi-layered. To address the specific issue of account-creation spam, we've already taken steps to apply back-end rate limiting on welcome emails. We did not produce a public notification of this change as it didn’t require a change to your settings, and doesn’t qualify as a feature change. However, ticket creation spam is a different challenge. Attackers exploit open web forms to force Zendesk to send “ticket received” emails to unsuspecting victims and because those emails come from trusted domains, they’re highly effective. This verification step is the most reliable way to stop these attacks at the source, protecting your brand’s sender reputation and ensuring our email servers remain healthy for all customers. 

@lori14 

 ZD please confirm it does not apply to requests created by sending an email to your support email address

• Our announcement has been updated to include this information more clearly: The Email channel is not affected. Here’s why: Direct email submissions already benefit from industry-standard verification to help identify legitimacy. This new verification workflow specifically applies to web forms, which have become the primary entry point for sophisticated relay attacks that bypass traditional spam filters.

@robert61 

• auto-replies will not work when the user is not signed in means that they will not receive important information from us.

Your auto-replies and article recommendations will still reach your users, the timing has simply shifted to ensure security. Auto-replies will trigger immediately if the ticket is recovered from suspended, or when the user clicks the verification link in their inbox. By delaying the auto-reply until the email is verified, we prevent your Zendesk instance from being abused by scammers to send automated messages to people who never submitted a request. This protects your customers from noise and ensures when your auto reply does go out, it’s being delivered to a real person ready to engage.  

We have been using Zendesk for years, and I must say, we were pretty unsatisfied with how this was handled. 

We have a complex environment with many integrations which were adversely affected by this change (that's putting it mildly - they all would've immediately stopped working if we hadn't scrambled to completely change how they functioned with minimal notice). 

If you're going to roll out a change this significant without any warning whatsoever, we need more of an explanation for why this haste is necessary than “I don't know man, there's a lotta spam out there”. Any SaaS company can spot “we had an urgent security reason why we had to do this and that's why we're being so cagey and inflexible about it”, and speaking as a company that has had to deal with this recently, I can tell you - flexibility is a luxury; being cagey is a vice. 

If there's a reason why this has to be done this way right now, tell your customers that.
If there's no reason why this has to be done this way right now, but you really really wanna do it this way - please try to give us more notice, or give us better options than “fix everything we broke with zero notice or warning". 

While we were scrambling about this, your support team's inability to tell us specifically how many days we had left before our pod would have this policy activated was fairly irritating, and this is not something I blame the support team for. If you're rolling out this change one pod at a time, it should be possible to tell us which day our pod is on the chopping block. If that information is not being made available to your customer-facing teams, we would like that to happen next time.

If you are dealing with what I suspect you're dealing with, please know you have my sympathy along with my consternation here. I just hope y'all can take some good lessons away from it. 

Is there an alternative way to verify email addresses that does not require users to click a link? At the moment, it seems we cannot customise it as per brand which means it will look fairly generic unless dynamic content is added. 

My main concern, however is the method itself, we spend a significant amount of time educating both customers and agents not to click on suspicions links in emails because of phishing risks, yet in this case we are asking them to do exactly that to verify their email address. It feels a bit contradictory that while rolling out a feature to combat spam and related threats, the verification process relies on behaviours we typically advise users to avoid. 

Are there other verification methods available? (e.g. one time code) that could be used instead?

Hello Zendesk, @max30 , @leanne11 ,

thank you for explanations.

We operate in the financial sector, where handling sensitive data and documents (like Proof of Funds) is a daily routine. We actively instruct our users to use the web form for secure document uploads instead of sending unencrypted emails. This update directly penalizes that secure workflow and severely disrupts our operations for several reasons:

• Automation becomes meaningless: We utilize automated resolutions (like Ultimate AI). If a legitimate request ends up in the suspended folder pending verification, the automation is broken. Stating that "autoreplies will still work once the ticket is recovered" fundamentally misses the point of an auto-reply. If it requires manual intervention or a delayed click from the user, it’s not automated or real-time anymore. Over weekends and holidays, these requests will simply get stuck, heavily degrading our customer experience. (We do not have service on those days)
• Suspended queue chaos: Currently, the suspended folder serves its purpose by catching actual spam. If you start mixing real, pending user requests with actual spam, it forces our agents to manually scan and review the entire folder. 
• Security & Phishing risks: We constantly educate our customers: "Think before you click." In an era of rampant phishing, forcing a workflow where users receive unexpected automated emails with a mandatory link to click is the perfect breeding ground for fraud. You are training users to execute the exact behavior we try to prevent.
• Redundancy & No Brand Customization: Performing verification for every single anonymous request, even if the user has verified before, will lead to immense frustration ("I just verified yesterday, why again?"). To make matters worse, reusing the standard verification email without the ability to customize it per brand prevents us from giving our customers the necessary context to trust the email.
• The "Sign-In" workaround is not a quick fix: Suggesting we just "require end users to sign in" ignores the reality of custom Help Center layouts. We intentionally removed the sign-in requirement a few months ago. Forcing us to revert this requires development effort, yet there is no active support or clear guidance from Zendesk on how to seamlessly implement this change on short notice. 

This change trades a spam problem for a massive customer friction and automation problem. We need a better, more flexible solution for forms that doesn't punish legitimate users and break the AI integrations we pay for.

Also an addition to our previous comment:

Punishing secure setups for the mistakes of others:
We do not even include {{ticket.description}} or other user-generated payload in our auto-replies upon receipt. Therefore, we do not pose a risk for propagating mail relay attacks in the first place. Why is there no opt-out or intelligent check for instances that already have secure trigger configurations? Instead of implementing intelligent bot protection on the form level (like invisible reCAPTCHA), you are applying a blanket restriction that punishes secure instances and destroys our automated workflows just to clean up the mess of other vulnerable instances.

I appreciate your response, but this is still not acceptable. Again, we need to be responsible for our own decisions. If we need to turn off this feature, we accept and understand the risk. Please do not enforce this as mandatory, as it will be disruptive for our customers and staff.

We have a case with multiple languages across multiple brands. Some languages are supported only via dynamic content and community translations. 
What options do we have: 
1) We want verification notice messages to be presented in the user's language.  Can we do it with theme customization? 
2. Each brand should receive the email verification in the correct language. When do you plan to introduce dynamic content support for these messages?

This is a significant change that will cause real challenges for our end users in the process of trying to receive help. Our users already struggle to communicate effectively via email – causing every single form submission to require verification is redundant and unneeded.

We don't go into a change like this without significant discussion and thought, and we want to continue to improve this experience for everyone.

If this is the case, then this should have been communicated SIGNIFICANTLY earlier.  Less than 1 week to the inital rollout is not significant consideration for your users or their end-users.

“These are completely reasonable responses, and we're working to address them with some much needed enhancements to the Suspended Tickets interface. This will include additional filtering, bulk actions, and more visible detail. We can't comment on timelines quite yet, but this is a very high priority and will be released as soon as possible to make this process simpler.”

If this is going to cause this much friction, don't roll this out until these solutions are implemented and ready. OR, do provide an on/off switch from the start. That is not a significant lift.

I am shocked that this rollout is still proceeding.. there are hundreds of comments here against it, and there are so many unanswered questions on how this will affect, and possibly break, everyones build.. but this is plowing ahead with no answers provided.

We cannot test, as there is not way to just enable in a sandbox first, because this is going straight to production.. this is a recipe for all kinds of disasters and instances failing to work when launched.. but still we have a hard deadline of launch with very little insight or answers to important questions

Here are some question that I am unable to get answers to, I have ticket open with support and have received no answer for over 3 days.. I suspect because there are no answers to be had right now:
Wanting to confirm, several places said that trigger will still not work with Suspended Tickets. This would have been a possible solution, but to confirm this is not changing correct?

1. API ticket creation endpoints are affected by this as well.. we have multiple API systems that create tickets in ZD, mainly anonymous feedback tickets which will NEVER have an associate email address. Does this mean the ability to do this will be blocked permanently by this rollout?
2. Per Max’s post there will be no way to adjust or opt out of this… This is going to add a ton of unplanned work to account for this sudden change, and having that happen for a service we pay a lot of money for sounds extremely counter intuitive. Do we get a cost reduction for the increase in workload we will have to do internally? What about the hours Agents are going to spend combing through Suspended tickets for ones that should not be there?
3. How would you ensure Data Deletion requests do not get lost to the Suspended ticket purgatory? You can't action Suspended tickets with triggers etc, and even more frustrating theres no good way to search or sort Suspended tickets. This change will cause an explosion in the amount of Suspended tickets (which is already very big) and will make this even harder to find tickets that should not end up there. So what is the recommended way we mitigate the loss of legally sensitive ticket submissions?
4. Web forms are around 65% of our ticket volume, so this change has a large impact on us, and tickets that are legally sensitive cannot be lost. Please provide any and all steps to mitigate “suspended lost” tickets that are ones that we cannot miss legally. Manual Agent review really the only option?
5. Please confirm this is expected behavior:

What if the end user already exists and their email address is already verified?
Verification is performed per each anonymous request; even if the email is verified and belongs to an existing user, the verification email will be sent for every anonymous request.
If this means every time a user submits a web form they will need to re verify, this is going to be a huge issue and cause a lot of lost requests I suspect

6. When a user submits a ticket through our help center, and they get sent a verification email, say that email goes to their SPAM folder, so they do not verify their email address… then the user submits another ticket asking what happened to the first.. what is the expected behavior? Should they receive another verification email? Or since one has already been sent, does that ticket go straight to Suspended with no other contact since one email has already been sent for that end user?

7. We have an internal instance for very sensitive internal tickets, like HR, WFM, etc. Does this mean every employee of the company will need to verify their email for every ticket they submit in our Internal Only system? This instance gets zero SPAM as it is not public facing, can this be removed from the new system as it will never need it?

8. Also, how will this change affect 3rd party apps?
For example we use Proactive Campaign, which leverages API to create those proactive tickets.. will these all need to be validated as well?
 

Very disappointed with this change. We do not require sign-in for consumers to submit our webform. Having to verify their email address is a confusing added step that will be very disruptive to the consumer experience and to our staff. Also given that the subject line of the email verification message is not editable and is very vague, we expect many people will not go through the verification process for fear it's a spam/phising email or will simply ignore it. This means our agents will be constantly in the Suspended Tickets view combing for legitimate tickets which is a very inefficient use of time. 

Adding my voice to the calls to please, please make this an optional update. It will be a horrible user experience for everyone involved.