Magento – New Customer Registration Emails Not Received by Some Customers

This is not a problem of Magento itself.

But if you send mails directly via a mail delivery agent from your webserver, the configuration of this one might be neglected.

I am assuming you send via the standard Linux mail delivery.

You have the following options:

1. configure your mail system on the Magento server to use a well configured mail server for example of your ISP
2. use an extension - AShroder's SMTP Pro module would fit.

One interesting provider which promises (untested) to take a lot of effort that your mail is actually delivered is Amazon SES - the module you mentioned also has a dedicated interface to Amazon SES.

mb_string() is a decent place to start looking, as we ran into it also while working the first occurrence of this issue I've seen in the wild. AND It's easy to check : if that's the root cause, you should see something like the following in your system.log:

Fatal error: Call to undefined function mb_convert_encoding() in /public_html/lib/Pelago/Emogrifier.php on line 556

I wrote up some additional details of mb_string() behavior on this answer.

However, if mb_string() was the root cause in this case, none of the emails would be going out and it appears that the new account setup and the comment notification emails are being delivered, just not the order confirmation emails.

In that earlier discussion above, mb_string() wasn't the root cause : the submitter wound up resolving the problem by changing the senders email address domain of the store's outbound emails. It appeared his SMTP server was rejecting emails that came from the same domain as the server itself. Oddly enough, Lucas had the exact same problem, but reversed - his mail agent was blocking all emails that were being sent fro a DIFFERENT email address than the domain for which the server itself was configured. Changing the emails sent to use an address that matched the server's configured domain resolved the problem for him.

Again, I don't think that applies to this case since you're delivering mail on 2 of the 3 scenarios.

On a related question, another user reported similar issues where he could send the new user and comment notification emails but not order confirmation emails and he pointed out that when he tried to enable cron.sh that didn't succeed but it did handle the queue processing duties when he scheduled cron.php instead. You should be able to schedule with either of them, though depending on the default configuration of your EC2 instance, you may have to update some config settings to make sure your cron jobs are running without errors.

Ashley Schroder, the author of the SMTP Pro plugin you're using, recently wrote a great blog post on the changes in mail handling that has been implemented in Magento 1.9.1. I found another similar technical deep dive from Željko Prša over on the Jake Sharp Blog.

There are a couple of key take-aways you should check based on this analysis:

1. First, do you see all of the outbound order emails in the new "Queue" table core_email_queue? If the queue is being processed, you should see a timestamp value in the processed_at column corresponding to when the email was sent. If NOT, that may be indicating that those messages are not being processed by the queue cron scheduler. If you DO see a timestamp value in that field, that means the scheduler is processing the emails but the delivery is failing further down in the stack. The code that delivers it to your outbound SMTP system may be failing or the SMTP system itself may be failing to deliver the messages.
2. As Ashley points out in his post, the way the new system is implemented in Magento CE 1.9.1 is conditional : Mage_Core_Model_Email_Template first checks to see if there is a queue, and if it finds out, it uses that mechanism. If it doesn't find one, it should fallback to sending emails out immediately. If that's happening in your case, you won't find any entries in the core_email_queue table for Order Confirmation emails, so at least you would be able to confirm that it's not queue processing failures that are the root cause of your problem.
3. Ashley also points out that the Email Update Feature Documentation and the Official Magento Release Notes appear to have statements that contradict what myself and many others have observed first hand - that only the Order Confirmation emails are using the new queue system, which would explain why your other emails are being delivered but not the Order Confirmation emails.

If you get to this point in your troubleshooting and you have your Heartbeat Cron Scheduled, you may want to try the following test in Aidan's answer to yet another question about email issues in 1.9.1:

navigate to http://yourmagentodomain.com/cron.php and keep refreshing that page every five minutes and you'll see the queued order emails start to go out. The Heartbeat Cron is supposed to do this for you.

So if you start seeing the emails get processed in the queue when you try this test, that should tell you that you either :

1. Fix whatever problem you may be having with your cron.sh based scheduler in your current install.
2. Switch to the cron.php based scheduler like The Oldman did

Several other users have commented in some way or another that if their queue processing fails for any reason, the automated processing scripts won't seem to resume until they have manually cleared out any "stuck" items in their queues, so if your initial troubleshooting doesn't seem to resolve the problem, you may want to try that next.

By the way, I'd echo everyone who's recommended installing the AOE_Scheduler extension - it's a much more productive way of managing scheduled tasks in Magento and troubleshooting them when they don't work like you'd expect. They just released the official 1.0 release - you can install it from their source tree over at GitHub or download it from Magento Connect.