How to send 100,000 emails weekly? [closed]

Question

How can one send an email to 100,000 users on a weekly basis in PHP? This includes mail to subscribers using the following providers:

• AOL
• G-Mail
• Hotmail
• Yahoo

It is important that all e-mail actually be delivered, to the extent that it is possible. Obviously, just sending the mail conventionally would do nothing but create problems.

Is there a library for PHP that makes this simpler?

Selfseeker

Answer 1

Short answer: While it's technically possible to send 100k e-mails each week yourself, the simplest, easiest and cheapest solution is to outsource this to one of the companies that specialize in it (I did say "cheapest": there's no limit to the amount of development time (and therefore money) that you can sink into this when trying to DIY).

Long answer: If you decide that you absolutely want to do this yourself, prepare for a world of hurt (after all, this is e-mail/e-fail we're talking about). You'll need:

• e-mail content that is not spam (otherwise you'll run into additional major roadblocks on every step, even legal repercussions)
• in addition, your content should be easy to distinguish from spam - that may be a bit hard to do in some cases (I heard that a certain pharmaceutical company had to all but abandon e-mail, as their brand names are quite common in spams)
• a configurable SMTP server of your own, one which won't buckle when you dump 100k e-mails onto it (your ISP's upstream server won't be sufficient here and you'll make the ISP violently unhappy; we used two dedicated boxes)
• some mail wrapper (e.g. PhpMailer if PHP's your poison of choice; using PHP's mail() is horrible enough by itself)
• your own sender function to run in a loop, create the mails and pass them to the wrapper (note that you may run into PHP's memory limits if your app has a memory leak; you may need to recycle the sending process periodically, or even better, decouple the "creating e-mails" and "sending e-mails" altogether)

Surprisingly, that was the easy part. The hard part is actually sending it:

• some servers will ban you when you send too many mails close together, so you need to shuffle and watch your queue (e.g. send one mail to [email protected], then three to other domains, only then another to [email protected])
• you need to have correct PTR, SPF, DKIM records
• handling remote server timeouts, misconfigured DNS records and other network pleasantries
• handling invalid e-mails (and no, regex is the wrong tool for that)
• handling unsubscriptions (many legitimate newsletters have been reclassified as spam due to many frustrated users who couldn't unsubscribe in one step and instead chose to "mark as spam" - the spam filters do learn, esp. with large e-mail providers)
• handling bounces and rejects ("no such mailbox [email protected]","mailbox [email protected] full")
• handling blacklisting and removal from blacklists (Sure, you're not sending spam. Some recipients won't be so sure - with such large list, it will happen sometimes, no matter what precautions you take. Some people (e.g. your not-so-scrupulous competitors) might even go as far to falsely report your mailings as spam - it does happen. On average, it takes weeks to get yourself removed from a blacklist.)

And to top it off, you'll have to manage the legal part of it (various federal, state, and local laws; and even different tangles of laws once you send outside the U.S. (note: you have no way of finding if [email protected] lives in Southwest Elbonia, the country with world's most draconian antispam laws)).

I'm pretty sure I missed a few heads of this hydra - are you still sure you want to do this yourself? If so, there'll be another wave, this time merely the annoying problems inherent in sending an e-mail. (You see, SMTP is a store-and-forward protocol, which means that your e-mail will be shuffled across many SMTP servers around the Internet, in the hope that the next one is a bit closer to the final recipient. Basically, the e-mail is sent to an SMTP server, which puts it into its forward queue; when time comes, it will forward it further to a different SMTP server, until it reaches the SMTP server for the given domain. This forward could happen immediately, or in a few minutes, or hours, or days, or never.) Thus, you'll see the following issues - most of which could happen en route as well as at the destination:

• the remote SMTP servers don't want to talk to your SMTP server
• your mails are getting marked as spam (<blink> is not your friend here, nor is <font color=...>)
• your mails are delivered days, even weeks late (contrary to popular opinion, SMTP is designed to make a best effort to deliver the message sometime in the future - not to deliver it now)
• your mails are not delivered at all (already sent from e-mail server on hop #4, not sent yet from server on hop #5, the server that currently holds the message crashes, data is lost)
• your mails are mangled by some braindead server en route (this one is somewhat solvable with base64 encoding, but then the size goes up and the e-mail looks more suspicious)
• your mails are delivered and the recipients seem not to want them ("I'm sure I didn't sign up for this, I remember exactly what I did a year ago" (of course you do, sir))
• users with various versions of Microsoft Outlook and its special handling of Internet mail
• wizard's apprentice mode (a self-reinforcing positive feedback loop - in other words, automated e-mails as replies to automated e-mails as replies to...; you really don't want to be the one to set this off, as you'd anger half the internet at yourself)

and it'll be your job to troubleshoot and solve this (hint: you can't, mostly). The people who run a legit mass-mailing businesses know that in the end you can't solve it, and that they can't solve it either - and they have the reasons well researched, documented and outlined (maybe even as a Powerpoint presentation - complete with sounds and cool transitions - that your bosses can understand), as they've had to explain this a million times before. Plus, for the problems that are actually solvable, they know very well how to solve them.

If, after all this, you are not discouraged and still want to do this, go right ahead: it's even possible that you'll find a better way to do this. Just know that the road ahead won't be easy - sending e-mail is trivial, getting it delivered is hard.

T

@Piskvor: If you time your mails appropriately you can send as many out as you like. Trouble happens when you send too many mails too quickly. I send out around 30,000 newsletter mails to subscribers on a cycle of 20 mails per minute through a ASP.Net cache call back. Its been working for over two years now and never gets blocked. – Gunplay

@Syed Sajid Nizami: I do mention this somewhere in the second list. Note that rate throttling is not a end-all-be-all solution, as your newsletter would take about 1500 minutes (30000/20=1500, a bit longer than one day) to send out. For a 100k e-mails, this comes out to over three days, and for larger volumes, you wouldn't be finished with one newsletter when it's time to send another. – T

When the mails get blocked the server gets blacklisted and my network admin has set up a notification for that and we submit request for it to get the server out of the blacklist. – Gunplay

Answer 2

People have recommended MailChimp which is a good vendor for bulk email. If you're looking for a good vendor for transactional email, I might be able to help.

Over the past 6 months, we used four different SMTP vendors with the goal of figuring out which was the best one.

Here's a summary of what we found...

AuthSMTP

• Cheapest around
• No analysis/reporting
• No tracking for opens/clicks
• Had slight hesitation on some sends

Postmark

• Very cheap, but not as cheap as AuthSMTP
• Beautiful cpanel but no tracking on opens/clicks
• Send-level activity tracking so you can open a single email that was sent and look at how it looked and the delivery data.
• Have to use API. Sending by SMTP was recently introduced but it's buggy. For instance, we noticed that quotes (") in the subject line are stripped.
• Cannot send any attachment you want. Must be on approved list of file types and under a certain size. (10 MB I think)
• Requires a set list of from names/addresses.

JangoSMTP

• Expensive in relation to the others – more than 10 times in some cases
• Ugly cpanel but great tracking on opens/clicks with email-level detail
• Had hesitation, at times, when sending. On two occasions, sends took an hour to be delivered
• Requires a set list of from name/addresses.

SendGrid

• Not quite a cheap as AuthSMTP but still very cheap. Many customers can exist on 200 free sends per day.
• Decent cpanel but no in-depth detail on open/click tracking
• Lots of API options. Options (open/click tracking, etc) can be custom defined on an email-by-email basis. Inbound (reply) email can be posted to our HTTP end point.
• Absolutely zero hesitation on sends. Every email sent landed in the inbox almost immediately.
• Can send from any from name/address.

Conclusion

SendGrid was the best with Postmark coming in second place. We never saw any hesitation in send times with either of those two - in some cases we sent several hundred emails at once - and they both have the best ROI, given a solid featureset.

Bethune

Answer 3

Here is what I did recently in PHP on one of my bigger systems:

1. User inputs newsletter text and selects the recipients (which generates a query to retrieve the email addresses for later).

2. Add the newsletter text and recipients query to a row in mysql table called *email_queue*

   • (The table email_queue has the columns "to" "subject" "body" "priority")

3. I created another script, which runs every minute as a cron job. It uses the SwiftMailer class. This script simply:

   • during business hours, sends all email with priority == 0

   • after hours, send other emails by priority

Depending on the hosts settings, I can now have it throttle using standard swiftmailers plugins like antiflood and throttle...

$mailer->registerPlugin(new Swift_Plugins_AntiFloodPlugin(50, 30));

and

$mailer->registerPlugin(new Swift_Plugins_ThrottlerPlugin( 100, Swift_Plugins_ThrottlerPlugin::MESSAGES_PER_MINUTE ));

etc, etc..

I have expanded it way beyond this pseudocode, with attachments, and many other configurable settings, but it works very well as long as your server is setup correctly to send email. (Probably wont work on shared hosting, but in theory it should...) Swiftmailer even has a setting

$message->setReturnPath

Which I now use to track bounces...

Happy Trails! (Happy Emails?)

Delineator