Hi all,
A while ago, I deployed my own Ghost blog, leveraging the DigitalOcean Marketplace 1-Click App deployment.
However, after some testing, I noticed that I’m unable to sign in to my own blog, although nothing special has been changed, as far as I can tell.
I currently have a session that is still signed in, and remains like that. But when I test signing in once more via a different browser or incognito window, this keeps failing.
At first this will endlessly keep spinning at this screen.
Then, later on, it will time out, with the following error message.
Trying to reset the password also fails, with this endless spinning wheel, and eventually gives another error message.
Has anyone experienced similar behavior with a similar setup and know what the exact issue is?
I’d love to properly maintain my blog and get this issue fixed, to avoid getting locked out. So any help is welcome. 
Thanks in advance!
This is /probably/ a problem with outbound email. There’s another thread from this week about the issue, but basically, DO tends to block outbound email (and may start blocking unpredictably, it seems), and getting logged in now requires an emailed token, unless you turn that function off.
Hi @Cathy_Sarisky, thanks for the input. So to have a proper understanding of this.
- This is a DO issue, rather than a Ghost configuration issue?
- To fix this, I need to reach out to their support to allow either SMTP or, ideally, SMTPS/STARTTLS, correct?
- A workaround, though not preferred and less secure, obviously, would be disabling this by adding the parameter as mentioned here, for example, disabling the 2FA authentication?
Thanks in advance for further elaborating on this.
The strange thing is, I’m not seeing anything of this in my logs, as per instructions in the documentation of Ghost. When intentionally logging in with wrong passwords, I do see the log getting populated. So I might have to look at a different log file?
Mmm, never mind, I do see the following when not filtering specifically on errors only.
[2026-03-07 16:33:14] WARN Missing mail.from config, falling back to a generated email address. Please update your config file and set a valid from address
[2026-03-07 16:33:14] WARN Missing mail.from config, falling back to a generated email address. Please update your config file and set a valid from address
I guess that’s the first step I’ll have to do. Configuring my SMTP settings.
Well, it could be both! :)
I think the latest log entries I added indicate it was an issue on my end still, or not necessarily?
However, I’ve added configuration now with Mailgun, as seen below, but it still complains in the logs that something is missing.
Any clue what I am possibly overlooking or need to do next? 
The from needs to be a direct child of mail - looks like you’ve got it under options?
And don’t forget to restart ghost after changes :)
Hah, okay, that explains a lot already, damn syntax I fixed that part now. However, upon clicking the forgot password button, it was still not sending anything. I presume it has something to do with the fact that DO is indeed blocking the classic SMTP ports, as seen here.
I changed the port to 2525, since Mailgun supports that as well, as stated here.
Unfortunately, I’m now bumping into the following error, hehe.
[2026-03-08 10:36:07] ERROR "POST /ghost/api/admin/authentication/password_reset/" 500 296ms
NAME: EmailError
CODE: ESOCKET
MESSAGE: Failed to send email. Reason: 0048634D277F0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:355:
I’m currently looking into this. But if you, or anyone else in general, has encountered this before and knows the cause and fix, please do not hesitate to let me know 
Many thanks in advance once more for the help so far.
Try either or both:
Remove service: mailgun since you aren’t on their standard port.
Try secure:false and starttls:true together in the options
1 Like
Nice, this issue has been resolved by removing the service explicitly.
I’m now getting password reset and 2FA mails. I can’t thank you enough for the help, I truly appreciate it. 
One last question: I think for the sake of security, enabling 2FA on every sign-on would be beneficial.
However, should I encounter any difficulties at a later phase with my email, I can still change this parameter to entirely lift the 2FA enforcement until I am able to fix my email settings, correct?
“security”: {
“staffDeviceVerification”: true => false
}
Once again, thanks for the help so far.
1 Like
Yes. But if your 2FA isn’t working, members can’t sign up either.
You mean that even with it being set to “false,” that part won’t work for just general members? Not my own user or other admins? However, it is, obviously, meant as a temporary fallback only, until everything is fixed. This way, I can maintain the highest security level without having the risk of being locked out entirely in case the mails are not properly getting sent.
So in essence, as long as it is a viable backup plan, that’s the main goal. Ideally, I hope I’ll never have to use it regardless.
Right - if your transactional email is broken, you won’t be able to send magic links either. But yes, staff users will be able to log in (but not password reset). I was just saying that you wouldn’t want to leave it in that way if memberships & sign-ups were important to you. :)
Oh yeah, no, no, I’m totally aware of that. If this were to occur, I’d get it fixed ASAP. It’s mainly, requiring 2FA for every single sign-on, regardless of whether it is a familiar device or not, greatly enhances security. However, if it were to break at some point, I at least have the certainty I can temporarily disable it with that one parameter in the JSON configuration to avoid entirely being locked out.
1 Like
