Best practice for mass (group) emailing

Anyone have any suggestions? I'd really appreciate any input here... :)

@opheliadesign I would use the Mail::queue function (http://laravel.com/docs/5.0/mail#queueing-mail). Putting a job onto a queue is very fast and this way you can let a worker process the mails. More information can also be found in these 2 Laracasts lessons. Putting all recipients in the BCC field shouldn't be an option.

https://laracasts.com/lessons/bulk-email-notifications-part-1

https://laracasts.com/lessons/bulk-email-notifications-part-2

@flo thanks for the tip! I'll check out those lessons, I did not see them before.

I'm using Iron.io for push queues and I'm a bit worried about flooding it with commands. I gave up trying to get Beanstalkd working on my Forge provisioned Digital Ocean server after upgrading to L5.. :/

@flo The lessons you linked to look intriguing but too long for me to watch at the moment (probably later this evening). In addition to targeting large groups of recipients (100+) at a time, I also need the flexibility to target small groups or even individuals. I've also had terrible luck with Mandrill, numerous complaints of people not receiving emails that they marked as "Delivered," so I have switched to Mailgun. Since Mailchimp == Mandrill I'm a bit reluctant to take this approach.

Does he mention simply iterating through email addresses and using Mail::queue? That's the first thing that came to my mind, just wondering what impact that will have on the server and Iron.

@opheliadesign Use a service like MailChimp or Campaign Monitor.

@opheliadesign I also had terrible exps with Mandrill, I sent a massive list of emails but only some got delivered. I dug out, and found that only the last created API key is guaranteed for delivery, all other keys sometimes work, sometimes do not. To send lots of email, first, use a third-party massive mail sender; second, use a background worker for sending mail; and, the last, apply queue to mail method.

The sending of emails boils down to what settings you have on your DNS. If they didn't receive them, they've either been blocked/filtered and you don't have the right records to sign the emails.

Well MailChimp isn't really meant for transactional emails.

@bashy, everything was correct in terms of DNS. It was totally random, Mandrill would report Delivered, users would report "I never received it! I've looked everywhere!" Switched to Mailgun and complaints stopped.

@JeffreyWay these aren't transactional emails I'm talking about, they're group emails. Basically, the application I'm building allows users to email each other from within the site. This could be to a few people or hundreds, depending on their selection.

So, with that information, what is best? Thanks for the input, everyone, really appreciate it. :)

@opheliadesign Yeah from their point of view, the data was sent and received (so to speak) by the server for the email itself. It's then down to that server to deal with it and show it to the user. If for some reason Mandrill is blocked, that could be why. I've never had any issues, all my emails are signed.

Sorry, I missed a couple of replies above. @petehouston glad it's not just me! Can you explain what you mean by "only the last created API key is guaranteed for delivery?" I did not change API keys, to my knowledge.

Also, "To send lots of email, first, use a third-party massive mail sender; second, use a background worker for sending mail; and, the last, apply queue to mail method." Do you mean in order of the best approach to the least favorable or using all in combination somehow?

Thanks!

@bashy there was never an indication that there was a problem whatsoever. Either Mandrill is horrible about reporting mail server bounces/rejects or something else is going on. I've read posts by others around the Web that this is a pretty common issue with them. Maybe some of us are just unlucky.

@opheliadesign open the Settings board on Mandrill, check whether the last created by date time API is used in your app. In my experiences, the latest one is guaranteed to work perfectly.

Also, "To send lots of email, first, use a third-party massive mail sender; second, use a background worker for sending mail; and, the last, apply queue to mail method." Do you mean in order of the best approach to the least favorable or using all in combination somehow?

Example, first - Mandrill, second - Beanstalkd, third, in code Mail::queue(). That's what I'm using now. It works fine for me until now.

Maybe what I'm using is not cool or good butI don't care what is best to use, I just use what works best for me.

@JeffreyWay I was thinking about this again the other day when I received a notification that someone had replied to a post on Laracasts. Because each Post can have many subscribers, I'm assuming you are not setting up a mailing list on Mandrill (I see that's what you use to send them, based on the click tracking).

Just wondering, how are you handling this? Do you iterate through a list of addresses and then use Mail::queue()? If you could share your method I'd really appreciate it. :) Thanks!

Hello @opheliadesign did you find an answer to this? I'm looking forward. Thanks

@opheliadesign I recommend mailgun for those transactional and bulk emails. It will serve you better by avoiding junk email boxes and getting blacklisted as a spammer. They have great docs and how-to's. I have never had a problem with them.

@ejdelmonico and how can you send them? Via queues? Even if they are 10,000 e-mails?

@ndiiorio This page gives some highlights https://www.mailgun.com/sending-email

...and this https://documentation.mailgun.com/api-mailinglists.html#mailing-lists

You can try out Aws API to send bulk email with laravel. There are a lot of tutorials to set up Laravel and AWS for sending email.

https://vannstudios.com/send-bulk-email-in-laravel-with-amazon-ses-t-1