Hey,
Why does it take 30-60 minutes to receive email verification message on other emails than gmail? If I register user with gmail account the email comes straight a way, but if I use other email account than gmail it takes 30 to 60 minutes to get that verification message? Why is that?
I'm using sendEmailVerification() function to send that message after signup and after email is changed by the user.
There is also StackOverflow question on this topic from yesterday (not asked by me) but I figure here is better chance to get answer sooner.
StackOverflow question
Hey @eljass this is due to some issue with SendGrid service which Firebase Auth uses to send emails (password reset, email verification, etc). In case you are still experiencing these delays, please file an issue there: https://firebase.google.com/support/
UPDATE: We are working on fixing this issue and are actively migrating to another email sending solution. In the mean time please use the workaround below.
WORKAROUND: If you would like reliable email delivery today you will need to set up Firebase auth to use a custom SMTP server:

Your email sending should not face any issue anymore.
We apologize about this issue.
Thanks, it now seems to work as expected.
I’m dealing with the same problem past few days, email verification got delays for about 1 hour.
Yeah mine also take about an hour to receive. Is this temporary or always like this?
This is related to this issue which you can track here: https://status.firebase.google.com/incident/Authentication/17005
I am experiencing the delay in email delivery, even though the firebase status regarding this issue (https://status.firebase.google.com/incident/Authentication/17005) says it's okay right now.
Yes, same goes to me , it's not consistent. Sometimes the email delivered immediately, sometimes got some delay.
If anyone is still experiencing these delays, please file an issue there: https://firebase.google.com/support/
Firebase Auth team may need more information about the emails getting delays and the timestamps when the emails were sent.
Still happening to us. Have logged it with support.
This is a serious problem. It's the users first interaction with an app and can give the impression that there is a bug in the app and not continue to use it.
Sometimes the email arrives immediately and sometimes after 15-30 minutes.
Edit: I have contacted the Firebase team directly and sent them the full details of one of the emails that arrived with a delay and they are looking into it. This is a quote from the original response from the team:
Also, we are considering some other ways to send emails. One possibility is for Firebase to send emails through an SMTP server you may specify. Would you consider that or do you have other preferences?
Just want to put that out there for people to consider.
I completely understand how serious this issue is and how frustrating it can be. I have relayed this issue once again to the relevant parties. You will have a more direct line and a dedicated channel with the Firebase Auth backend team, reporting this through Firebase Support.
This issue is still there. Why we have closed this issue without any fixes?
I am experiencing the same issue, with or w/o gmail email address.
the issue is still active unfortunately (and blocker)
I am also suffering from this problem and it threatens the user-credibility of my app.
Is there an ETA on a fix yet?
I have also seen this problem this morning 12/4/2017. One confirmation email took over 45 minutes to send! This is serious issue and has already caused some headaches for my team as well as some of our users.
The link at: https://status.firebase.google.com/incident/Authentication/17005
Shows this has been resolved... it definitely has not. Filed issue with firebase support as well.
Would be nice if they uploaded a new status for this issue since it is definitely still a problem.
Seemed to work fine until a couple of weeks ago. Now so slow as to appear broken to users. Therefore it is of no value to me in its current state.
Any news @bojeil-google? The status is still apparently "Normal Operations" https://status.firebase.google.com/
This morning, 12/5/2017. I am not experiencing the delays anymore. Conf emails are coming across within 30 seconds of being sent. This one might be fixed but I'm not sure if I am 100% confident in saying that because the problem has seemed intermittent (at least for me).
It still happens from time to time, experienced it last week and now today. I've been waiting for 20 minutes for my confirmation email, still counting. This is a major issue, if the first contact of a lead is to wait 30-35 min to confirm his email it might mean losing him for good, plain wasted marketing effort.
Still experiencing the long delays here too. Late yesterday the delays were 45-60 minutes, this morning around 20-30 minutes.
Just had the same issue, emails took 2 hours to deliver. However, if I Request 3-4, I’ll get one right away. Isn’t there a way to do custom email? This failure is absolutely unacceptable and considering it’s a authentication issue, I would say that this should be a high priority.
Hey guys, anyone experiencing these delays should reach out to Firebase Support. This is the best channel to help resolve this issue: https://firebase.google.com/support/
You will need to provide samples of email addresses affected, the average delay time and the timestamp the emails were sent.
@bojeil-google Unfortunately, most of us have already done that and are not having any luck that way. This is a public collection of people with this issue.
Has there been any progress? The status board still says there's no issue, and we get no updates, so it really seems like it isn't being taken nearly seriously enough.
I have the same issue. Causing us to need to switch to phone auth. Any updates on fixing this?
If this issue can't be reliably fixed, can each verification link sent to the user remain valid?
I have a button for "Resend Confirmation". If a user taps that, and emails are delayed, then when the first arrives, it is unusable (invalid OOB code).
So the user has to keep waiting for the last email to arrive.
This is really hurting the experience at a critical moment in the a user lifecycle.
People on this thread - Are you noticing any differences when using the same test account repeatedly, vs new accounts?
I'm having this problem too. It is intermittent but occurs often.
We are facing the issue with delayed verification e-mails too. This is a critical defect for us! Sometimes e-mail arrives instantly but very often there are huge delays (20-50min).
We have the same problem, it takes about 15-60 minutes until the mail arrives. It is working fine with gmail accounts.
Next week is my fyp presentation, i really hope this problem can be resolve. Otherwise i cannot show the verification part of my application. I really need a backup plan for this. Sobs
I am having the same issue. Verification emails are taking 30 - 75 minutes!! This is a massive failure on the part of Firebase. Any solutions that actually work? As is, this is a show stopper and we will have to migrate away from Google/Firebase.
It takes some effort but you can move to Phone Auth and do the same process via txt message. We are planning to implement that. I really wish they would fix this.
@everyone We just launched custom SMTP server setup in the console ("Authentication > Templates > SMTP settings"). You should try checking it out if you've been having email delivery issues!

@kmcnellis some quick testing shows this to be more reliable!! thanks!
FWIW, I'm using mailjet and had trouble with TLS on port 587, so am using port 465 per their recommendation.
I might also mention that some of the console stuff is a bit confusing around this - I'm not sure how the "custom domains for email templates" impacts the SMTP settings, which supersedes, etc.
@kmcnellis Thanks for letting us know about this. Whilst it is great to have this as an option for those who need/want the customisation, it seems a real pity that we would _have to_ use our own servers (or another service) when a lot of the reason why we're using Firebase is to avoid that.
Also, the fact that we might be successful using another mail delivery service whereas Firebase are not is a little odd and disconcerting.
I hope that this is therefore not seen as "the answer" to the problem when surely that should be your developers actually fixing the problem.
@sbauch question about I'm not sure how the "custom domains for email templates" impacts the SMTP settings, which supersedes, etc. is also very important before any of us can seriously consider using our own SMTP server in production.
Completely agree with Simon Burbage.
I chose Firebase because it had a comprehensive set of back-end services in
one place. I don't have another mail server option in mind and want to use
Firebase for this purpose.
Can we please have a "proper fix". If all that is needed is a working mail
service it seems odd that this is taking so long.
Thanks
Adam
On 10 Jan 2018 03:11, "Simon Burbidge" notifications@github.com wrote:
@kmcnellis https://github.com/kmcnellis Thanks for letting us know
about this. Whilst it is great to have this as an option for those who
need/want the customisation, it seems a real pity that we would have to
use our own servers (or another service) when a lot of the reason why we're
using Firebase is to avoid that.
Also, the fact that we might be successful using another mail delivery
service whereas Firebase are not is a little odd and disconcerting.
I hope this is therefore not seen as "the answer" to the problem when
surely that should be your developers actually fixing the problem.@sbauch https://github.com/sbauch question about I'm not sure how the
"custom domains for email templates" impacts the SMTP settings, which
supersedes, etc. is also very important before any of us can seriously
consider using our own SMTP server in production.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebaseui-web/issues/234#issuecomment-356487130,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AfvVQyTCnd56pMCW9enPfEHDMa1CGSCxks5tJCpLgaJpZM4QKS-a
.
I agree with @siburb. The service should work in the first place - having the option should be something that we shouldn't use to circumvent issues...
Thanks for adding the option to the configuration, but can we also have a test email option with debug information on this screen?
I'm using sparkpost and for some reason when I configure the smtp - I don't get any emails and I don't get any trace of a mail in sparkpost's dashboard.
When I use the sparkpost API in the cloud functions everything is fine. So right now I'm clueless as to why the smtp is not working.
Is there anything the community can do to help with this issue? I'm using SMTP for now, but I'd like to someday move over to letting Firebase manage these emails.
@kmcnellis In addition to this, I'm looking for documentation on how to switch to using custom SMTP. I've configured the SMTP panel, is there anything else I need to update in my code? I'm using the [Web version] sendEmailVerification method, and monitoring logs from the Mandrill side but there are no records in their API logs. The emails are no longer being sent at all- despite the sendEmailVerification returning a 200.
Nevertheless, I think adding this option is a step forward. We had case of
30-60min delays for messages in the sign-up process, I'm glad that at least
now we can see what it's happening with the delivery.
Still, I don't quite get how to set a proper Sender name while using our
SMTP, having sign-up emails coming from someone called "office" or
"contact" is quite annoying :) Does anyone have any hints on this?
Thanks!
On Fri, Jan 12, 2018 at 1:38 AM, Jj Medina notifications@github.com wrote:
Is there anything the community can do to help with this issue? I'm using
SMTP for now, but I'd like to someday move over to letting Firebase manage
these emails.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebaseui-web/issues/234#issuecomment-357097259,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOSiDJ8V1F9CebhEUKlchlNNYFHYC80ks5tJpt-gaJpZM4QKS-a
.
@jjPlusPlus You should first do a check on your SMTP config. You can use Telnet or any online tool (e.g. https://www.smtper.net/) to test it.
When you do, set the sender address to a real inbox, so that you can receive any bounce emails.
I also ran into this problem. Using my gmail ID for now to send out the email since I am still in development phase. I would really like to see this fixed. I wouldn't mind paying the standard rate per email because I don't want to maintain my own SMTP server or a separate service.
This is an absolute blockbuster problem.
Firebase is now simply a non-starter, due to this.
We implement startups for clients in the $1m - $2m range.
The two current early stage projects in the pipe, we are now changing away from Firebase.
It's that simple unfortunately. Firebase is now a non-starter.
However it's very important to note that, FIREBASE MAKE IT TRIVIAL TO CHANGE TO USING ANOTHER EMAIL SERVER for sending email ...........
I only learned this myself after talking with the helpful FB crew, well, after complaining bitterly to the helpful FB crew....
it takes 30 seconds to change to your own mail server ... totally easy
Just wanted to hop in here and say I'm also experiencing a long delay in receiving the password reset email.
We just released our application on Play Store, we had several interviews about it and we receive a huge amount of user trying to make your first login but they aren't receiving the confirmation email. There's a lot of 1 star ratings because that. It's very frustrating, we spend a lot of time development the best app possible to get very bad rating because the firebase can not send emails with an acceptable time...
I don't recommend Firebase.
Hey @ceac13 and @Gillinghammer - like you we found this to be a breaker,
in fact as I mention above we were moving a client away because of this,
however - I did not realize it's actually trivial to just _change the email server used_, to send the email -
like, I literally used at first for a test just my own ordinary email server, i.e. I opened settings on my iphone and copied the name of the server and my passwd!!

Of course, you can get a $2 account from sendgrid, godaddy or whatever to send email instantly.
At first I was absolutely furious with Firebase that they can't send email
Then I was over the moon kissing ass since it is so easy to change email servers
Then again I was really furious, because, people have been complaining about this for a year, surely, Firebase should have more clearly yelled out "oh just press the button to change email server!"
Heh!
Important - we verified very carefully, that, the part "done by Firebase" is blazing, it happens instantly. If you use say a sendgrid account, you can clearly watch the email request arriving at sendgrid, as I say instantly (thanks Firebase), and then the only delay is the usual few seconds or whatever that your email server takes. If there was a delay in FBase's system, before, requesting the email, we'd all be screwed. But no, it's instant.
There is still no explanation for why Google have not fixed this yet. (The
email server thing is a workaround not a fix. And it isn't even a viable
workaround for everyone.)
On 7 Feb 2018 18:14, "SMHK" notifications@github.com wrote:
Hey @ceac13 https://github.com/ceac13 and @Gillinghammer
https://github.com/gillinghammer - like you we found this to be a
breaker,in fact as I mention above we were moving a client away because of this,
however - I did not realize it's actually trivial to just change the email
server used, to send the email -like, I literally used at first for a test just my own ordinary email
server, i.e. I opened settings on my iphone and copied the name of the
server and my passwd!![image: screenshot]
https://user-images.githubusercontent.com/3938526/35933396-270d2894-0c00-11e8-82b7-b6c7de36a685.pngOf course, you can get a $2 account from sendgrid, godaddy or whatever to
send email instantly.1.
At first I was absolutely furious with Firebase that they can't send
2.Then I was over the moon kissing ass since it is so easy to change
email servers
3.Then again I was really furious, because, people have been complaining
about this for a year, surely, Firebase should have more clearly
yelled out "oh just press the button to change email server!"Heh!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebaseui-web/issues/234#issuecomment-363860021,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AfvVQ0Hp9itXrcpabuJq_vQrb2d4pH-Kks5tSegVgaJpZM4QKS-a
.
Firebase Auth has always valued its developers and aimed to provide the best service to them. Once again, we apologize if you have encountered delays in our email delivery. The issue has always been due to some change in a third party email service provider which Firebase Auth used for email delivery, a service which we have no control over. Since then, we have been actively working on migrating to a new service which requires a lot of time and effort to complete.
We really appreciate your understanding and patience on this issue.
I'm still experiencing the problem and sometimes when I clicked the given link, it throws the following error below:
first byte timeout
Details: cache-hnd18734-HND 1518072219 3756878893
Varnish cache server
that would seem to be a different unrelated problem, @jeffminsungkim. maybe start a new issue?
@smhk Ok, I'll open the above issue.
I'm developing a new project and I decided to use Firebase as a backend service, but this issue is a big big big problem and I'm not sure anymore of my choice...Is Firebase a professional service? I saw a lot of people in different international conventions, speaking about and presenting Firebase, but... I suspect that this isn't a production ready service. Must I pay 25$/month for a such service? 4 months since this important issue was opened and no real solution to this at the moment. People here, are asking to open an issue to support....please man, hundred of people are facing this problem, what informations do you need about this issue again??? HEY Google, what are you doing???
@nandowalter see @bojeil-google 's response just a few comments above; along with what I imagine is hundreds of other developers, I submitted a support ticket simply because the more requests we pile on the more the fire will be lit underneath them to ship a fix.
For now, it really, truthfully, pitifully, annoyingly, disgustingly, shamefully sucks- it just really _really_ sucks- but we all have to maintain our own SMTP servers to handle these emails, or switch away from Firebase.
@jjPlusPlus thank you, but I cannot think that migrate to another provider could take more than 3 months...maybe is there a problem on architecture? Is Firebase system hard coupled to the service provider? My company will fire me if such things happens... Someone has to explain me because Firebase, a company of Google, the world famous company having the world leading email service GMail, needs to send email with an external provider...I cannot understand this 3 months issue...sorry.
Hey all, If you are looking for a free email sending option I recommend you use Mailgun. It comes with 30,000 free emails per month if you signup through Mailgun's Google Cloud Platform partner page: https://www.mailgun.com/google which you all are entitled to since you are using Firebase (instead of 10,000 free emails/month for a regular signup). You should be able to setup the Firebase authentication SMTP with your Mailgun account.
I know it's extra setup and it's all quite annoying to you. Again we apologize about the delays fixing this issue.
By the way setting up your own SMTP account has actually some nice added value. Typically professional-grade Email Sending Platforms will allow you to track the delivery of your email and also enable Open and Click tracking. You'll also get reports in case of user-complaints (if your users mark your emails as Spam for instance). This should give you a better understanding and overview of what is happening with these emails.
PS: Please do not take this message as a way to understate the importance of this issue, we know this is bad and we're working on fixing it.
@nicolasgarnier purely FYI ..
"I know it's extra setup ...."
Just so everyone knows, to change to mailgun you
Believe me, nobody was more furious at Firebase than me about this issue, and I still am.
But honestly it is "one click" to enter your own email server.
(For example: at first I literally just used my personal email server!!!!!!!! ie, I opened "settings" on my iphone, and in Firebase I typed something like "pxh34.godaddy.com" and a password. That's it.)
Hope it helps someone!
BTW the mail-sending services are incredible (and free unless you send millions)
They all have reports like THIS:

I literally assigned a staff member to bitterly complain to Google about this issue :) But even when Goog fixes it, we'll just use sendgrid or whatever now. Hope it helps someone! :O
Thanks @smhk I do agree that they are very very nice.
I've updated the initial response from @bojeil-google to highlight the current workaround.
My main concern with setting up a custom SMTP server rather than just using the existing solution was that it makes no sense that we should have any more luck at routing the emails than Firebase does. Surely if the new custom SMTP feature works properly, then Firebase Auth could just use that same feature for everyone and route the mail through their own account on whatever service we're now being told to use - switching everyone from Sendgrid (or whatever the previous service was using) to Mailgun would have only taken minutes.
Having said that, I have now setup SMTP via Mailgun and it is all working perfectly. It did only take a few minutes to implement and test the system on our dev environment before I was comfortable that it was a big improvement on the old system.
I think it was a pity that we had to go around the houses to get there - it still feels a little like the existing system broke conveniently so that we'd all have to abandon it - _but_ I do think we have a far better system now, with far more visibility and control over our email routing.
_"...that it makes no sense that we should have any more luck at routing the emails than Firebase does.."_
Hey @siburb - I had exactly the same concern.
(I screamed filthy obscenities at a Firebase dude, and then a supervisor, on the phone, for literally 10+ minutes over this - I timed it.)
I found an expert in a current client's organization (a guy who sends a huge amount of email for a living) and got the specific, actual, explanation:
It's simple, using FBase's built in system _everyone's email is sent from the same mail service_.
Again, if you think about it logically _everyone's email is sent from the same mail service_ - it's that simple.
And given modern mail systems (anti-spam, etc) it is absolutely impossible that mail will be routed quickly in that situation - it's impossible.
I've actually thought about this a lot and my final feeling is:
_It's actually really silly that Firebase even offers the quick-test, "every client together", email sending!!_
They should take away the option.
When it comes to that part in the setup, it should just say:
"type your mail server and password here"
and this issue would never have come up.
Another way to look at it ......
the FBase dudes on here are currently saying "oh we're trying to fix the problem." _That is literally not possible._
The way modern email-spam systems work, you simply can not send mass email from sundry varied contexts, from the one account, without incurring 1-2 hour delays.
The only way they could "fix" it (and this would be bizarre/dumb/pointless - I just say it for clarity) is this: where it comes to that setup screen, it could say "click here, and we will automatically create a free account for you on (pick a service from a list) and we will populate the two following fields for you ("name and password") - to avoid you having to type in your name and password!"
I honestly think they should just remove the option to use their "testing" one, and just have people type in the name/pass of an email server.
The simplest possible quickfix:
on that screen they should just add some text: "Enter your mail server / pass. If you wish, feel free to use our testing account (email delivery takes about an hour in the testing account)."
If they had simply added that _line of text_, none of this would ever have come up - at all!
@bojeil-google @smhk
SMTP works, but email gets to spam despite the fact firebase verified custom domain for emails.
Anyone faced spam issue?
If you are using the custom SMTP server, make sure the "from" email in the console matches the email your smtp server is setup with.
Seeing the same issue again, with Zelle. Moreover, once the mails finally get delivered, they are timestamped "30 minutes ago".
Have never seen anything like this before, and it's oh not so cool. If you are (hopefully) considering changing e-mail codes sending provider, and need a witness to prove your current contract should be terminated early without any penalties (actually, _they_ should pay _you_ for such a terrible service), don't hesitate to reach out).
Thanks,
Dima
@Stas-Buzunko if you are facing spam issues make sure you have correctly went through the steps provided by your ESP when you configured your domain name with them.
This typically means that you have added a bunch of MX and TXT records in the DNS settings of your domain. These DNS settings basically indicate that the ESP is a legitimate sender for the emails of your domain (you can search about DKIM and SPF checks on google) and without them your emails are likely to go to spam.
Other reasons could be that your domain already has a bad sender reputation, for instance if you have already sent a lot of spammy emails (unwanted promotional emails for instance) and users marked your emails as spam manually. In that case I would advise to create a separate subdomain for sending only these (aka don't send promotional and transactional emails with the same domain)
It seems like the email sending delays have been fixed now. Closing this.
I am still experiencing these Issues.
@nicolasgarnier Please re-open this issue; the problem has returned and I've lost days trying to develop through it. Was speaking with a Firebase DevRel, thinking I'd set things up incorrectly, and they were totally unfamiliar with this being a known issue, leading us on a wild goose chase; so the support team also needs informing about this.
I was testing email verification briefly around 23:00 and received emails with timestamps between 23:54 and 07:52 the next day:

That is to say, the emails took up to nine hours to deliver, and were spread apart by several hours despite having been requested minutes apart from each other.
Also as noted by @dkorolev, the time of receipt is actually long after the times indicated by these timestamps:
Moreover, once the mails finally get delivered, they are timestamped "30 minutes ago".
This is a critical issue for user adoption that reflects badly on app developers, leading to bad reviews and frustrated customers. It has been over three years since discovering this issue and yet it still resurges.
The issue has always been due to some change in a third party email service provider which Firebase Auth used for email delivery, a service which we have no control over.
@bojeil-google If the Firebase team are going to defer blame to their choice of third-party email service provider, why haven't they in these three years at least set up regression tests to react quickly to reoccurrences of this bug? Why isn't it acknowledged as a potential problem in the documentation to save use losing days of dev time?
Developers shouldn't always be the first to discover this, and we shouldn't have to compensate for Firebase's email services, with it being advertised as the best-in-class, all-in-one, quick-start scaleable backend.
EDIT: moreover, even when changing to my own SMTP server, these emails aren't arriving on time (maybe not at all; hard to tell right now without waiting a few more hours).
The original problem was fixed, and the email provider moved to the new system.
If you are experiencing issues now, it’s a new issue. Could you email support (firebase.google.com/support) with the details?
Thanks @kmcnellis, I have reported this now; case 00045312.
Me too, 00045323
Same here. Case #: 00046555
Hi !
I'm getting a VS-Score of 49
Which is way above the 10 score that is restricted on many mail servers
X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelgdejgecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr
tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomh
grihhnucdlgeelmdenucfjughrpeggkfffuffhvfgtsegrtderredttdejnecuhfhrohhm
peihohhurhhfrhhivghnughsseifvghlohhvvgguvghvshdrtghomhenucffohhmrghinh
epfhhirhgvsggrshgvrghpphdrtghomhdpfigvlhhovhgvuggvvhhsrdgtohhmnecukfhp
pedvtdelrdekhedrudeiiedrjedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg
hmpehinhgvthepvddtledrkeehrdduieeirdejtddphhgvlhhopehmrghilhdqihhouddq
fhejtddrghhoohhglhgvrdgtohhmpdhmrghilhhfrhhomhepoeihohhurhhfrhhivghnug
hsseifvghlohhvvgguvghvshdrtghomhequcfukfgkgfepfeehleeh
X-ME-VSScore: 49
X-ME-VSCategory: clean
Locking this discussion as this issue tracker is for requests related to Firebase UI Web; request here is a bug report for Firebase Authentication server infra and unrelated.
Most helpful comment
Completely agree with Simon Burbage.
I chose Firebase because it had a comprehensive set of back-end services in
one place. I don't have another mail server option in mind and want to use
Firebase for this purpose.
Can we please have a "proper fix". If all that is needed is a working mail
service it seems odd that this is taking so long.
Thanks
Adam
On 10 Jan 2018 03:11, "Simon Burbidge" notifications@github.com wrote: