On the logs page the subject column is empty against Opened and Clicked events logs. The email subject is also missing in clicked and opened events API response. The email subject is also missing in Clicked and Opened webhooks response.
This make it difficult for those who want email subject base statistics.
These logs and responses contain message-id so on base of message-id the email subject can be extracted and added to logs and response.
I am working on a project where client want email subject base statistics , all other events have subject but clicked and opened doesn't have. I tickle the issue by getting message id from response and call event API with filter message-id and delivered event and get subject from that response.
If the subject exists in response i will have no need to re-call API.
Secondly it's difficult for my client to verify the result what is stored in local databse for clicked and opened event against subject as the logs at dashboard doesn't contain subject against clicked and opened events.

I am using a route to post incoming message to an API for processing. If the processing is successful, all is fine. If there is a processing problem, Mailgun correctly retries to post after a period of time.

I would like a way I can see all the emails that are waiting to be re-tried? I can see them in the log marked as "Will retry in 900 seconds:", but it is difficult to determine which emails are still waiting to be processed.

I want to see a list of everything that is currently waiting to be retried. That way, I can determine if there is a bug in my processing, or if I need to add more compute power to process the queue.

Recently, I setup an SMTP account. I used a strong password generator. That password had special characters in it. When I went to use it, I got a very generic message that said Mail Gun does not love my credentials. The could be solved one of two ways. 1) Preferred - Have validation on the SMTP box when you create the credentials to not allow for special characters and a message to that effect if some are used. This would stave off this situation right at the beginning. 2) Not preferred but workable - Change the error message that comes back to say "You have special characters in your password and that is a no-no." I really like 1) the best. Thanks for listening.

Not sure if this is the correct place to post this but it's where live chat told me too. This seems more of an oversight/bug then like "feedback" but apparently you need the Admin role to see and use the Clear Domain Queue button in domain settings. That doesn't seem right because I have the Developer role right now and can just about do anything in the UI from creating new domains, assigning IP's, creating and deleting mailing list; I can even delete domains completely YET I can't clear the message queue for a domain?

Clearly that logic doesn't make any sense at all and is not protecting anything as roles are setup for if I can delete the domain surely that's going to clear the queue and everything else associate with that domain. Thus that leads me to believe the permissions set for that button are not correct and was overlooked and should be corrected to the appropriate level to view.

Pros:

• Good customer service

• decent documentation

• easy to get going

Cons:

• Mailgun feels like its from the 80s. the UX is drab, and really ugly.

Been using AWS Heroku, and Google Cloud lately, and those interfaces feel like a rocket ship in comparison.

• Alot of what mailgun feels like a black box to me. This is my first real time using transaction email, but their is a heap that mailgun could teach, and be transparent about what they do under the hood.

• Setting up dns could be better. would be good to be able to download a file/text and upload directly to cloudflare or cloudfront

TL;DR: Some SMTP issues are not logged as event, this can lead to multiple email sending without noticing it.

Let me tell you a (true) strory:

A customer calls us to let us know he receives the same email multiple times from us. We find this really weird… but, hey! He take time to notify us: let's dig into our multiple level of logs… We found nothing speaking to us… So we ask for an example to our customer… He send it back to us… We, now, can determine what mail was send multiple times… And, what a surprise when we jump to the mail history we see the following events:
Accepted, Opened, Opened, Opened, …

Look: no delivered event while the mail has been opened.

Asking for insights to Mailgun support, we get the following response:
```
Every time we submitted the request it failed internally with the following error,

data write failed: write tcp4 A.B.C.D:10277->E.F.G.H:25: i/o timeout

Because we didnt get delivered response we continued to attempt delivery until we receive the delivered response. This would be the cause of the multiple deliveries.
```
(where A.B.C.D is our sending IP and E.F.G.H the destination MX IP)

So we ask why we did not get the error event:

Our apologies for any inconvenience. Unfortunately, these types of failed events are actually classified as internal and are not public facing to the customer.


So… I think that this is an issue: we have no feedback on sending issue, we cannot monitor them, and over all, it could hurt our reputation without knowing it.

Yes, here is some feedback

1. Onboard was very bad in the segment of signup. I wrote a ticket for this. As a web developer can say signup form is really, really badly done, you must spend more time to make a sign-in process much better. My suggestion is that you first create an account, do not take people's credit card on the first screen. You first want to capture their name and email, so you can have them in your database for marketing. Then on the second screen to complete the signup process ask them for all necessary card data. And please, make sure form and buttons work right and form validation especially since that is the biggest problem for now. Regarding other onboarding stuff you need to better explain what domain people should use, that is the confusing part. I was always using EMAIL.domain.tld (subdomain) because I got that from your manual, but 1 year later I realized I wrongly interpreted your manual.

2. Just fix UI a bit, make it a bit more spacious and modern. Make everything in "flat" design, move submenu and logo in the navbar and make few changes, not complete redesign, because it would make customers crazy :) But just small cosmetic changes (Even we can help you with that, we are doing design as well)

3. We strongly recommend Mailgun to all of our clients. We especially love it because you are not trying to be all in one solution to have email builders, automation and the rest of the stupid stuff. You are transactional email service, and we, developers, love that and easy integrations. Just stay like that. If you need money, just charge us 1-2$ per month for the low quantity customers (That's for sure significant amount of money per month) just don't try to be all in one and too confusing.