Skip to main content
Closed for Voting

Using Freshdesk you don't know if your emails are delivered

Related products:Freshdesk
  • January 18, 2016
  • 57 replies
  • 388 views

Forum|alt.badge.img+1

I've reported this problem many times, each time the answer was, that it will be planned in the roadmap.


I personally consider that this is a HUGE issue. You cannot offer a ticket portal, mainly operating with emails, which does not support notification upon unsuccessful delivery of the email.


It just appears as sent. And this is applicable for all type of events - reply, forward, new email. If you make a tiny typo adding the to address in send email or forward email (with contact which is not in your customers lis), you are done. The recipient will never receive it and you will never know.


The more frustrating thing is that if you get your email to a certain recipient(s) bounced several times (rejected by the recipient server, you receive an email back with the reason, called bounce), the mail service Freshdesk is using will mark this particular email(s) and put them to their suppression lists. This could be even caused due to temporary configuration problem at your recipient's mail server.


After being put on the suppression list, EACH email you sent to those email addresses will appear as properly sent in the portal, but they are actually DROPPED and never reach their destination.


And the worst part - you will NEVER know. Freshdesk team cannot give you information about all contacts being sent to the suppression list. You must specifically ask for a certain email address...


Dear Freshdesk Team, you will lose a lot of clients (when they realise this fact) if you do not implement receiving some sort of notification that the email was not delivered.


As discussed in my support ticket - I do not want you to change the mail services you are using or emails being sent in the suppression lists. This is normal behaviour.

If I know that there is problem, I'll contact you and ask if the email is in your suppression list in order for you to whitelist the domain or remove it from there.


But now - we are left in the dark.

57 replies

  • Community Debut
  • August 16, 2016

It is really silly that this is still an issue. Sendgrid has a really great API that shouldn't take a competent programmer more than a couple of days to integrate.


How about adding a front-end component that allows administrators the ability to search for addresses on a bounce list and delete them?

https://sendgrid.com/docs/API_Reference/Web_API/bounces.html


Get your programmers on it. You have lost business over this issue. Given the quality and ease of integrating the sendgrid API, the ROI should be measurable and immediate.


  • Community Debut
  • September 3, 2016
This is indeed a tremendous and basic issue and one that is causing us to consider migrating to another service.

 


You are completely right. It would also be helpful to see when a reply (email) is opened.

Hi everyone,


Thank you for your responses on this thread - we understand the severity of this issue and apologise for not having picked it up earlier. Rest assured, we have picked this up now and are analysing the best approaches to solving the problem. 


We typically want to provide you with the following information:

(a) Information pertaining to the reason for a failed / bounced email delivery

  • This could be when a "hard" bounce occurs typically because of an invalid recipient address
  • This could also be in context of a "soft" bounce when an email got as far as the recipient's mail server but was returned before reaching the intended recipient's mailbox. A typical example of this scenario is when the recipient's inbox is full.
  • While the two scenarios mentioned above are fairly straightforward, there are also scenarios when mail servers do not necessarily return bounce notifications and block certain emails with the intention of preventing potential spammers. If emails to recipients of a specific domain are alone failing, we often find this to be the reason.
 

(b) Information pertaining to corrective action, if any

  • In the scenarios mentioned above, we also want to inform you of corrective actions that you can take wherever applicable. At the very least, letting you know the reason of a failure in itself will help you take corrective actions, but that is something that we need to properly evaluate as there may be multiple recipients to a single mail and not all the recipients may have faced an issue for the same reason. Additionally, emails could have been sent manually by agents using the ticket page or by automations and I am sure you will want to be informed either way and we want to evaluate the best approaches to this.


We intend to the fix this problem iteratively and I will periodically post updates on this forum with potential fixes and timelines. In the meanwhile, let me assure you that we are actively working on resolving this concern and you will definitely see an enhancement in the near future.


Thanks,

Arvind


Dear Arvind,

I need:
1) Inside the ticket: a warning that a particular outgoing email was dropped and a link to a page with more details and tools to handle the issue.
2) Inside the ticket: a confirmation that  a particular outgoing email was delivered.
3) In a dashboard-style page: a list of warnings for outgoing email that were dropped and, for each, a link to a page with more details and tools to handle the issue. Bulk unblock is welcome.

I must have the option to unblock a recipient myself, as opposed to requesting you do that for me.

Recipients that have already successfully received a number of emails should be whitelisted or treated with much more leniency. In this case, you should tolerate a number of hard bounces  ( sometimes mailservers will hard bounce because, for example, they classified the incoming email as spam based on, say, contents ).

You should also tolerate a reasonable number of soft bounces when contacting a new recipient ( for example, the greylisting anti-spam technique relies in proper treatment of soft bounces by legitimate senders ).

PS: Based on the increased number of such reports lately, I suspect you recently made your algorithms more trigger-happy.

 


  • Contributor
  • September 8, 2016
I've recently come across this myself and am astounded that freshdesk is a system in which your customers will stop getting your emails completely and you will never know unless they say something or they stop being your customer because of the lack of communication. I can't tell the owner of the company that this is the case because he will want to leave Freshdesk immediately if he knew so I really hope this is resolved asap. The sad part is that even now, I could have customers who aren't getting my emails and I am completely oblivious to it!

  • Contributor
  • September 8, 2016

Quote "I can't tell the owner of the company that this is the case because he will want to leave Freshdesk immediately if he knew so I really hope this is resolved asap."


I wonder how many of us are in the same boat, fearful that this fact will get out.  It would undermine customer, agent, and management confidence in the product.  Once that is gone people would be competitor bound.


We get all these updates on all the wonderful new things Freshdesk is creating that sound good for marketing but meanwhile serious items like this remain untouched.


That other helpdesk system that Freshdesk (and it's website) looks so similar to has extensive e-mail control including whitelist / blacklist facilities (I love the one where you can blacklist everything except your customer domains... it would cut down on all the Spam we get *daily* that creates tickets with malware/trojan payloads).  How about copying some of their e-mail stuff too?


  • Contributor
  • September 12, 2016
Another vote to move this development along.  We simply don't know that people aren't getting our mail or if they are just not responding.  I had a chat with a FreshDesk rep a bit ago and found a user in the sendgrid reject list for whatever reason and was able to understand why that user was not getting our correspondence.  But the only reason I even knew that this was happening was that I had access to the customer's email account to try to troubleshoot the problem.  There is ZERO evidence from either side that this is happening, so when I reported it and it was fixed and I was asked "are there any other addresses you want me to check", my initial reaction was "ALL of them", ALL the time.  I can't wonder if my customers or potential customers are getting my tickets or outbound email tickets!

Please resolve this issue as soon as possible.

 


Hi Thanos, Ben, Tim, Slavelle


Thanks for your feedback! The concerns expressed by you are definitely valid and we will be taking each of these points into consideration before rolling out a fix. In the meanwhile, thought it best to share some feedback from my end as well:


Thanos,

* Let me assure you that most emails get through to their intended recipients. I agree that there are failures in some cases and to alleviate that, we will provide a failed notification in the most appropriate location. However, you mention that you would also like a delivery confirmation for all outgoing content. Would that really be of help or would it actually contribute to more noise on the ticket? For instance, if you use a Gmail, Yahoo or Outlook mailbox, unless you get a failure notification, you can safely assume that your message went through. Is there any specific reason you feel that only failure notifications are insufficient and want success notifications as well?

* I agree that allowing you to unblock a suppressed recipient will be the most optimal way of eliminating the problem instead of reaching out to us to have a recipient unblocked. Will definitely consider this in the solution.

* In terms of our implementation becoming more "trigger happy", I assure you that there are no changes from our end and we rely on our mail delivery service in this context. I am however unable to elaborate further because I am not aware of the specific cases you are mentioning. Request you to share any future cases you come across with our support team (support@freshdesk.com) so that we can analyse every case individually and help you trace the root cause to the best extent possible.


Tim,

You mention requiring a feature that will allow emails only from certain domains and block communication from every other domain. We already have this feature in Freshdesk. Below is a small snapshot of the feature. You can always learn more by visiting this link.

Ben, Slavelle

Considering you are legitimate users of the system, I can understand your wonder around adding people to a "reject"/suppression list, but unfortunately, any email system can be exploited by spammers to attempt sending mass mailers or to attempt sending content to random addresses to evaluate the validity of these addresses and then subject the valid ones to spam emails. While I will skip the various scenarios in this post for the sake of brevity, I hope you understand that certain restrictions need to be put in place to prevent such unintended use. However, this explanation is not intended to undermine the importance of this forum's request - as a user of a ticketing system, you definitely need to know if your legitimate communications are dropped, and we will do all that we can to build this feature in the best way possible.


Thanks,

Arvind.


 Dear Arvind,


You have an excellent point about positive delivery notifications being an overkill if inside the ticket page. Perhaps, but I don't insist on that, they have a place in the Show Activities page.


My impression about a change in the strictness of the blacklisting mechanism was based on personal experience plus the observation of reports from others. This was subjective.


I have to mention that we are in the process of moving to Forest and soon this may stop being an issue for us. Regardless, it is good to know that Freshdesk addresses it.



  • Community Debut
  • November 3, 2016
Any update to this - plenty of time has passed.  I put in  request recently to get a list of blocked emauls and was told I could only get emails from the last 48 hours, which is....ludicrous.


 


  • Community Debut
  • November 23, 2016

Hi, I recently discovered this critical issue on our helpdesk, and it's very dissapointing to know that there is no answer yet.


  • Community Debut
  • November 24, 2016

Guys, what other freshdesk alternatives did you move to when you realised about this bug?


  • Community Debut
  • November 24, 2016

This is critical, when should we expect delivery of such solution? 


  • Community Debut
  • November 24, 2016
I agree - another lost email confirmed today.  Also a crappy response when I asked for support on this - they could not supply a list of blocked emails. Appeared to not really understand the issue.

I'm currently evaluating alternatives.  No response or progress in two months to a very serious issue is not good enough Freshdesk!

 


  • Contributor
  • November 28, 2016

When it comes to this issue there are only three kinds of Freshdesk customers:  those who are blissfully ignorant of this issue; those who are painfully aware of it and are are worried about their own customers becoming aware of it and are fearful that one day they will find out while all they while they keep their fingers crossed Freshdesk will get it fixed; and those who have had their customers find out and are now having to research alternatives.  If a Freshdesk competitor (or the product Freshdesk copied) found out about this issue it could be a real Freshdesk-killer.


Just directing some resources at this would result in a lot of existing customers being pleased (and retained.) Every time they announce a new feature or functional change and major issues like this remain unaddressed I just have to wonder if they care about the customer post-sale at all and feel that retention is important or if it's an attitude of "ha, got 'em".   One can't help but have the impression that they really have no direction when it comes to prioritizing existing issues over pet projects and Freshdesk truly is an offshore code-mill with a bunch of autonomous programmers doing what they will.  


SMTP is not a "send and forget" mail transport and it is important enough that Sendgrid provides an API for this data, so why doesn't Freshdesk care enough to provide customers insight into this HIGHLY CRITICAL information?  Oh that's right, you already are a subscribed Freshdesk customer by the time you need this data so they don't care. 


  • Contributor
  • November 29, 2016

I don't know that they don't care, but to be honest I would never have gone with Freshdesk if I'd known about this issue. I do wonder why we haven't at least heard anything about progress. It's not inspiring much confidence.


I've hung on in hope that this gaping hole in functionality would be plugged but I'm going to have to inform the owner of the company soon just to cover my own rear, and I expect he will want to go elsewhere.


Hi everyone,


Apologies for our delayed response. While we are actively working on a feature that will inform agents of delivery failures, we have also been taking steps to ensure the improved deliverability of emails and that has been our first step to solving this problem in the long run.  


Further to this approach, in a short while from now (about 2-3 weeks) we will be releasing a feature that will facilitate customers to digitally sign their outgoing communication sent using Freshdesk with DKIM authentication as well as SPF validation.  Soon after the release of this feature, we will follow up with updates on our approach to providing information on delivery failures. Thanks for being patient and bearing with us while we develop a comprehensive fix for this issue.


  • Community Debut
  • February 2, 2017

Is there any update on resolving this issue. My company is quite new in implementing Freshdesk, but to be honest if I had known about this issue I would never implement Freshdesk in our system. I'm not confident that our emails are being sent as I have received several queries from our clients that they have not received our emails. At first we thought that they went to trash or spam but then we determined that they never were sent. 


This is quite serious issue and we, as most of your valued customers, would appreciate quick resolution of this issue. In last post by Arvin (Administrator) you have mentioned 2-3 weeks for rolling out new features that will help us in implementation. Is there any update on it?


  • Contributor
  • February 2, 2017

Maybe you guys should check this:

https://sendgrid.com/docs/API_Reference/Webhooks/event.html


I'm not trying to simplify, but a 30 second Google search shows me that there are API hooks in the sendgrid system to handle this sort of thing.  I'm sure that someone there must be able to create this.


Seems that this would be able to be done for as many advanced functions as you have in FreshDesk.  My last request about this was 5 months ago.  Seems that we should be able to have some kind of answer in that amount of time - not to mention that this post has been out here for a year ago.


I don't think it would be a stretch to believe that there are FAR more people interested in knowing whether their emails were delivered than for the FreshDesk system to try to "guess" what the emotion of the last update might have been from a user with a smiley, neutral, or frowny face.


I'm not trying to downplay your roadmap or fun new features, but this is super CORE to the system being usable and valuable.


Please provide an update to your community of users so we know when to expect this.


  • Community Debut
  • February 2, 2017

Come on, freshdesk. You already have this feature implemented in freshsales.io. Please copy it to freshdesk ASAP, PLEASE!


  • Contributor
  • February 2, 2017

I also think that this is an essential issue that has to be resolved.


  • Contributor
  • February 2, 2017
+1. This is top priority for anyone using Freshdesk to send emails or replies to customers (probably everyone). Hoping to hear some positive updates from the Freshdesk Team about this ;)

  • Contributor
  • February 2, 2017

I'm waiting to hear "two weeks" again.  With so many upset people over this (and rightly so as it damages customer confidence) I can't believe they've kicked this down the road so long.


Hi everyone,


While I have mentioned in one of my previous posts that this feature is of utmost priority to us and we are actively building it, I agree that we have taken more time than anticipated. I am truly sorry for keeping you waiting for so long but believe me when I say that we have been steadily building this feature. We hit a few roadblocks along the way - but I'll skip expanding on that for the sake of brevity :)


Here's how we've built this feature so far:


(a) Summarized failure information on a conversation:

If a conversation has failed recipients, we will indicate the number of failed recipients (including CC addresses) on the ticket details page:


image


(b) Further info on failed recipients:

On expanding the failure details, we will show an agent friendly error message indicating the reason for the failure of each recipient:


image


(C) Mail failure as trigger on Observer

While the above may be good enough to give information on failures, we understand that you might want to take certain rectification steps following a failure. Assuming an agent reply failed to reach the ticket requester or a CC address, you might want to have the status of the ticket changed to open, or add a tag, or send a notification to the group supervisor or perform any other suitable step based on your workflow. For that reason, we have also added the failure events to the observer rules:

image


While not common, we understand the extent of the impact that a failed reply can cause, and hence we have tried to solve the problem in the most comprehensive way possible instead of implementing a quick fix. I hope you bear with just a little while longer while we finalize our implementation, check for stability and start the roll out process for all our customers. 

I will update this thread when we have completed the rollout of the feature. Until then, thanks for all your feedback and active participation!