Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"(techcrunch.com)
techcrunch.com
Mailgun (YC W11) Raises $1.1 Million For Its "Twilio For Email"
http://techcrunch.com/2011/05/13/mailgun-raises-1-1-million-for-its-twilio-for-email/
70 comments
I met the Mailgun guys and they seemed really sharp so it's good to see them getting money. I wish this had been around a year ago - there are so many odd corner cases to managing a transactional email system, it's a pain to deal with. Companies like Sendgrid are only handling one small part of the problem. Good luck and congrats on the funding!
Would somebody care to sell me on why this is superior to SendGrid or Amazon Simple Email Service? (Or perhaps what use cases it better serves.)
As far as I know, most e-mail products focus only on sending e-mails and not receiving them. Mailgun works both ways.
Sendgrid accepts incoming emails: http://nanceskitchen.com/2010/02/21/accept-incoming-emails-i...
My interpretation is that this provides a mailbox API, to provision and maintain mailboxes on THEIR servers. Doesn't sendgrid just perform a restful post when an email is received rather than store it and all? Almost akin to pop vs imap.
[deleted]
Actually we do "everything email":
Detailed searchable mail logs: we actually tell you what happens to every single one of your messages - nobody else is that brave!
Incoming email push - and our parsing/cleanup of incoming traffic is pretty impressive - if it's time to self-promote, it's now. And our incoming email handling if flexible: we do routing/forwarding, similar to Rails/Django routes.
Storing/hosting your email traffic and giving POP3/IMAP access to it - nothing stops you from giving each user of your app their own email address. Some customers do that very, very creatively.
Piping it through some battle-tested Mixpanel-powered analytics doesn't hurt too: some companies charge an arm and a leg just for that one feature.
Mailgun is not about merely pushing mail, we're more of an "sexy programmable ESP" :) We're just a bunch of oddballs who thought that running an ESP business would be fun!
Detailed searchable mail logs: we actually tell you what happens to every single one of your messages - nobody else is that brave!
Incoming email push - and our parsing/cleanup of incoming traffic is pretty impressive - if it's time to self-promote, it's now. And our incoming email handling if flexible: we do routing/forwarding, similar to Rails/Django routes.
Storing/hosting your email traffic and giving POP3/IMAP access to it - nothing stops you from giving each user of your app their own email address. Some customers do that very, very creatively.
Piping it through some battle-tested Mixpanel-powered analytics doesn't hurt too: some companies charge an arm and a leg just for that one feature.
Mailgun is not about merely pushing mail, we're more of an "sexy programmable ESP" :) We're just a bunch of oddballs who thought that running an ESP business would be fun!
This a completely off-topic and pendantic, but I just thought I'd throw this out there. On this page:
http://mailgun.net/pricing
I personally have a hard time parsing how much money $0.5 is. I'm assuming you're charging 50 cents per 1K messages. My mind groks $0.50 per 1K messages, much more easily.
http://mailgun.net/pricing
I personally have a hard time parsing how much money $0.5 is. I'm assuming you're charging 50 cents per 1K messages. My mind groks $0.50 per 1K messages, much more easily.
Thanks for sneaking a grok in there. HN just wouldn't be the same without hipster buzzwords!
I'm a happy SendGrid customer, but I'll definitely give you guys a look. Thanks for the details.
Does a product have to always be superior to its competitors in order to exist?
Nope. I was genuinely curious whether and how Mailgun was superior to those products.
No, but if it isn't, then why even bother launching it?
purely for competition.
to some degree, customers make up their own minds about what's "better" when comparing two products/services that may be identical in functionality and pricing.
Someone may prefer the colors/logos on one site vs another, some may prefer where one is located (located in my city/state/country vs the competitor). Some may care about the technology, wanting to support one supplier vs another.
to some degree, customers make up their own minds about what's "better" when comparing two products/services that may be identical in functionality and pricing.
Someone may prefer the colors/logos on one site vs another, some may prefer where one is located (located in my city/state/country vs the competitor). Some may care about the technology, wanting to support one supplier vs another.
Twilio is awesome because setting up Asterisk and acquiring phone numbers is a big pain in the butt and requires knowledge most web developers don't have.
Sending email isn't hard. Amazon SES solved that.
Receiving email is just slightly more work, but still well within the comfort zone of most developers:
Sending email isn't hard. Amazon SES solved that.
Receiving email is just slightly more work, but still well within the comfort zone of most developers:
$ cat /etc/aliases
comment_reply: "|/path/to/email_handler"Sending and receiving email is easy, unless you want it to work reliably, do intelligent processing, etc.
SES is extremely easy, and I seriously doubt any claims that they're more reliable/faster than what Amazon is offering.
What kind of intelligent processing are they offering?
In the use case of turning a reply into a comment the hard work is not receiving and parsing the email, it's authenticating the user/adding the comment to the database.
I'm a potential customer who just doesn't see the value proposition. I'm sure they can build a business as a Sendgrid competitor, but I don't see anything as disruptive as Twilio here.
What kind of intelligent processing are they offering?
In the use case of turning a reply into a comment the hard work is not receiving and parsing the email, it's authenticating the user/adding the comment to the database.
I'm a potential customer who just doesn't see the value proposition. I'm sure they can build a business as a Sendgrid competitor, but I don't see anything as disruptive as Twilio here.
Staunch: there will always be guys who want to do everything themselves. But we're selling to folks who have other things to worry about.
Risking to re-type our own front-page, I'll go ahead and give you some tips for how Mailgun can be useful:
Once a message is sent, what happens to it? We give you searchable SMTP logs: see if some crazy admin guy in Canada misconfigured greylisting (because he likes to do everything himself :) and your customer's mail is sitting in a repeat-later loop for 5 days.
Once a message is received, are you sure you'll figure out the encoding of it? Or what happens if your process/machine is down when the message arrives? What if it's spam? And why not record computer-to-person email conversations you're software is doing in a real POP3/IMAP mailbox? No coding required.
On intelligent processing: we transcode all your traffic to UTF-8 and figure out what parts of the message is quoted - so you won't have to. It's not easy, ever wondered why some folks resort to "reply above this line"? Also, if there's no plain text part, we'll generate it from HTML. More is coming.
Mailgun is not an email sending service. We're a full-featured programmable ESP, it's up to developers what they want to use our email servers for. The creative ones keep amazing us every day! :)
Risking to re-type our own front-page, I'll go ahead and give you some tips for how Mailgun can be useful:
Once a message is sent, what happens to it? We give you searchable SMTP logs: see if some crazy admin guy in Canada misconfigured greylisting (because he likes to do everything himself :) and your customer's mail is sitting in a repeat-later loop for 5 days.
Once a message is received, are you sure you'll figure out the encoding of it? Or what happens if your process/machine is down when the message arrives? What if it's spam? And why not record computer-to-person email conversations you're software is doing in a real POP3/IMAP mailbox? No coding required.
On intelligent processing: we transcode all your traffic to UTF-8 and figure out what parts of the message is quoted - so you won't have to. It's not easy, ever wondered why some folks resort to "reply above this line"? Also, if there's no plain text part, we'll generate it from HTML. More is coming.
Mailgun is not an email sending service. We're a full-featured programmable ESP, it's up to developers what they want to use our email servers for. The creative ones keep amazing us every day! :)
I don't like to do everything myself. I'm actually very inclined to outsource stuff like this.
It doesn't sound very interesting for sending email. The receiving part is more interesting.
Still, it doesn't seem like it would save me enough time to warrant implementing your API, dealing with yet-another-service, and paying.
I don't mean to be too negative. One of my favorite kinds of businesses is taking something every company already does and "productizing" it.
Maybe I'll get tired of dealing with it myself and sign up. Either way, good luck!
It doesn't sound very interesting for sending email. The receiving part is more interesting.
Still, it doesn't seem like it would save me enough time to warrant implementing your API, dealing with yet-another-service, and paying.
I don't mean to be too negative. One of my favorite kinds of businesses is taking something every company already does and "productizing" it.
Maybe I'll get tired of dealing with it myself and sign up. Either way, good luck!
Automatic detection of which bits are quoted sounds good.
Having just gone through the process of setting up a VPS to handle sending and receiving email, processing bounces and recording delivery receipts I'd say that, fundamentally, this isn't challenging.
Then again I've also setup my own SMPP server for sending SMS and didn't find that particularly difficult either :)
Some of the inbound processing features sound pretty good - how about offering them as a paid-per-transaction service? I wouldn't bother outsourcing the sending and receiving per se because it's cheap and easy to do that myself, and I then have control over the up (or down!) time but being able to pass a message through your service and pay, say, $1 per 1000 messages processed with no storage costs would be kinda cool.
I'm imagining getting back some kind of structured document (XML and/or JSON) allowing me to see quoted messages, interleaved replies, attachments, encoding blah blah basically all that stuff you're talking about.
Having just gone through the process of setting up a VPS to handle sending and receiving email, processing bounces and recording delivery receipts I'd say that, fundamentally, this isn't challenging.
Then again I've also setup my own SMPP server for sending SMS and didn't find that particularly difficult either :)
Some of the inbound processing features sound pretty good - how about offering them as a paid-per-transaction service? I wouldn't bother outsourcing the sending and receiving per se because it's cheap and easy to do that myself, and I then have control over the up (or down!) time but being able to pass a message through your service and pay, say, $1 per 1000 messages processed with no storage costs would be kinda cool.
I'm imagining getting back some kind of structured document (XML and/or JSON) allowing me to see quoted messages, interleaved replies, attachments, encoding blah blah basically all that stuff you're talking about.
Would love to learn more about the SMPP server and your setup, is there a writeup or pointers to more info anywhere?
Hey, sorry I just checked this thread. I just use Kannel! You can use Kannel with a GSM modem as a "fake SMSC" or you can get an SMPP connection to one of the many SMS aggregators worldwide that allow it. SMPP is generally faster than HTTP in terms of throughput, but in terms of functionality (for example, setting the sender id) most aggregators have comparable offerings in both SMPP and HTTP APIs.
One major difference I've found with SMPP vs. HTTP APIs is on the inbound side of things - ie. receiving messages on a virtual number. Some aggregators I've used don't pass the UDH (user data header) through in inbound requests so you can't stitch long inbound messages together (this is, in my opinion, the driving force behind Twitters much vaunted 140 character limit - if they'd had an SMPP connection with the UDH in-tact they wouldn't have had to restrict posts to "140 characters reserving 20 characters for the username).
Even with kannel, though, you still need to stitch long messages together manually. I posted my sample implementation for this in PHP to the Kannel lists a few years back:
http://comments.gmane.org/gmane.comp.mobile.kannel.user/1664...
I've been using the same setup for years with no problems.
One major difference I've found with SMPP vs. HTTP APIs is on the inbound side of things - ie. receiving messages on a virtual number. Some aggregators I've used don't pass the UDH (user data header) through in inbound requests so you can't stitch long inbound messages together (this is, in my opinion, the driving force behind Twitters much vaunted 140 character limit - if they'd had an SMPP connection with the UDH in-tact they wouldn't have had to restrict posts to "140 characters reserving 20 characters for the username).
Even with kannel, though, you still need to stitch long messages together manually. I posted my sample implementation for this in PHP to the Kannel lists a few years back:
http://comments.gmane.org/gmane.comp.mobile.kannel.user/1664...
I've been using the same setup for years with no problems.
I kind of agree, I've used SES for a side project through Mailchimp's STS api and it is pretty simple and reliable, and quite free at first. Other than some other bells and whistles like handling unsubscribes I'm not sure MailGun is that much more revolutionary.
I've heard people say before that to beat Gmail you can't just build an email service 10% better. Gmail works well enough that 10% isn't worth the switching costs. Same goes for this I believe.
I've heard people say before that to beat Gmail you can't just build an email service 10% better. Gmail works well enough that 10% isn't worth the switching costs. Same goes for this I believe.
SES is extremely easy. Unless you actually care about deliverability. Deliverability on the modern internet is hard. SES does not handle this. If Mailgun handles deliverability well, that alone is worth the price. Making it programmable is awesome.
Amazon implements trust-based dynamic throttling and only allows verified email addresses. I don't think anyone else does both.
Where's your evidence that anyone has better deliverability than SES?
Where's your evidence that anyone has better deliverability than SES?
Nobody can claim to sell you "better deliverability". It largely depends on 2 things, they are easy to understand:
1. Infrastructure. A lot goes into this, and you can Google what needs to be done, and do it yourself if you have the time.
2. Content quality. If your recipients keep flagging your mails as spam, nobody will help you - that's your responsibility not to spam people.
Myriads email sending services do #1. Mailgun, among many other things, does that too. Plus, we can give you a completely separated, dedicated setup where your reputation won't be affected by other senders (something SES can't promise you).
But in the end, you need to send something people want to read. Saying "email company X gives you automatic deliverability" is a bit like saying that "hosting company Y gives you automatic PageRank" :-) Yes, your emails will be 100% solid on protocol/format/rate level and the IP you're sending from is watched, but you'll be taken down if you're spamming.
Hope this helps. And if you need assistance regarding deliverability (on your own server, or with Mailgun) - shoot me an email at [email protected] BTW, this mailbox is hosted by Mailgun itself. see? we're eating our own dogfood here!
1. Infrastructure. A lot goes into this, and you can Google what needs to be done, and do it yourself if you have the time.
2. Content quality. If your recipients keep flagging your mails as spam, nobody will help you - that's your responsibility not to spam people.
Myriads email sending services do #1. Mailgun, among many other things, does that too. Plus, we can give you a completely separated, dedicated setup where your reputation won't be affected by other senders (something SES can't promise you).
But in the end, you need to send something people want to read. Saying "email company X gives you automatic deliverability" is a bit like saying that "hosting company Y gives you automatic PageRank" :-) Yes, your emails will be 100% solid on protocol/format/rate level and the IP you're sending from is watched, but you'll be taken down if you're spamming.
Hope this helps. And if you need assistance regarding deliverability (on your own server, or with Mailgun) - shoot me an email at [email protected] BTW, this mailbox is hosted by Mailgun itself. see? we're eating our own dogfood here!
>"Plus, we can give you a completely separated, dedicated setup where your reputation won't be affected by other senders (something SES can't promise you)."
Ahh, so you're using a different IP / subnet for each customer, then? With the internet running out of IPv4 space, I think that companies that do this kind of thing should just have all their addresses revoked. Same goes for "SEO web hosting"
Ahh, so you're using a different IP / subnet for each customer, then? With the internet running out of IPv4 space, I think that companies that do this kind of thing should just have all their addresses revoked. Same goes for "SEO web hosting"
>Sending email isn't hard. Amazon SES solved that.
I don't see how Amazon SES can be said to have "solved" a problem when you need a dedicated 3rd party to do it. As long as you still have to pay regularly, there's still a problem in need of a solution. (And there's still space for someone else to come in and either solve it better or charge a lower fee.) We can't resign ourselves to Amazon, Google and the other big players being the sole providers of these sorts of services.
I don't see how Amazon SES can be said to have "solved" a problem when you need a dedicated 3rd party to do it. As long as you still have to pay regularly, there's still a problem in need of a solution. (And there's still space for someone else to come in and either solve it better or charge a lower fee.) We can't resign ourselves to Amazon, Google and the other big players being the sole providers of these sorts of services.
We've been using Mailgun for all of our email on http://lanyrd.com/ - sending messages via their REST API (and using them to receive bounces and email unsubscribe requests). It was easy to integrate and we haven't had any deliverability problems - they gave us plenty of great advice about that.
I've spent a bunch of time talking to them about email, and they really know their stuff.
I've spent a bunch of time talking to them about email, and they really know their stuff.
Your recommendation in a previous blog post made me sign up for their service and I have been a happy customer for a few months.
This is literally the greatest service I have come across. Honestly, it was like a godsend, all day I was studying on all these little details required to having a solid, protected, non-blacklisted, works on ec2, stable, spam-free, e-mail server.
After hours of configuring postfix and looking at files I never wanted to even know about I took a break on HN.
Then I saw Mailgun, boom.. problem solved. (With more bells and whistles then I even imagined)
I've now saved part of my life thanks to this product.
Even chatted with one of their dev's who is extremely helpful. This is the kind of company I would want to invest in.
After hours of configuring postfix and looking at files I never wanted to even know about I took a break on HN.
Then I saw Mailgun, boom.. problem solved. (With more bells and whistles then I even imagined)
I've now saved part of my life thanks to this product.
Even chatted with one of their dev's who is extremely helpful. This is the kind of company I would want to invest in.
Honestly just to add, I like this product so much that i've considered porting their helper libs to every language they don't already cover.
(I worked with Ev for a year, before he did YC.) The whole Mailgun operation is top notch. If you want to do cool things with email, definitely check out MG.
For a over a month now we've been using the service, and it's been smooth sailing without a hitch - really impressed and interested to see what these guys do next
Wow, this will save me hours in development time. Guess procrastinating on HN is useful after all ;). Great service guys, congrats!
To the ppl at Mailgun following this thread: I want to see you guys succeed. Please spend a portion of your funding on getting a better website design. The content of the site was enough to get me to sign up, but you'd be surprised just how much the look and feel of a site matter to some customers.
Will do! Do you mind if I contact you in private regarding specific design issues you'd want to point out? My email is in my profile.
Thanks.
Thanks.
Sorry for the late reply. I'm not a designer myself, just know when a final design is bad or good.
You don't need something flashy. Something Neat, simple and attractive that gets the USP across will do. Check out the sites of some of your YC classmates, like Indinero for example.
You don't need something flashy. Something Neat, simple and attractive that gets the USP across will do. Check out the sites of some of your YC classmates, like Indinero for example.
Very good suggestion and it's really needed. Since the service is mostly focused on developers we can "forgive" a not so polished interface, but the overall look and feel could use some improvement.
Can anyone comment how this compares to context.io? (which also appeared on HN)
http://context.io
It seems to me that the analogy "Twilio for email" works better when applied to context.io, which aims to give a uniform API to all mailbox operations.
http://context.io
It seems to me that the analogy "Twilio for email" works better when applied to context.io, which aims to give a uniform API to all mailbox operations.
context.io turns mailboxes into databases you can tap into. They are especially good with attachments. is there an API call to send or receive email with context.io? I am not sure.
from what I get, mailgun makes it easy to send/receive emails, so that email is a completely integrated feature of your web app, meaning users won't even have to check their email, the experience is all within the app. You can also do it the other way around with mailgun, which is interacting with the user in his email client, so he doesn't have to go in the app.
from what I get, mailgun makes it easy to send/receive emails, so that email is a completely integrated feature of your web app, meaning users won't even have to check their email, the experience is all within the app. You can also do it the other way around with mailgun, which is interacting with the user in his email client, so he doesn't have to go in the app.
Hey guys, it's Sarah-Jane, Community Manager at Context.IO. Yup, you got it. We don't host dedicated mailboxes that your application can receive and send emails from, but since we make the contents of any IMAP account available to your app, whatever is received in that account is like your app receiving it. For the sending part, we're leaving that to Mailgun and other services that focus on this.
hey Sarah-Jane, the reply above was from me heri from @mtw
why mailgun.net? you're losing people who are typing mailgun.com
Congratulations on the funding. Feedback - Logo is not click able on the documentation page.
Can I use your service to send emails on behalf of my clients. We have an bulk email campaigns app, that our clients use to send their mail. I am looking for a SMTP service where we can send email on their behalf.
Killer service, but two things jump out. 1) Need dkim signing by own domain and 2) envelope sender should match from address. These don't matter if you're sending to consumer domains (gmail, yahoo), but, as I've learned, they do matter for corporate environments, which are fragmented and antiqued.
We use and love Postmarkapp (http://www.postmarkapp.com). They have an awesome interface, and SMTP relaying is reliable, and nice reports. MailGun seems to go further than Postmarkapp though, in that they doing inbound automatons.
Hey Justin, thanks for the love. We've been battle-testing our inbound processing before releasing it to the wild. If you'd like to take it for a spin, drop me an email - [email protected] - and we can get you set up in the private beta. You can be sure that it'll be just as reliable and easy to use (and easy to look at) as the rest of the Postmark you're used to :)
An encrypted mailbox service would be nice, considering our privacy is pimped out by the big guys.
[deleted]
I can see that on the top of their list already. Somebody has to fix this problem with less-complicated solution than PGP.
Somebody has: http://www.watchguard.com/products/xcs-overview.asp
Not seen one myself yet, but $Boss who went to infosec came back impressed and is trying to arrange some for testing.
Not seen one myself yet, but $Boss who went to infosec came back impressed and is trying to arrange some for testing.
I'm working on it. :) We hope to have a private alpha start the end of next month.
I am definitely interested in this, do you have any website up yet? Any possible way to get onto that private alpha? ;-)
Website is http://ClickLock.com/. We've pivoted slightly, so some of the details are out of date, but there is a sign-up form at http://clicklock.com/install/ for people wanting an early look.
I'm working through the pivot tech changes, then will update the web site at that point.
I'm working through the pivot tech changes, then will update the web site at that point.
Congrats guys. I beleive this is going to be huge, especially for enterprises.
"Let your users leave comments, answer simple questions, upload data as attachments and interact with each other using their email clients."
Q: So a customer can reply back to one of your emails and it turns into a comment?
thanks
Q: So a customer can reply back to one of your emails and it turns into a comment?
thanks
With a little bit of coding on your part - yes.
I'm curious about this. I found the tagging functionality for outbound mail. If I tag an outbound message, and someone replies to it, can I easily read back the tag from the reply message?
Put another way--I want to send an outbound email in relation to a specific thread/ID, and if someone replies I want to associate their reply with that ID. What's the best way to do this with your system?
Put another way--I want to send an outbound email in relation to a specific thread/ID, and if someone replies I want to associate their reply with that ID. What's the best way to do this with your system?
For your use case I would add your own Message-ID MIME header to the
outgoing message. When a user replies, usually (in most cases) you'll
see the ID of the original message as In-Reply-To header.
And it will be posted as In-Reply-To HTTP parameter to your app. There's also "References" MIME header you can use.
I hope this helps.
And it will be posted as In-Reply-To HTTP parameter to your app. There's also "References" MIME header you can use.
I hope this helps.
Off topic: Is your username a reference to BBC Three's Old Gregg "episode"? I sure hope so. =)
hosted/saas james?
http://wiki.apache.org/james/
http://wiki.apache.org/james/
Far more complicated than that. You won't scale james to millions+ of mailboxes as we're planning to :)
Cool, best of luck. I've used two competitors services and spent far too many days pulling my hair out over unexplained slowdowns and api errors. It would be extra cool if you guys did an architecture blog post.
ok why does everything these days have to be described as "Twilio for XYZ"
No disrespect to twilio, I think they've done a great job, but they aren't huge yet. They also weren't the first infrastructure PaaS to hit the market.
No disrespect to twilio, I think they've done a great job, but they aren't huge yet. They also weren't the first infrastructure PaaS to hit the market.
lol....because E-Mail pipes are e-mail processing is "hard". I don't see a real need for this. Twilio is useful because interfacing phones is hard. E-Mail is just plain-text and is pretty simple to parse server-side.