Need Help Resetting Email Config for no-reply

Hi @VaughnVernon,

Sorry about the delay, this has now been reset.

Thank you so much, Hrishikesh!

Is there a way for me as an owner to reset to the default no-reply@netlify.com?

It seems like a really good idea to have a Reset button that both clears the settings and persists the change.

Also, is there better documentation on using a Google Workspace email account (alias) as a no-reply accounts? I can’t find much if any useful documentation on this topic (see links).

https://support.google.com/a/answer/176600

https://support.google.com/mail/answer/185833

Thanks in advance for the additional help.

Unfortunately, not at the moment.

I believe any valid SMTP configuration should work. Is that not the case?

No, hat is not the case.

Also our reset on Email configuration was just switched back to the broken state (previous problem). Could we please get the reset / clearing of our custom settings and revert to default settings until we have a working no-reply email?

Thanks!

It’s been reset again.

Thanks, Hrisikesh.

We have just succeeded in getting our GitHub OAuth working and now trying to get Google OAuth squared away.

But the no-reply@vlingo.io with our previous configuration never worked. New registrations were failing due to not receiving confirmation emails.

Someone in a thread somewhere (you, in the Support forum?) said that most of your customers use the default no-reply@netlify.com and suggested sticking with that. It seems strange to me to not have a rebranded email address that represents our company, and doesn’t disclose our cloud platform. Perhaps you could make it appear that the email is from a customer brand (don’t recall all the email on-behalf-of, etc., options) and make it appear that it is our email address and user logo. That would at least give us an easy way out and forget all the SMTP hassles.

Any insight on how to get our own no-reply working or enhanced default features you can provide would be greatly appreciated.

If you could setup a different website and setup SMTP credentials on that, we can see in our logs why it might be failing, or probably see what error we’re getting when trying to send emails from those credentials.

You could also try using a different SMTP in the mean time to see if it works to isolate this to maybe Google Workplace SMTP only?

I have set up a new site and created a completely new and non-aliased user. Please contact me on my direct email address for confidential information. Thanks.

Could you share the site name?

test-oauth-and-no-reply

Hi @VaughnVernon,

I checked that website, but sadly there’s nothing interesting in the logs. In the past, we got some text like:

error = "Error sending confirmation email: gomail: could not send email 1: 554 Transaction failed: Invalid domain name: '12313'."

OR

error = "Error sending invite email: gomail: could not send email 1: 554 Message rejected: Email address is not verified. The following identities failed the check in region US-EAST-1: email@domain.com"

That could help us troubleshoot. But i am not seeing that happening here.

Could you try to use the Netlify Identity Widget for the time being on this test website to see if that creates a difference (or at least show us some helpful logs like the ones above)? I don’t really think that should make a difference, but that’s the only area where I see your setup differs than the ones that showed such errors.

Thanks, Hrishikesh. It was late in the day Friday by the time this site was set up. We have not attempted any registration tests. You could register with some fake user and create logs yourself.

That’s what I’ve been doing and I’m not seeing any logs, which is something I wonder why.

I am seeing that the email failed to be sent (as that’s the error returned to the client-side), but there’s no separate error mentioning the cause.

Got it. The developer of these components has been alerted and should join in soon.

Hi @hrishikesh.
This the response from https://test-oauth-and-no-reply.netlify.app/.netlify/identity/signup

{
  "code": 500,
  "msg": "Error sending confirmation mail",
  "error_id": "01FMZ4SY30GECGJTM64CT7MR54"
}

The response don’t mention the error raison, just the error_id.

Yes, I’m aware of that and that’s the only line of information available in our logs as well.

I am just wondering why i’m not seeing any logs for the reason just like I saw them for other websites. These logs are not sent to the frontend and are visible only to us, but I’m simply unsure why there’s no trace of it.

This is why I wanted to eliminate the theory of this being related to Netlify Identity Widget vs GoTrue JS.

EDIT: Nevermind, I was able to find the error using the error id. This is the error I can see:

error = "Error sending confirmation email: dial tcp 64.233.181.27:587: i/o timeout"

I checked that IP and it belongs to Google:

So for some reason, the connection is failing.

I have changed the no-reply email configuration with a different approach to authentication, but it seems also not to work.

Please try again to check whether the error logs are improved.

Unfortunately, the error message remains the same.

Is it possible for you to try personal Gmail credentials so that we can try to filter the cause of the problem? As in, is it because Google Workspace SMTP is not allowing connections from Netlify, or anything of that sort. Additionally, if you could try a random third-party SMTP that doesn’t rely on Google, that could also help us narrow down the problem even more.

Thanks, Hrishikesh.

What you suggest is what I previously configured, which as of early yesterday (my time) didn’t work for your tests. Let’s call this Config1 since it is what Netlify recommends.

Then late yesterday I tried configuring with a different approach recommended by Google when your documented approach fails. We can call that Config2. That is what you also reported as failing in your most recent email that I am here replying to.

I have consistently used Config1 throughout the tests, except for the most recent attempt to use Config2. Unfortunately both have failed.

I must say that the documentation on both sides of this is quite murky. It’s like we need to put a Google Workspace Email engineer and a Netlify integration engineer together, not just to solve the problem, but also to explain what they did so that someone can commit the potion to writing.

I wonder why this is not already turnkey. I did find another Netlify Support forum post from a few months ago where someone else was trying to do the same thing and experiencing exactly the same problems. To my disappointment the post is inconclusive as to whether the other user was ever successful, and if so, how. Dennis, one of your Support Engineers, seems to have had the most knowledge:

https://answers.netlify.com/t/custom-sender-address-error-recovering-user/34032

The below discussions are not our use case, but might be related:

https://maximehardy.medium.com/keep-receiving-your-google-workspace-email-while-using-netlify-1fed1fa58480

https://medium.com/@jacobsowles/how-to-deploy-a-google-domains-site-to-netlify-c62793d8c95e

In other words, we are not hosting our production Netlify app domain on Google, and our test sites of course don’t host on Google. Our set up is as follows:

  • Production app domain name is hosted by Netlify
  • Email account is to the Google hosted domain name of the parent company, the app developers

If we can’t get our parent company email to work, perhaps we should not use the parent company domain email account, but use the app domain as the email account on a different email host. This seems to be better supported and works for others:

https://answers.netlify.com/t/support-guide-how-can-i-receive-emails-on-my-domain/178

That would be our last alternative as I’d sure prefer to get the parent company emails to work.

We’re trying to figure this out with you, and hopefully after we resolve this, we can work on what parts of documentation to improve.

From what I know, custom SMTP is currently working fine for a lot of users and this error text dial tcp 64.233.181.27:587: i/o timeout is not particularly helpful. It’s just saying that the connection to Google timed out.

This is why I said, try using a different SMTP provider temporarily - just to isolate the source of the problem. At the moment, we’re trying to guess the source of the problem - it could be Google, it could be us. Now we know the functionality is working for other websites, but I suppose the same SMTP credentials would be working for you elsewhere too. So, we’re back to the same question as to where the fault exists at the moment. This can only be solved by taking out one variable at a time and in this case that would be a different SMTP host.

If that works, you would also get some concrete information that might help in getting help regarding this from Google. If not, we can file a bug for our engineers to investigate.