Provide option to send Non-Delivery Reports to the original Sender
Mailgun bounce processing works great when a single sender is sending email to a broad audience. It does not work well when there are many original senders each with their own list of contacts.
- Company with 10 to 1000 employees.
- Company switches from a traditional in-house mail solution to Mailgun for all outgoing email.
- John, a typical employee in the organization, sends email to a customer, but spells the address wrong.
Traditional in-house system behaviour:
- John would get a Non-Delivery Report letting him know of his mistake. John would fix his mistake, and re-send the message. The customer would receive the email.
Mailgun-based system behaviour:
- Mailgun notes that the message cannot be delivered and records it as a "bounce". This information is accessible to the email administrator, but not to John.
- John is not aware that his email did not reach the customer. John waits for a response. Customer complains that John never sent him any email. John believes he did.
- John eventually gets the email administrator to look into it, and finds it in the bounce pile for the entire company.
Please implement an option to send Non-Delivery Reports to the original Sender, so that John would be notified that his message was not delivered.
As a side note, it would be beneficial if the Non-Delivery Report looked something like the traditional Non-Delivery Reports, so that software that recognizes these messages such as Outlook or Mailman would be able to understand them.
Tim Bertens commented
Who would be interested to have NDR's handled by an external platform for a small fee?
NJ Andreasson commented
+1. A new route action such as reject() would be an excellent way to implement this.
Arun Sampath commented
Can you add a feature to send bounce email back to the "from" address when the to address is invalid or wrong?
We had this feature in Amazon SES by default before moving to mailgun and this feature is missing in Mailgun
This helped our customers to validate the email address automatically on our platform. So with mailgun we might need to update our platform to do an extra validate email API call implementation.
Sean Bradley commented
Oh wow. We just switched to Mailgun and will probably have to reconsider. I can't believe this isn't available for transactional email.
Maxim Paperno commented
We also couldn't go with Mailgun for SMTP gateway because of this shortcoming, although we liked the overall feature offerings.
Besides the major issue outlined in the original post (individual users not getting any feedback for warnings/errors), our mailing list software also needs to process bounces directly (which is pretty typical, I think). There are webhooks, but integrating those into a perfectly working list server is considerable work. And furthermore the list server would still need to process asynchronous bounces anyway.
Here's an example implementation (sorry for competitor link): https://help.socketlabs.com/docs/my-application-already-handles-bounces-how-do-you-support-this
Possible dupe: https://feedback.mailgun.com/forums/914635-general-feedback/suggestions/8010573-add-bounce-and-complaint-route-actions
Michael Kane commented
Andrew - I think I am not clear on the scenario you're describing. However, there is a third action for /routes, in addition to forward() and stop() - you can also store() with Mailgun or specify a callback destination like so:
Can you clarify your comment by describing in terms of Person 1 / Person 2, and what you would like to occur in that scenario?
Andrew Bucklin commented
Suzzel, your proposal doesn’t solve INBOUND emails. In the route, the only option for inbound messages it to either forward it along or drop it. There is no option to send an NDR back to the external user who sent the email.
I have yet to find the option to send back to the Mailgun administrator. let alone the specific email sender. Other transational email systems like ElasticMail have the option to return the bounce back info to the sender, and without it nobody knows when a message isn't delivered. We can't keep looking at the logs every day on behalf of hundreds of customers whom our LMS sends emails to every day.
Definitely would help make this product even better. We are a IT shop who recommends Mailgun for customers' SMTP traffic but the lack of this feature is always making it less likely for Mailgun to be picked up by new customers.
Pete Schaefers commented
This is spot on! This SHOULD be done! It's a deal killer for many applications. I want to use MG as SMTP for hosting servers, but this lacking feature makes that impossible to consider. Please upvote!
Andrew Bucklin commented
In the same situation as the original poster. +1
Zachary Grimshaw commented
I was going to switch to Mailgun, but this feature is a huge must for me, and for many others. I hope this can get added soon, as it's a crucial function.