ポート 465 については、RFC8314 を参照してください。
この RFC に基づくと、ポート 465 と 587 の両方が SMTP メッセージ送信エージェント (MSA) として有効なポートです。
ポート 465 は接続確立時に TLS/SSL のネゴシエーションを必要とし、ポート 587 は TLS のネゴシエーションを選択した場合に STARTTLS を使用します。
IANA 登録簿は、この目的のためにポート 465 の正当な使用を認めるように更新されました。
SMTP メール中継の場合、ポート 25 のみが使用されるため、STARTTLS がメール中継で TLS を行う唯一の方法となります。
@kyekiller さん、ポート 465 を使用する場合は、以下の設定を試すことをお勧めします（false に設定）：
DISCOURSE_SMTP_ENABLE_START_TLS: false
この行をコメントアウトしてもあまり効果はないでしょう。Discourse コンテナファイルから直接見ると、この設定のデフォルト値は true になっているため、この行をコメントアウトしても true に設定されたままになります。
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (オプション、デフォルトは true)
参考になれば幸いです。
RFC からの参照もご覧ください：
「submissions」サービス（デフォルトポート 465）のために TCP 接続が確立されると、TLS ハンドシェイクが直ちに開始されます。クライアントは [RFC7817] で説明されている証明書検証メカニズムを実装しなければなりません。TLS セッションが確立されると、残りの TCP 接続全体にわたって、メッセージ送信プロトコルデータ [RFC6409] が TLS アプリケーションデータとして交換されます。（注：「submissions」サービス名は、このドキュメントの セクション 7.3 で定義されており、Implicit TLS 上にレイヤリングされたサービス名の一般的な慣習に従っています。つまり、TLS なしで使用されるサービス名に「s」を付加した名前です。）ポート 465 の状況（セクション 7.3 で議論）により、ポート 587 上の STARTTLS メカニズムは比較的広く展開されています。これは、サーバー側で Implicit TLS が STARTTLS よりも広く展開されている IMAP および POP サービスとは異なります。一貫性のため、および 付録 A で議論されている追加の理由のため、MUA ソフトウェアが使用するコアプロトコルを時間とともに Implicit TLS へ移行することが望ましいです。ただし、送信における暗号化の利用を最大化するためには、数年間の移行期間中、メッセージ送信における TLS に対して両方のメカニズムをサポートすることが望ましいです。その結果、クライアントとサーバーは、この移行期間中、ポート 587 上の STARTTLS とポート 465 上の Implicit TLS の両方を実装すべきです。実装が正しく、クライアントとサーバーの両方がメッセージ送信前に TLS のネゴシエーションの成功を要求するように設定されている場合、ポート 587 上の STARTTLS とポート 465 上の Implicit TLS のセキュリティ特性に大きな違いはないことに注意してください。
注意点：Discourse のデフォルト設定には、TLS 関連のデフォルト設定が 2 つあります。
# smtp 認証メカニズム
smtp_authentication = plain
# smtp 接続の TLS 暗号化を有効にする
smtp_enable_start_tls = true
# smtp サーバー証明書の検証モード
# 無効にする場合は 'none' に設定
smtp_openssl_verify_mode =
# RFC 8314 3.3 に準拠して Implicit TLS を強制
smtp_force_tls = false
参照：