[bug]: SMTP not working even with correct configuration

[Sedation6612]

Is there an existing issue for this?

• [x] I have searched the existing issues

Current behavior

I'm self-hosting a plane instance on Proxmox. I've created the Plane instance using the script. I've used God-Mode to configure the SMTP, however, it keeps giving me a "Network connection error. Please check your internet connection.".

I've tried multiple different configurations using SSL/TLS, but nothing works. I did, yesterday, manage to get a single email to go though, using "https://" (either this or http) infront of the SMTP host, but I don't remember to well as it was a one time "fluke".

I do proxy this via Nginx Proxy Manager on a separate container, I have a few external facing sites. This is the only one that has an issue. I also tried using it via Cloudflared, but that didn't work.

My domain register is Cloudflare, the SSL cert is correctly assigned via my Nginx, and the website is not Cloudflare proxied. (that orange setting)

I've re-installed Plane 7ish times, all with different ways/configurations, I could not get SMTP to work.

Attached is an image of the web-inspector error once I get the network connection error.

As a side note, my mailbox is hosted by a smaller company, I haven't had an issue with them, but they selfhost their mail servers. (i don't think this will be an issue as I have other apps that send via SMTP without error)

Any tips would be greatly appreciated! Been working on this for like 4 hours, no avail.

Steps to reproduce

Simply configure SMTP.

Environment

Production

Browser

Google Chrome

Variant

Self-hosted

Version

vv1.9.2

[Sedation6612]

Update: I've attempted to use a different SMTP server/provider, still got the same errors. It might be a configuration issue, but at this point I'm not sure, I've done all the troubleshooting steps the documentation provides.

One of the reasons I think could be the issue is this: https://developers.plane.so/self-hosting/govern/reverse-proxy

I change the two ports as it request, add the SITE_ADDRESS field, but plane won't load after that.

[akshat5302]

Hi @Sedation6612,

The changes above are related to proxy configuration, in cases where ports 80 or 443 are already in use by another service.

For email-related configuration, please refer to the documentation. Also, make sure that the following SMTP ports are open on your server: 25, 465, and 587. Additionally, verify that your SMTP credentials have been entered correctly.

[Sedation6612]

Hello @akshat5302, thank you for the response!

I have plane installed on its own container, so no other ports are being used, verified and all.

I also did follow the documentation, but it was no help.

I port forwarded those 3 ports to the container as well, but still no resolution.

I have also verified the SMTP creds are correct, even used different creds from a separate provider, still nothing.

Is there anything I can provide you that will help me troubleshoot this?

[akshat5302]

Can you log into the worker container and run python manage.py test_email <receiver_email> to check why it's failing to send email.

[Sedation6612]

@akshat5302 Here's the screenshot, I had to reupload because I realized it had personal information.

There wasn't anything else outputted, let me know if you need anything else! Still can't get it to work.

[bonkboykz]

@Sedation6612 Don't know if it'll help, stumbled across this issue during a search, I was using railway template, which is based on makeplane/plane-backend docker image, and it turns out the godmod page was not using my configuration even for testing the email.

By looking at the source code https://github.com/makeplane/plane/blob/preview/apiserver/plane/license/utils/instance_value.py#L40 you need to:

1. either set up env variable SKIP_ENV_VAR=1, then set and save email configs using godmod, and try to test it out
2. or provide apiserver with env variables for smtp, which I did and it worked

EMAIL_HOST=
EMAIL_HOST_USER=
EMAIL_HOST_PASSWORD=
EMAIL_PORT="587"
EMAIL_USE_TLS="1"
EMAIL_USE_SSL="0"
EMAIL_FROM=

[Sedation6612]

@bonkboykz Thank you for the information! A bit confused on how I'd configure this, would I add those variables to the docker compose under the API service? Or am I missing something?

[bonkboykz]

@bonkboykz Thank you for the information! A bit confused on how I'd configure this, would I add those variables to the docker compose under the API service? Or am I missing something?

Are there any .env files or environment sections in your docker compose setup that you could add those variables to? If yes, then that's right you'd add them under the api service

[Sedation6612]

@bonkboykz Sorry, I did end up finding the .env file.

I did both methods as you said, but still didn't receive an email.

After some further investigation, it looks like all requests made to /api/ are being denied, which would explain why I can't send any emails (i think).

The issues might stem from the fact that I'm using Nginx Proxy Manager, and not Nginx via the CLI.

I attempted to translate what I could, but I'm not sure if it's correct.

This is what I've done, any insight?

[bonkboykz]

@bonkboykz Sorry, I did end up finding the .env file.

I did both methods as you said, but still didn't receive an email.

After some further investigation, it looks like all requests made to /api/ are being denied, which would explain why I can't send any emails (i think).

The issues might stem from the fact that I'm using Nginx Proxy Manager, and not Nginx via the CLI.

I attempted to translate what I could, but I'm not sure if it's correct.

This is what I've done, any insight?

No problem! Just to confirm, are you able to send the test email using manage.py right now?

[Sedation6612]

@bonkboykz Still getting the same error, connection refused.

I'm pretty sure its just a Nginx Proxy Manager configuration issue, there's zero documentation on it though so it's been an absolute pain trying to figure this all out.

[leandrogrupozani]

try change email security to: no email security

[Sedation6612]

@leandrogrupozani I tried that, but I'm confident its a reverse proxy issue, here's the output of the error when I try with no email security:

Unfortunately, it's the same as the other times I've tried with different SMTP configurations.

[CedricLindigkeit]

@leandrogrupozani I tried that, but I'm confident its a reverse proxy issue, here's the output of the error when I try with no email security:

Unfortunately, it's the same as the other times I've tried with different SMTP configurations.

I have the same smtp issues. I also tried my config with external smtp testers and they all worked.

[leandrogrupozani]

aaaah... now that I saw your error:

add this in apache on <VirtualHost *:443>

# API – redirecionamento correto
ProxyPass /api http://localhost:8000/api
ProxyPassReverse /api http://localhost:8000/api

#emailcheck
ProxyPass /auth/email-check http://localhost:8000/auth/email-check
ProxyPassReverse /auth/email-check http://localhost:8000/auth/email-check

ProxyPass /auth http://localhost:8000/auth
ProxyPassReverse /auth http://localhost:8000/auth

ProxyPass /api/instances/email-credentials-check  http://localhost:8000/api/instances/email-credentials-check 
ProxyPassReverse /api/instances/email-credentials-check  http://localhost:8000/api/instances/email-credentials-check 

#AUTH
ProxyPass /auth/get-csrf-token http://localhost:8000/auth/get-csrf-token
ProxyPassReverse /auth/get-csrf-token http://localhost:8000/auth/get-csrf-token/

# Admin
ProxyPass /god-mode http://localhost:4001/god-mode
ProxyPassReverse /god-mode http://localhost:4001/god-mode

# Spaces
ProxyPass /spaces http://localhost:4002/spaces
ProxyPassReverse /spaces http://localhost:4002/spaces

# Frontend – vem por último
ProxyPass / http://localhost:4000/
ProxyPassReverse / http://localhost:4000/

# Headers  
ProxyPreserveHost On
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Host "plane.yourdomain.com"
RequestHeader unset X-Forwarded-Host

Header always set X-Frame-Options "SAMEORIGIN"
Header always edit Set-Cookie "(?i)^((?!;\s?SameSite).*)$" "$1; HttpOnly; Secure; SameSite=Lax"
ProxyTimeout 300
Timeout 300

[Sedation6612]

@leandrogrupozani Sorry, where is apache located? Not sure what <VirtualHost *:443> is. Can't find apache on my system either.

But this does look like it will help! Those are all the URL's to the error's I've been receiving.

Is this posted on the documentation anywhere?

[leandrogrupozani]

It is located in /etc/apache2/sistes-availables/youplanename.conf

[Sedation6612]

@leandrogrupozani Apache isn't installed on my LXC, do you mean within the Docker container?

[leandrogrupozani]

@leandrogrupozani Apache isn't installed on my LXC, do you mean within the Docker container?

@Sedation6612 If you don’t have Apache, that’s totally fine. But Plane still needs some kind of reverse proxy (like Nginx, Caddy, or Apache) so users can access it in the browser using a domain (e.g., https://plane.yourdomain.com).

The plane.conf I mentioned is just an example config for Apache. If you’re using another web server (like Nginx), I can share an equivalent setup.

Without a reverse proxy, Plane will only be accessible via IP and port (like http://IP:3000), which isn’t ideal — especially for production.

Are you planning to use a domain, or just access it via IP and port?

[Sedation6612]

@leandrogrupozani I've installed plane with the default installation script, I'm pretty sure it does come with nginx, I see the compose file in the installation directory, so if you could instruct me how to configure this with Nginx, that would be amazing! This should also be added to the documentation as well, unsure as to why it's not, you've been a massive help!

And I am actively using a domain with Plane, not just an IP and a port.

[leandrogrupozani]

@Sedation6612 To expose Plane using a domain (like https://plane.yourdomain.com), you’ll need to:

Make sure ports 80 and 443 are open on your host machine.

Point your domain (e.g., plane.example.com) to your server's IP.

Edit the Nginx config. If you're using the Docker setup that comes with Plane, you’ll likely find the nginx.conf or related site config under something like docker/nginx/conf.d/.

Here’s a basic example you can adapt (if you're not using an existing one):

nginx Copiar Editar server { listen 80; server_name plane.yourdomain.com;

location / {
    proxy_pass http://web:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

} If you’re using HTTPS (which you should), you can set up a Let’s Encrypt cert using a tool like Caddy or nginx-proxy + docker-letsencrypt-nginx-proxy-companion.

[Sedation6612]

@leandrogrupozani Hold on a second, might have miscommunicated. I am using an external reverse proxy, Nginx Proxy Manager on a separate LXC.

Will configuring nginx that's installed on my plane LXC matter at all?

Additionally, where can I find /docker/nginx/conf.d/? I can't seem to find that directory anywhere.

Thanks!

[leandrogrupozani]

If you're using Nginx Proxy Manager (NPM) on a separate LXC, then you don't need to configure Nginx inside your Plane LXC at all — it won’t make any difference. The NPM setup is exactly what you need to expose Plane externally.

You just need to make sure:

Your Plane web container is exposing the correct port to the host (e.g., - "4000:3000" in docker-compose.yml).

In NPM, you create a proxy host pointing to http://YOUR_PLANE_LXC_IP:4000 (or whatever port is mapped).

(Optional but recommended) Enable SSL in NPM with Let's Encrypt.

About /docker/nginx/conf.d/: That path was just an example in case you were running your own Nginx inside the same LXC. But since you're using NPM externally, you can ignore that completely.

[Sedation6612]

@leandrogrupozani Still might be some confusion as well, I have the container already exposed, and everything (for the most part) works as intended, I can access Plane and all.

The issue is the SMTP doesn't want to work.

I thought the file you linked was going to correct the issue, as the errors I have been experiencing are bad requests to the API ports.

It seems that your configuration file changed http://api:8000 to http://localhost:8000, which (i think) would solve the issues, because my external reverse proxy (Nginx Proxy Manager) doesn't know what http://api:8000 is since it's not on the same docker network as plane.

Is there not a way to fix this?

[leandrogrupozani]

try save information first before test. change port .. any value.. then save. test. After error.. back to 587, salve and test again... works for me.

[Sedation6612]

@leandrogrupozani Huh, that's super odd, I played around with it and finally got it to work after saving incorrect configurations as you suggested, then applying others, thank you very much!

@CedricLindigkeit (pinging you for visibility since you had the same issue)

[Manethpak]

Having the same problem, I logged into the worker docker container and try python manage.py test_email <email> and receive this Error: Email could not be delivered due to timed out as a result.

[Sedation6612]

@Manethpak Hello! This does seem to be a bug, but the workaround solution is here: https://github.com/makeplane/plane/issues/7042#issuecomment-2902115327

For my detailed breakdown:

• Enter all of your correct SMTP credentials in god mode
• Save the credentials even though the test did not work
• From this point forward, you will only be fiddling with the “email security” option, so don’t change the port in conjunction with the protocol you want to use

Next, you’ll change the email security option to no authentication, then attempt to test. If it doesn’t work, more to SSL then test. If that doesn’t work, move to TLA then test.

Once you got a success prompt, save what you had and you are all set!

[Manethpak]

Hey @Sedation6612 , thank for the method. I've tried what you suggested and what other people suggested here as well but to no avail, I'm still getting the Timeout request.

Head up, I am on the self-hosted community edition. version 0.25.1.

[Sedation6612]

@Manethpak Ahh, very sorry then, I won't be much help, you might be better off making a separate bug since it seems it might be different from my original issue!