Delay between user registration and sending of code via email
We use Zitadel Cloud (PRO). We allow user registration via email and password. For most users, this works fine: they enter their info, receive a validation code in their email within 30 seconds, then enter the code and continue to our web application.
But for some chunk of users, the email takes at least 5 or more minutes to arrive in their inboxes.
I thought maybe this was a deliverability issue, but two pieces of evidence indicate that it might be on Zitadel's end:
1. Our SMTP provider shows timestamps for when an email was queued in its system and when the recipient opened it. Even for users who encountered a delay, those two timestamps were still in the same minute.
2. In Zitadel, for users that encountered a delay, I see a difference in the "Last Changes" section of that user's page. e.g.,
Initialization code sent 16:23 Initialization code generated 16:18 Person registered themself 16:18Any guidance?
13 Replies
Hi @Joshua, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.
Answer
I wasn't able to find a direct answer to the delay between code generation and code sending in the available sources.
However, there is a related open GitHub issue that describes email verification behavior that might be relevant to your situation (1) . The issue discusses scenarios where users created via API with unverified emails experience different flows depending on whether they click the verification link or try to log in directly .
For SMTP configuration testing and troubleshooting, ZITADEL provides a test endpoint that allows you to verify your SMTP provider setup (2) . You can test your SMTP configuration by providing parameters including
senderAddress, senderName, host, user, password, and receiverAddress .
Since you're experiencing a consistent 5-minute delay between code generation (16:18) and code sending (16:23) for some users, and your SMTP provider confirms near-instant delivery once received, this suggests the delay occurs within ZITADEL before the email is handed off to your SMTP provider.
For your specific Cloud PRO instance issue with systematic delays, I'd recommend clicking the "Ask for help" button to tag a team member who can investigate your instance's email sending patterns and any potential queuing or rate-limiting behavior.
Would you like a general answer about potential causes of email delays in authentication systems?
ā
To learn more, see the sources I considered:
[1] [Bug]: Email verification code not working if user tries to login directly
[2] Test SMTP Email Provider
ā
Feel free to tag @Ask Inkeep with additional questions.
Got it. Tagging @Rajat for additional help.Hi @Rajat I'm also experiencing this issue. Could you help debug this?
hey @Andre welcome to the server, I will take a look at it.
Thanks Rajat!
hey @Andre I have raised it internally, I should get back annswer from the team tomorrow. Thank you
Hi @Rajat , have you heard back from the team about this issue? Thanks!
Hi @Rajat, we use Postmark SMTP. Will create an issue shortly. Could you also let us know if you hear back from the team? thanks!
@Rajat created an issue here! https://github.com/zitadel/zitadel/issues/11041
GitHub
[Bug]: Delayed Emails Ā· Issue #11041 Ā· zitadel/zitadel
Preflight Checklist I could not find a solution in the documentation, the existing issues or discussions I have joined the ZITADEL chat Environment ZITADEL Cloud Version No response Database None D...
@Rajat To clarify, it works pretty instantly with postmark 95% of the time. It's with a select subset of users that there's a delay ā mostly users at academic institutions. Evidence suggests it's an issue on Zitadel's end given the timestamps, but hard to be 100% sure. (More details in the GitHub issue I posted above!)
I have updated the issue with this comment, it will be helpful for the devs to make an estimate the impact š of the bug
hey @Joshua are these delayed emails always for specific set of users?. Have you tried deleting their emails and adding them and trying again?.
you can share one of the email to mer privately. I can test it against my SMTP and see if I get an OTP