I maybe have an idea. If this is the problem I'm thinking of, it's not a problem of Magento.
Sometimes, a customer wants a shop, but also already has a homepage for his domain. For sending emails from a domain, when you register a domain, you usually get a mailserver that's responsible for this specific domain. This "being responsible for a domain" can be checked. Open the supertool and use mx:anydomain.com. This will show you the mailserver that's responsible for this domain.
Now, Magento supports sending mail only through a local MTA (mail transfer agent, basically the program that takes the mail and contacts the servers to pass them along). Now imagine that the customer has in Magento configured his mails to be sent from myshop@customerdomain.com. Now customerdomain.com already has a mailserver that is responsible for it, which you can check with supertool.
What now happens: The magento servers MTA takes the mail and connects to the mailserver where the mail should go (the domain from the "to:" address). However, there's a mechanism that the destination server can (and most of the time does) use to determine if the server he's talking to (the magento server) is allowed to send mails from that address (customerdomain.com): The also checks what you check with supertool. Then he compares who he is talking to to who is responsible for the domain of the from: address. And if these two don't match, we have a problem.
3 things can happen, and I know of instances of all 3 happening:
- The mail gets delivered.
- The mail gets delivered, but sent to the SPAM folder.
- The mail gets rejected or dropped.
If your MTA is good, you might find information about what happened with the mail in your system logs (/var/log/mail*). If what I described here is the case, you can add a module that supports sending of Magento mails via external mail server.
Have you checked your Magento logs yet? We recently had a client who reported the same symptom on their 1.9.1 installation. When we checked the Magento logs, we discovered that their system was making calls to a PHP module called mb_string() which were failing.
Fatal error: Call to undefined function mb_convert_encoding() in /public_html/lib/Pelago/Emogrifier.php on line 556
That mb_string() function is used in Magento 1.9.1 to strip out CSS styles from your email templates and inline them into your outbound email HTML code for supporting Mail Clients that won’t render CSS 3 styles : http://www.myintervals.com/blog/2014/12/02/magento-and-the-intervals-emogrifier-class/
Their web host did not have this PHP module installed / enabled, so the function calls were throwing errors before the logic that sends the actual message can be executed, causing emails to not be sent.
If your logs show a similar error, you may need to contact your web hosting provider to see if they can enable support for mb_string()
If they don't support it, you'll need to find another host who offers support for it if you want to continue running 1.9.1
If this error isn't being thrown in your logs, you may find one of the answers submitted in this discussion may apply : New order email confirmation not being sent
Best Answer
If you have same problems when you send your letter, you can see it in a file
exception.logbecause inapp/code/core/Mage/Core/Model/Email/Queue.phpit is provided (you can seeMage_Core_Model_Email_Queue::send()at the end of method). But if exception doesn’t appear, it doesn’t means that recipient got your letter. It means that letter was sent to the mail service (successful execution of the functionmail()in PHP).