# Mail not sent from CiviCRM via SMTP or mail()

I am trying to send email using SMTP settings in the outbound email settings. I have set all the fields according to this post which would be

SMTP server address : ssl://smtp.gmail.com
SMTP server port: 465


I have also commented out CIVICRM_MAIL_LOG in the civicrm.settings.php hence my emails are not sent to a file, for sure. In both mail() and SMTP, the test mail is sent OK according to the popup window (view attached file). But it does not get delivered so it isn't really sent.

I have checked all the related questions. The closest was this CiviCRM not sending mails but the outputs don't match.

 The mails work now. I have implemented the changes suggested by @Siddharth Gupta, below. Also to allow your gmail to send mails you need to change its security to allow access for less secure apps from here

• You'll need to provide your host environment information. Are you on a shared server? VPS? Do you have postfix (or equivalent) installed? If you're on a shared server, are they allowing outbound traffic on that port? Or does your VPS have a firewall that may be blocking you? – Peter Petrik May 17 '16 at 10:29
• Can you test sending to another gmail address? Could it be that @iiitd.ac.in is blocking the delivery of the message? Also I would not recommend using Gmail for email delivery. There are other semi-free solutions, such as SparkPost (+ CiviCRM extension). – bgm May 17 '16 at 13:19
• I think the issue is with google not allowing to use itself as SMTP account, I faced this in one of the python code I was writing. Have a look at this support.google.com/accounts/answer/6010255?hl=en – Siddharth Gupta May 17 '16 at 18:19
• @bgm - Tried with another email address but the problem was different. The mails were redirected to "/dev/null". Fixed that and mails are working now. – Anjali Ujjainia May 18 '16 at 7:18

I think I found the issue. If your CiviCRM is installed via buildkit there is a file ~/buildkit/app/civicrm.settings.d/100-mail.php which sets the CIVICRM_MAIL_LOG to /dev/null. This doesn't allow Civi to communicate to MTA (Mail Transfer Agent).

The first solution is to comment out

//if (!defined('CIVICRM_MAIL_LOG')) {
//  define('CIVICRM_MAIL_LOG', '/dev/null');
//}


Further, because this is a dev/testing environment, you may want to log your emails while you send them. In your civicrm.settings.php add the following lines.

if (!defined('CIVICRM_MAIL_LOG')) {
define( 'CIVICRM_MAIL_LOG', 'log_path/mail.log');
}
define('CIVICRM_MAIL_LOG_AND SEND', true);


CIVICRM_MAIL_LOG_AND SEND allows CiviCRM to log as well as send the emails.

• Also I used ssl://smtp.gmail.com as server and 465 as port – Siddharth Gupta May 17 '16 at 20:09
• Thanks, the solution worked and I am able to send emails now. – Anjali Ujjainia May 18 '16 at 6:31
• Fun fact -- you can override anything in ~/buildkit/app/civicrm.settings.d by creating a file in /etc/civicrm.settings.d. It allows you to manipulate the settings for all builds. For example, I use this to direct mail to a log file: gist.github.com/totten/fa8ed564db5d336aec70cdda46ade0e1 – Tim Otten May 19 '16 at 23:22

so using google smtp is fine for tests, but as bgm mentioned, it won't scale for production, as google doesn't allow you to send a lot of emails that way.

if you have the popup, it means that civi could talk to the mail server successfully, so it's probably working and your set up is correct. What might be the issue is between gmail servers and your university final account. Can you try sending the test to a gmail address, eg the one you use as the sender too?

And double check what email account you set as the sender, it might be as well that the sender email address is not your gmail address, so the anti-spams kills the test email somewhere on the way.

In addition to queuing up the mail, you need to ensure that the cron job for sending them is executing. Look under Admin > System Settings > Scheduled Jobs, then check when the last time Send Scheduled Mailings ran. You may want to click on View Job Log to see if there are any issues it is having. Note that when debugging it can be convenient to click more > Execute Now, and then check the job log again.

• it seems that the issue is there even for the tests emails, so I'd suspect the cronjob isn't the issue – Xavier May 17 '16 at 14:31