Magento 2 - None of transactional emails are sending

Question

None of store's transactional emails are sending (order confirmation, newsletter signup confirmation, account password reset etc).

All settings in backend of magento are good (like "Disable email communication"), all store emails are set.

Cron seems to be working. Here is the rules I got:

*   *   *   *   *   /usr/local/bin/php /home/uspatriot/public_html/bin/magento setup:cron:run >> /home/uspatriot/public_html/var/log/setup.cron.log

*   *   *   *   *   /usr/local/bin/php /home/uspatriot/public_html/update/cron.php >> /home/uspatriot/public_html/var/log/update.cron.log

*   *   *   *   *   /usr/local/bin/php /home/uspatriot/public_html/bin/magento cron:run | grep -v "Ran jobs by schedule" >> /home/uspatriot/public_html/var/log/magento.cron.log

Here is the screenshot of DB:

I am not aware of any 3rd party modules, which would mess with emails either. Here is the screenshot:

I tried to use php mail function from ssh to see if that's the problem, like this:

mail -s testingmail [email protected]
testing message

Nothing happens there.

Tried to do

mail -v [email protected] -- -r "[email protected]"

It returns error that gmail thinks it's spam and therefore blocked the email.

Tried to create php file with simple php mail() function in it, and then run with

php filename.php

It returns that email has been sent, yet nothing is actually happening.

I'm pooped. HELP! :)

UPDATE:

There are bunch of errors like this in update.log: [2017-04-21 03:31:02] update-cron.ERROR: Cron readiness check failure! Found non-writable paths: /home/uspatriot/public_html/php.ini.sample [] [] i don't know if that is the problem. Tried to google - not much info on it.

UPDATE 2:

Got this from server support folks:

*It appears the PHP Mail function is enabled and working properly on the server at this time. I did a quick check for the function to insure it was enabled and then sent a test message manually via command line to my gmail account. I received this within the exim_maillog after that test: This log shows the sending of the message through the PHP Mailer to my test gmail account:

2017-04-20 23:08:18 cwd=/root 4 args: send-mail -i -- [email protected]
2017-04-20 23:08:18 1d1Ovi-000NzU-4X <= [email protected] U=root P=local S=556 T="Iron Maiden" for [email protected]
2017-04-20 23:08:18 1d1Ovi-000NzU-4X ** [email protected] R=lookuphost T=remote_smtp H=gmail-smtp-in.l.google.com [74.125.126.27] X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=yes: 

However gmail did deny the message at their SMTP server due to the message being sent from root and gmail believes it to be a spam message. SMTP error from remote mail server after end of data:

550-5.7.1 [67.225.162.240] The IP address sending this message does not have a\n550-5.7.1 PTR record setup. As a policy, Gmail does not accept messages from\n550-5.7.1 IPs with missing PTR records. Please visit\n550-5.7.1  https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.1 information. l130si775055ita.29 - gsmtp

In conclusion to the original inquiry, all of this indicates that the PHP Mail function is active and working on the server. If you could give us some steps in order to replicate the issue you are encountering we will be able to better investigate. *

Answer 1

From the logs you posted and the conclusion that Gmail is discarding the emails sent because it's coming from an unreal email address. The easiest solution is to set up a "dummy" email address on your domain and then proxy your exim to send through your domain's email provider. I know Postfix can achieve this very easily, not sure about Exim.

Answer 2

Many people struggle with this problem and try many solutions only to come to find out that the problem is that shell access is disabled in your account. If shell access is disabled in your account (especially for shared hosting servers), confirm your cron command url to the cron.php file is correct in cPanel and then modify your cron.php just below line 49: Add this line: $isShellDisabled = true; This works and I tested on Magento 1.9 running on a shell disabled hosting.