I wrote a script in Perl to query our db and send out messages to every active account (those that have verified addresses). Took about ten minutes, including testing on a small dummy data set. Since the task is so trivial, I've written similar scripts (in many languages...bash, Python, PHP, and probably others) dozens of times in the past ten years.
Protip: Use a properly configured actual mail server (Postfix, Sendmail, exim, etc.), and use your script to inject into the queue (using library bindings or simply the 'sendmail' command or equivalent). Many standalone SMTP libs are crap, and will lead directly to the bitbucket. Strict RFC compliance is more important with mail than any other protocol.
Also, don't sort by destination domain. Many mail providers will filter or rate limit (or worse) your deliveries if you send many messages all at once. This was once the Right Way to deliver, since there are optimized methods of sending many messages to the same SMTP host, but spammers have killed that enhancement. You may also want to sleep for a second or two between each message or batch of messages, for the same reason. Our list of 5000, or so, users took a few hours to send...but most of them made it to their destination, and very few bounced (almost entirely just those that were actually invalid email addresses).
Doing it yourself seems to be a great idea if you want all of your emails to end up in people's spam folders. Here's a great article explaining all of the reasons why you might end up that way:
Much easier is to just use something like Constant Contact. Our emails seem to have a very high delivery rate through them. There's definitely some pain in the ass as they don't offer an API for syncing your userbase with their list, but if you're a small company for whom development time is valuable it's hard to beat.
As long as you're diligent, it's not that difficult to deliver e-mail successfully. It really depends on what kind of e-mail you're sending and how frequently you send it. That being said, monitoring bounces, watching junk mail reporting programs, etc can quickly become a full-time job.
The answer isn't do to one or the other -- it depends on the situation.
It can be done, I just can't see doing it yourself being worth it until you have a large number of people to whom you are frequently mailing.
Someone else said "it's really not worth it to go third-party unless you're sending heavy HTML newsletter type e-mails to hundreds of thousands or millions of people. "
My thought is the exact opposite. When you're small, it's not worth committing the resources to doing all you need to do yourself. Third party services cost $10 or $20 a month and save you hours of work, and increase delivery rates greatly. (At least they did for us and the few other startups I've talked to about this.) When you're large, the cost of third party services exceeds the cost of doing it yourself, and you can get better quality in house.
If you are doing it yourself, I hear good things about Return Path, but have no first hand experience.
I think when you're small it really depends on your application. If email isn't an important part and you aren't sending high volume, then I definitely agree it can be a huge time-sink and very tough to figure out.
But if you really want control of your email it's not that difficult to do if you follow best practices.
WRT Return Path - I'm pretty sure Twitter turned to them when they had trouble delivering mail. Part of what they do is email whitelisting, which I fundamentally disagree with. But if you read the paper on how they helped twitter out with best practices there is actually a lot of good stuff in there (things that you can do on your own if it's important or you're at that scale).
The author of that article is from CampaingnMonitor, which has a great user interface, and their pricing makes them one of the best options for startups or smaller companies that want to do something like send a monthly newsletter. They do have an API for synching your userbase.
I am working at StreamSend, a small company that has some of the best rates for sending thousands of emails a month, and an API which exposes basically the entire app.
I use DynDNS.org mail relay and Godaddy.com mail relay to send out messages rather then sending them out myself.
I store every message in the database, then I have a script that runs to check for new messages. I track if there is an error in sending and I use a different mail relay if the message failed to send.
Centralizing the mail system has been a huge pain relief. I was sending mail out from each script that needed to send mail, now I have more control and a central point of failure if there is a problem. Plus I can schedule mail such as reminders that need to be sent off in the future.
I do mail this way because I work for a company that sends out there own mail and it is a huge hassle. People click on the "Spam" button even on email technical support and billing receipt messages. They just do not care. I have spent hundreds of hours on mail over the last few years and would be pretty happy to never send one out myself though my own IP address.
Just some custom wrapper for PHP's mail() using QMAIL.
Unfortunately, now we're on EC2 and there's no way to pass reverse DNS lookups on e-mail originating from an instance. That's bad.
Looked through many third-party solutions, but they are expensive and impose artificial limitations, so we're basically going to get another machine outside of EC2 and use that.
Delivering e-mail reliably does have a slight learning curve, but it's really not worth it to go third-party unless you're sending heavy HTML newsletter type e-mails to hundreds of thousands or millions of people. Knowledge of e-mail and the issues surrounding its successful delivery is knowledge you can carry from project to project or start-up to start-up, so it's not such a bad idea.
I wouldn't recommend doing it on your own, or at least use a well known smtp server for relay (where you have access to).
Especially hotmail can be very tricky. If a few users complain about your mails, they will put you on a ban list and your emails will be routed to /dev/null. Tehy won't even appear in the spam folder of the user.
I don't have a startup, but I use Gmail for domains on my personal page. I just use postfix and some really basic scripts. Also, you might find these posts helpful:
http://searchyc.com/sending+mail
But, I'll answer anyway...
I wrote a script in Perl to query our db and send out messages to every active account (those that have verified addresses). Took about ten minutes, including testing on a small dummy data set. Since the task is so trivial, I've written similar scripts (in many languages...bash, Python, PHP, and probably others) dozens of times in the past ten years.
Protip: Use a properly configured actual mail server (Postfix, Sendmail, exim, etc.), and use your script to inject into the queue (using library bindings or simply the 'sendmail' command or equivalent). Many standalone SMTP libs are crap, and will lead directly to the bitbucket. Strict RFC compliance is more important with mail than any other protocol.
Also, don't sort by destination domain. Many mail providers will filter or rate limit (or worse) your deliveries if you send many messages all at once. This was once the Right Way to deliver, since there are optimized methods of sending many messages to the same SMTP host, but spammers have killed that enhancement. You may also want to sleep for a second or two between each message or batch of messages, for the same reason. Our list of 5000, or so, users took a few hours to send...but most of them made it to their destination, and very few bounced (almost entirely just those that were actually invalid email addresses).