Is there anything in Sprout Forms or Craft that prevents an email being sent to any registered Craft user email address but not other email addresses not in the Craft user list?

I have a really simple one field form that sends a notification to two email addresses: the one in the submitted form field, as well as the one in the CP Sprout Forms notifications field.

A weird thing is happening. If I use an email address that is not belonging to a Craft user (either as the typed in notification address or the {email} one) the email is sent (according the server logs) and received. If I use an email address belonging to a Craft user the email is not sent from Craft (doesn't even register in the server logs).

(The simple form is trying to distil the problem down - it is occurring on all my forms, and was working before but has stopped, possibly the same time as a server change. The PHP mail() function works to said email addresses. I am using latest versions of Craft and Sprout Forms on PHP 7.)

Edit: I can swap email addresses in and out of the user list so when they belong to a user no email is sent, and when they are removed from the user list, the email is sent. This suggests there is nothing wrong with the email address per se or the route through the system, but purely the fact that it is a Craft user email address.

Edit2: When sending to a craft user email address the following craft.log error is made: Email error: Could not execute: /bin/mini_sendmail (etc) This doesn't happen when a non-craft user email is used. So suggests to me Sendmail is not properly set up (but why then do other emails get through fine).

  • I would guess from your edits that this is a CraftCMS issue, as I haven't had this issue with Sprout Forms. Are you running the latest versions of Craft/Sprout? As an aside, have you dropped Barrel Strength or Pixel&Tonic a line? I assume you have, but always worth asking.
    – Joshua M
    May 2, 2017 at 13:38
  • Yes, I've more or less eliminated Sprout Forms from the equation by now. I have found that using SMTP mode with working service solves the problem all around. However I am still intrigued why the failure is only happening with Craft users. My vague assumption is that a different mechanism is used to send email to users compared to non-users, which seems a little unlikely. Yes, the latest versions as of two days ago are in place for both. I didn't ask Barrel Strength as I don't think it is a Sprout Forms problem given that the email Test from the Control panel also fails. May 3, 2017 at 5:25
  • Can you reproduce this problem in another environment? I've had sendmail issues on more than one host, so my guess is you've got a server-specific issue—and it could be working fine but extend to sending policies and other stuff that's a pain to troubleshoot. If SMTP (Mailgun, Sparkpost, SendGrid) is an option, it'd be a great way to get around the problem and avoid relying on a server's sendmail implementation. You might also consider detailing your Craft mail settings in the question, along with some environment info.
    – Matt Stein
    May 3, 2017 at 17:24
  • 1
    Sounds like a sendmail configuration issue to me. FWIW, both sendmail and PHP's mail are notoriously unreliable and shouldn't be used in production environments.
    – Brad Bell
    May 3, 2017 at 19:11
  • 1
    Thanks @Matt and Brad. I could not reproduce this in another environment. In the end I have taken your suggestions and used SMTP (without issues), and will be converting all my websites that use sendmail or PHP mail to SMTP. I think there are benefits beyond just getting the email "out of the server" as mentioned. May 8, 2017 at 21:47

2 Answers 2


As mentioned in the comments, this is likely an email configuration issue and Brad's comment should be taken to heart:

both sendmail and PHP's mail are notoriously unreliable and shouldn't be used in production environments

Craft should not be treating user emails differently than non-user emails and Sprout Forms isn't doing anything unique when it sends notification emails, it's just piggybacking on what Craft is doing.

Sending your email through a service like Mailgun (or any similar service) will give you more visibility into what's happening and what you may need to troubleshoot. Sprout Email has a Sent Email Element Type that you can enable to help troubleshoot some email deliverability issues on the Craft side of things.

For two good overviews on troubleshooting email errors in Craft, see:

Another direction to consider when troubleshooting an error like this may be to look closer at the From headers and what emails you are sending to. Is it really just Craft Emails vs non-Craft Emails or could there be other patterns? For example, maybe the emails that aren't being received are all gmail addresses. In some cases, if you are sending to a gmail address you own from a gmail address you own, Google may suppress the email from appearing in your inbox.

  • Thanks @Ben. I looked for other patterns but did not find any. The other domains were a range of domains, including non-Google app domains. The clincher for me was that I could take any of the affected addresses (any of website domain, Gmail, Google app email, hoster ISP domain, and NZ's biggest ISP), and in each case I could make them a Craft user email and the email would fail (with log error), or remove them from Craft user email and email would be delivered. May 8, 2017 at 21:44

Are the craft users' e-mail addresses on the same domain as the hosting is running? I've ran into the issue before that the server just "delivers" the e-mail to the local hosting.

For example if your site is running on example.com:

[email protected] - goes through
[email protected] - doesn't go through - gets "delivered" to local server's inbox

  • Thanks @Rias. In this case the Craft users email addresses where both of the same domain and a range of other domains, and the non-Craft users were also of the same and a range of other domains. That was in-fact my first reaction but I soon ruled it out as a pattern. May 8, 2017 at 21:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.