I too did not consider sending mail from applications a big deal, until I had to do it on a huge scale. Turns out it gets quite difficult to maintain an email module that consistently avoids your outgoing app emails being spam-flagged or otherwise corrupted. It's a neat service.

I agree that it's not easy to do mail right, that's my daily business. But that's also the reason why i was wondering. I probably just don't like the marketing speak of the website (as if it would be something unusual to do SPF or mail routing or filtering or regex, etc. etc.). On the other hand it is hard enough in this business already. You need to point out that stuff, ok..

Anyhow, i have been downvoted for a serious question. Sorry i did upset people with a question....

I think you were getting down voted because its not the kind of comment folks come to HN to read. It sounds like from this comment that you're a competitor? ("that's my daily business")

There is a lot of information on mailgun, both on HN and on the web. They've made no secret of the problem space they were going after.

So Rackspace felt like they were worth acquiring, the product and customers are supported so its not a strict acquihire exit, and while the questions about sendgrid are good here (which are proxies for "What is Rackspace's strategy as a services provider really?") there clearly was enough to Mailgun to make this worthwhile. That you don't "get it" is ok but instead of the snarky "Soo they just send email?" kind of thing why not dig into their product and ask specifically about it? If it seems un-remarkable then talking about how you implement the same features and qualifying the scale of that would be helpful too.

I didn't downvote you, but I suspect it might have more to do with the style of the question that was maybe somewhat easy to misunderstand. I don't think anyone is upset.

But I go disagree about the marketing copy. It says on the front page "Email for developers. Mailgun is a set of powerful APIs that allow you to send, receive, track and store email effortlessly." To me this conveys exactly the information I need about the service. I'm just disappointed they didn't play with the railgun analogy more, but still there is a reasonably cute mail gun gadget ;)

It's not just email deliverability. Mailgun's email API is super useful and worth learning because once you do you'll realize you can now do things with transactional emails in your app you never considered doing before. A few ways in which they are better than Sendgrid: (1) much better inbound JSON parsing of emails that can be used with any "route"; (2) On the fly route creation, modification and removal; (3) Pass through routing of individual mailboxes to your GoogleApps account for corporate email addresses. This is better than the Sendgrid approach because it allows you to put Mailgun in front of Gmail instead of the other way around. That could mean a noticable difference in speed of delivery of transactional emails reaching near real time relative to what you'd normally expect with email (<20 seconds).

If you're just sending in bulk, go with SendGrid, but if you want to do anything mildly interesting with email-as-an-interface, Mailgun cannot be beat. I'm honestly surprised it has taken other mail providers to offer these same features.

I just finished my first integration with MailGun (moving over from PostMark because MailGun has a better feature set imo) ... could not have been easier.

They have webhooks built in that can call your application when mail is delivered, bounced, opened, clicked, etc. That's huge for me. I allow my clients to send out emails to their users — now I can use that information to show my clients who has opened which emails ... I can also alert users if their email has become blocked or had a bounced email.

They give you a ton of functionality out of the box that would take a lot of time and effort to recreate on your own.

Their support for incoming messages is pretty slick, especially in that they provide a message body that strips out signatures and replies. At Posterous, we managed that mechanism ourselves, and it was really hellish – it's great to be able to offload that responsibility for Kinsights.

That feature alone made us switch from SendGrid, and the more reasonable price point for our stage just sweetened the pot.

I assume you were downvoted for saying there is no value in being able to send (and receive) email, but there is.

Deliverability is a huge important issue for most people, if I send an email and it doesn't arrive then I'm in a bad spot. I used a similar service to Mailgun (http://postmarkapp.com) and the amount I paid per month (when I was sending emails) meant if I spent more than 1 hour of my time configuring and managing a mail server every month I would be losing money.

This is an especially big issue for people that are using virtual servers or not that great server providers, ones that recycle IPs, if I'm correct in my understanding of mail deliverability, if an IP has sent spam before it's almost guaranteed to be blocked by most spam protection companies, that sort of thing isn't good.

To me the real value is that for a very fair price I no longer have to be concerned with the ins and outs of sending email. Once you start sending tens of thousands of emails you run into problems. People don't receive the emails. They get blocked. Users accidentally mark them as spam. And so on and so on.

I don't want to focus on figuring out email - I just want to send them and have them get to the users that want them.

I use MailGun for email for the same reason that I use FreshBooks for invoicing my clients — because I want to spend my time building my business rather than focusing on solving a problem that someone else has already done a great job of solving.

This is a great example. I think some of the disconnect with other commenters is thinking that sending email is trivial. It isn't. Even at small scale, deliverability starts to become a problem, there is infrastructure management (for example, this why people use heroku rather than just AWS) and receiving and tracking email requires managing all sorts of email weirdness that are not addressed by using software libraires (this is analogous to html parsing - getting all the non-standard or ambiguous cases right is hard).