<p>This error could be caused by the relationship between the user used in your SMTP Email settings in Craft and the From Address set in your Form notification. Some Mail Servers don't allow the sender (From Address) to be different from the SMTP user. Can you confirm if your From Address is the same email address in your SMTP settings?</p>

<p>Additionally, you may want to update your SMTP settings to use Mandrill or Mailgun. Those services make it pretty easy to look at your sent mail and see if it's being delivered and can provide more insight into what is happening if it is not being delivered.</p>

CC BY-SA 3.0
2015-12-17T00:37:17.557Z
2015-12-17T00:37:17.557Z
Ben Parizek
<p>A little history on this problem before I share my experience. It may be of value to somebody.</p>

<p>The form notifications were firing inconsistently. I'd fill out the form and get notified. The agency that hired me wouldn't. Occasionally a customer "in the wild" would fill out the form and notifications would fire. Occasionally they wouldn't. There was no rhyme or reason. I couldn't find a pattern.</p>

<h1>PROBLEM #1: INCONSISTENCY</h1>

<p>I had the Sender Email address dynamically set to the submitter's email. This worked fine in all my setup and testing, except - as it turns out - in cases where the submitter was using a @gmail, @hotmail or @yahoo address. These would fail silently. This is probably due to the SMTP issues discussed here, but email isn't in my skill set so that's just a guess. </p>

<p>The inconsistency was due to human nature - I would default to my non-gmail/yahoo/hotmail address when filling out the form and it would work. Same deal with others. My client used a gmail address (and it failed).</p>

<p>When I changed the FROM and REPLY-TO all notifications were firing to all parties. Except the client.... Even when I changed the FROM/REPLY-TO to something innocuous like my email, the client's Office365 was still ignoring the notificaitons.</p>

<h1>PROBLEM #2: SMTP</h1>

<p>I know very little about email (more, now) so this took a while to sort out.</p>

<p>I did some Googling and found this was sort of a common thing, getting Office365 to play nice with notification emails from forms. SMTP always seemed to be the answer so I looped in the Office365 admin and got that info.</p>

<p>Entered it and hit the "Test Email" button. No dice. Errors. </p>

<p>While I Googled around looking for explanations and we added the web server's IP to a whitelist in Office 365. </p>

<p>Back in SMPT-land I was thrown by the labeling of the field <strong>System Email Address</strong> in the Craft settings and the instructions <em>"The email address Craft will use when sending email."</em>  I took that to mean the address the System would send reports to which was set to my email address.</p>

<p>On a whim I tried the SMTP login email there as well and the test email worked (as @Ben Parizek wisely suggests).</p>

<p>I then changed the FROM/REPLY-TO to the Office365 address (which is also the TO address, by the way) and all is functioning smoothly.</p>

<p>I'll take the blame on that one, though I believe a clearer instruction line could help. Maybe something including "From"...</p>

<p>All is functioning now and everybody is happy. The client was wonderfully patient during this whole process so I count myself lucky in that regard.</p>

<p>A special shoutout to the Sprout support team who were looking into Problem #1 when it got sorted out. They were very helpful and responsive.</p>

CC BY-SA 3.0
2015-12-17T15:01:58.230Z
2015-12-17T16:26:47.070Z
2015-12-17T16:26:47.070Z
secondbridge
<p>I've got a few Sprout forms on a site that are functioning nicely. Data is being save and notifications are firing to 2 of the 3 addresses. The third address is an Office 365 mailbox on the same domain but hosted elsewhere.</p>

<p>I'v tried updating Craft's Email setting to the SMTP info provided by the IT company in charge of the mail but it's erroring out with:</p>

<p><code>SMTP Error: data not accepted.</code></p>

<p>Has anybody else had issues with this? A little Googling has led me to believe that this is a common issue. Wondering if anybody in the Craft community has dealt with it successfully.</p>

<form><plugin-sproutforms>
Sprout Forms Notifications to Office 365 address failing
# Sprout Forms Notifications to Office 365 address failing

(Asked by: username_0 on 2015-12-16)

I've got a few Sprout forms on a site that are functioning nicely. Data is being save and notifications are firing to 2 of the 3 addresses. The third address is an Office 365 mailbox on the same domain but hosted elsewhere.

I'v tried updating Craft's Email setting to the SMTP info provided by the IT company in charge of the mail but it's erroring out with:

`SMTP Error: data not accepted.`

Has anybody else had issues with this? A little Googling has led me to believe that this is a common issue. Wondering if anybody in the Craft community has dealt with it successfully.

**Tags:** form, plugin-sproutforms


---

## 2 answers

### Answer by username_1 on 2015-12-17. Score: 1 | Accepted answer

This error could be caused by the relationship between the user used in your SMTP Email settings in Craft and the From Address set in your Form notification. Some Mail Servers don't allow the sender (From Address) to be different from the SMTP user. Can you confirm if your From Address is the same email address in your SMTP settings?

Additionally, you may want to update your SMTP settings to use Mandrill or Mailgun. Those services make it pretty easy to look at your sent mail and see if it's being delivered and can provide more insight into what is happening if it is not being delivered.


---

### Answer by username_0 on 2015-12-17. Score: 1

A little history on this problem before I share my experience. It may be of value to somebody.

The form notifications were firing inconsistently. I'd fill out the form and get notified. The agency that hired me wouldn't. Occasionally a customer "in the wild" would fill out the form and notifications would fire. Occasionally they wouldn't. There was no rhyme or reason. I couldn't find a pattern.

# PROBLEM #1: INCONSISTENCY

I had the Sender Email address dynamically set to the submitter's email. This worked fine in all my setup and testing, except - as it turns out - in cases where the submitter was using a @gmail, @hotmail or @yahoo address. These would fail silently. This is probably due to the SMTP issues discussed here, but email isn't in my skill set so that's just a guess.

The inconsistency was due to human nature - I would default to my non-gmail/yahoo/hotmail address when filling out the form and it would work. Same deal with others. My client used a gmail address (and it failed).

When I changed the FROM and REPLY-TO all notifications were firing to all parties. Except the client.... Even when I changed the FROM/REPLY-TO to something innocuous like my email, the client's Office365 was still ignoring the notificaitons.

# PROBLEM #2: SMTP

I know very little about email (more, now) so this took a while to sort out.

I did some Googling and found this was sort of a common thing, getting Office365 to play nice with notification emails from forms. SMTP always seemed to be the answer so I looped in the Office365 admin and got that info.

Entered it and hit the "Test Email" button. No dice. Errors.

While I Googled around looking for explanations and we added the web server's IP to a whitelist in Office 365.

Back in SMPT-land I was thrown by the labeling of the field **System Email Address** in the Craft settings and the instructions *"The email address Craft will use when sending email."* I took that to mean the address the System would send reports to which was set to my email address.

On a whim I tried the SMTP login email there as well and the test email worked (as @username_1 wisely suggests).

I then changed the FROM/REPLY-TO to the Office365 address (which is also the TO address, by the way) and all is functioning smoothly.

I'll take the blame on that one, though I believe a clearer instruction line could help. Maybe something including "From"...

All is functioning now and everybody is happy. The client was wonderfully patient during this whole process so I count myself lucky in that regard.

A special shoutout to the Sprout support team who were looking into Problem #1 when it got sorted out. They were very helpful and responsive.


---

