Dify OSS版で eo光 SMTP を利用する手順書(設定・確認・トラブル対策)
本書は Dify OSS版(Docker Compose) で eo光 SMTP を使ってメール送信(招待/パスワードリセット等)を行うための設定手順、確認手段、トラブル対策をまとめたものです。
作成日:2026/02/14
1. 前提・推奨パラメータ(eo光)
- SMTPサーバ:
smtps.eonet.ne.jp - ポート:
465 - 暗号化:SSL/TLS(SMTPS)
- 認証:必須(ユーザー名=メールアドレス、パスワード=メールパスワード)
2. .env 設定(eo光向け:465/SSL)
Difyの ~/dify/docker/.env(環境によりパスは異なる)に以下を設定します。
重要:
MAIL_DEFAULT_SEND_FROMとSMTP_USERNAMEは同じメールアドレスに揃えるのが安全です。
MAIL_TYPE=smtp
# 送信元(eo光のメールアドレスに揃える)
MAIL_DEFAULT_SEND_FROM=yourname@xxxx.eonet.ne.jp
# eo光SMTP(465/SSL)
SMTP_SERVER=smtps.eonet.ne.jp
SMTP_PORT=465
# 認証(ユーザー名はメールアドレス完全形)
SMTP_USERNAME=yourname@xxxx.eonet.ne.jp
SMTP_PASSWORD=YOUR_MAIL_PASSWORD
# 465(SSL/TLS)の場合
SMTP_USE_TLS=true
SMTP_OPPORTUNISTIC_TLS=false
# HELO/EHLO対策(ドットを含むFQDN風が安全)
SMTP_LOCAL_HOSTNAME=dify.localdomain
3. 招待メールURLを http://localhost/... にしたい場合
招待メールのリンクを http://localhost/activate?... の形式にしたい場合は、.env に CONSOLE_WEB_URL を設定します。
CONSOLE_WEB_URL=http://localhost
# ブラウザが http://localhost:8080 なら以下
# CONSOLE_WEB_URL=http://localhost:8080
注意:他ユーザーを招待する場合、相手にとって
localhostは相手PCを指すためリンクが開けません。
その場合はhttp://<DifyサーバのIPまたはFQDN>にしてください。
4. 反映手順(必須)
.env を編集したら、必ずコンテナを再起動します。
cd ~/dify/docker
docker compose down
docker compose up -d
反映された環境変数を確認します(worker側が重要)。
docker compose exec worker sh -lc "printenv | egrep 'MAIL_|SMTP_|CONSOLE_WEB_URL'"
5. 確認手順(推奨の順番)
5.1 SMTP 465/TLS 接続確認(ネットワーク到達性)
workerコンテナから SMTP に接続できるか確認します。
docker compose exec worker sh -lc "openssl s_client -connect smtps.eonet.ne.jp:465 -brief </dev/null"
期待される出力(例):
CONNECTION ESTABLISHED220 ... ESMTP
これが成功すれば「ネットワーク/465/TLS」は概ねOKです。
5.2 Difyの送信処理ログ確認(workerログが主)
招待メール送信やパスワードリセット送信を試し、workerログを監視します。
docker compose logs -f worker
補助的にAPIログも見ます。
docker compose logs -f api
6. トラブル対策(症状別)
A) 535 5.7.8 Authentication failed(認証失敗)
原因(多い順)
-
SMTP_USERNAMEがメールアドレスではない(ID文字列等) -
SMTP_PASSWORDが「eo光メールのメールパスワード」ではない(会員ログインPW等)
対策
-
SMTP_USERNAME=yourname@xxxx.eonet.ne.jp(メールアドレス完全形)にする - パスワードをメール用パスワードに戻す
-
MAIL_DEFAULT_SEND_FROMとSMTP_USERNAMEを一致させる
B) 501 Bad HELO hostname syntax(HELO/EHLO ホスト名不正)
原因
- Dockerのコンテナ名/ホスト名が SMTP サーバ側で不正扱いされる(例:形式が不適切)
対策(推奨)
-
.envのSMTP_LOCAL_HOSTNAMEに ドットを含む値を設定SMTP_LOCAL_HOSTNAME=dify.localdomain
それでも改善しない場合(確実策)
-
docker-compose.ymlにhostnameを明示(英数字・ハイフン・ドット推奨)services: worker: hostname: dify-worker.localdomain api: hostname: dify-api.localdomain - 変更後に
docker compose down && docker compose up -d
C) Network is unreachable / Connection timed out(到達不能)
原因例
- FW/プロキシ/社内ネットワーク制限
- Dockerネットワーク異常
- 外向き 465 がブロック
確認
- まず
openssl s_client(5.1)で成功するか確認
対策例
- 社内/クラウドFWで
tcp/465を許可 - Dockerネットワーク再生成(必要時)
docker compose down docker network prune -f docker compose up -d
D) 招待メールのリンクが /activate?... のように相対パスになる
原因
-
CONSOLE_WEB_URLが未設定/不正/反映されていない
対策
-
.envに設定(例:localhost)CONSOLE_WEB_URL=http://localhost - 再起動後、
printenvで反映確認(4章)
7. 運用のコツ(ミスを減らす)
-
MAIL_DEFAULT_SEND_FROMとSMTP_USERNAMEは同じメールアドレスに揃える -
.env更新後は必ずdocker compose down && docker compose up -d - 送信系トラブルは まず workerログ(
docker compose logs -f worker)を見る
8. 付録:確認コマンド一覧
# 反映確認(環境変数)
docker compose exec worker sh -lc "printenv | egrep 'MAIL_|SMTP_|CONSOLE_WEB_URL'"
# SMTP接続確認(465/SSL)
docker compose exec worker sh -lc "openssl s_client -connect smtps.eonet.ne.jp:465 -brief </dev/null"
# ログ監視(メール送信は worker が主)
docker compose logs -f worker
docker compose logs -f api