emails fail with a 550 relay denied error if SMTP server is authenticate by IP WL

[HHVinChau]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.11.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

The root cause is that Python's smtplib defaults the EHLO/HELO greeting to the container's internal hostname or IP (e.g., something garbled with [172.18.0.8] from Docker's bridge network). Google's relay rejects this when:

• Using IP-based authentication (no username/password).
• The HELO doesn't present a valid/registered domain.
• Internal Docker IPs leak into the greeting.

Even when the public outbound IP is whitelisted in Google Workspace → Gmail → Routing → SMTP relay settings, the mismatched/internal HELO causes "Invalid credentials for relay".

Then, in the relevant SMTP code:

Python:

local_host = os.getenv("SMTP_LOCAL_HOSTNAME")
server = smtplib.SMTP(smtp_host, smtp_port, local_hostname=local_host if local_host else None)
This small change would make Dify much more compatible with strict SMTP relays (Google Workspace, Microsoft 365, etc.) in containerized environments.

Thanks for the great project!

container log:

2026-01-14 04:22:26.645 INFO [Dummy-23] [mail_change_mail_task.py:27]  - Start change email mail to recipient@domain.com
2026-01-14 04:22:28.070 ERROR [Dummy-23] [smtp.py:49]  - SMTP error occurred
Traceback (most recent call last):
  File "/app/api/libs/smtp.py", line 47, in send
    smtp.sendmail(self._from, mail["to"], msg.as_string())
  File "/usr/local/lib/python3.12/smtplib.py", line 876, in sendmail
    raise SMTPSenderRefused(code, resp, from_addr)
smtplib.SMTPSenderRefused: (550, b"5.7.0 Mail relay denied [63.xxx.xxx.130]. Invalid credentials for relay for\n5.7.0 one of the domains in: 0.8], 18.0.8], domain.com, [172.18.0.8] (as\n5.7.0 obtained from HELO and MAIL FROM).\n5.7.0  Email is being sent from a domain or IP address which isn't\n5.7.0 registered in your Workspace account. Please login to your Workspace\n5.7.0 account and verify that your sending device IP address has been\n5.7.0 registered within the Workspace SMTP Relay Settings. For more\n5.7.0 information, go to\n5.7.0  https://support.google.com/a/answer/6140680#maildenied 5a478bee46e88-2b170676e29sm2974537eec.2 - gsmtp", 'sender_dify@domain.com')
2026-01-14 04:22:28.070 ERROR [Dummy-23] [mail_change_mail_task.py:42]  - Send change email mail to recipient@domain.com failed

✔️ Expected Behavior

Users should be able to configure the SMTP client's local_hostname (passed to smtplib.SMTP(..., local_hostname=...)) via an environment variable in .env or docker-compose.yml. This lets us set a proper FQDN like mail.example.com or dify.example.com that matches our domain/registered in Workspace.

❌ Actual Behavior

No response

[dosubot]

Hi @HHVinChau! I'm Dosu and I’m helping the dify team.

The 550 relay denied error happens because Dify's SMTP client (in Docker) uses the container's internal hostname or IP for the HELO/EHLO greeting, which strict SMTP relays like Google Workspace reject unless it matches a registered domain—even if your public IP is whitelisted. Dify v1.11.2 does not currently let you set the local_hostname parameter for smtplib.SMTP via environment variable or config, so the HELO always leaks the Docker hostname/IP, causing relay failures see code.

To work around this, you can patch your Dify deployment:

1. Edit api/libs/smtp.py and, where smtplib.SMTP or smtplib.SMTP_SSL is instantiated, change:

   smtp = smtplib.SMTP(self.server, self.port, timeout=10)

   to:

   import os
   local_host = os.getenv("SMTP_LOCAL_HOSTNAME")
   smtp = smtplib.SMTP(self.server, self.port, local_hostname=local_host if local_host else None, timeout=10)

   Do the same for any smtplib.SMTP_SSL calls.

2. Set the environment variable SMTP_LOCAL_HOSTNAME in your .env or docker-compose.yml to a valid FQDN (e.g., mail.example.com) that matches your registered domain.

3. Rebuild/redeploy your Docker containers.

This will let you control the HELO/EHLO greeting and resolve the relay denied error with IP-authenticated SMTP relays.

References:

• Relevant code
• Related plugin discussion
• Contributing guide note

If you want this feature natively, consider upvoting or commenting on related issues to help prioritize it for future releases.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[HHVinChau]

I think this changes should natively support and release to public.

Hi @HHVinChau! I'm Dosu and I’m helping the dify team.

The 550 relay denied error happens because Dify's SMTP client (in Docker) uses the container's internal hostname or IP for the HELO/EHLO greeting, which strict SMTP relays like Google Workspace reject unless it matches a registered domain—even if your public IP is whitelisted. Dify v1.11.2 does not currently let you set the local_hostname parameter for smtplib.SMTP via environment variable or config, so the HELO always leaks the Docker hostname/IP, causing relay failures see code.

To work around this, you can patch your Dify deployment:

1. Edit api/libs/smtp.py and, where smtplib.SMTP or smtplib.SMTP_SSL is instantiated, change:
   smtp = smtplib.SMTP(self.server, self.port, timeout=10)

   to:
   import os
   local_host = os.getenv("SMTP_LOCAL_HOSTNAME")
   smtp = smtplib.SMTP(self.server, self.port, local_hostname=local_host if local_host else None, timeout=10)

   Do the same for any smtplib.SMTP_SSL calls.

2. Set the environment variable SMTP_LOCAL_HOSTNAME in your .env or docker-compose.yml to a valid FQDN (e.g., mail.example.com) that matches your registered domain.

3. Rebuild/redeploy your Docker containers.

This will let you control the HELO/EHLO greeting and resolve the relay denied error with IP-authenticated SMTP relays.

References:

• Relevant code
• Related plugin discussion
• Contributing guide note

If you want this feature natively, consider upvoting or commenting on related issues to help prioritize it for future releases.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

   

[fatelei]

I think this changes should natively support and release to public.

Hi @HHVinChau! I'm Dosu and I’m helping the dify team.
The 550 relay denied error happens because Dify's SMTP client (in Docker) uses the container's internal hostname or IP for the HELO/EHLO greeting, which strict SMTP relays like Google Workspace reject unless it matches a registered domain—even if your public IP is whitelisted. Dify v1.11.2 does not currently let you set the local_hostname parameter for smtplib.SMTP via environment variable or config, so the HELO always leaks the Docker hostname/IP, causing relay failures see code.
To work around this, you can patch your Dify deployment:

1. Edit api/libs/smtp.py and, where smtplib.SMTP or smtplib.SMTP_SSL is instantiated, change:
   smtp = smtplib.SMTP(self.server, self.port, timeout=10)
   to:
   import os
   local_host = os.getenv("SMTP_LOCAL_HOSTNAME")
   smtp = smtplib.SMTP(self.server, self.port, local_hostname=local_host if local_host else None, timeout=10)
   Do the same for any smtplib.SMTP_SSL calls.
2. Set the environment variable SMTP_LOCAL_HOSTNAME in your .env or docker-compose.yml to a valid FQDN (e.g., mail.example.com) that matches your registered domain.
3. Rebuild/redeploy your Docker containers.

This will let you control the HELO/EHLO greeting and resolve the relay denied error with IP-authenticated SMTP relays.
References:

• Relevant code
• Related plugin discussion
• Contributing guide note

If you want this feature natively, consider upvoting or commenting on related issues to help prioritize it for future releases.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
   

ok