SMTP-AUTHとは？ 10分でわかりやすく解説

SMTP-AUTHは、メールを送るときに「その人が本当に送ってよい利用者か」を確かめるための認証です。スパム送信やオープンリレーの悪用を防ぐため、だれでも送れる状態を避ける必要があります。SMTP-AUTHを入れると、許可した利用者だけがメールを送れるようになります。

ただし、SMTP-AUTHは送る人やアカウントを確かめるものであり、受信側でなりすましを見分ける SPF、DKIM、DMARC とは受け持ちが違います。この記事では、SMTP-AUTHのやり取り、よく使う認証の型、サーバーとクライアントで見る点、入れるときの注意を見ます。

SMTP-AUTHとは何か

SMTP-AUTHとは、SMTP（Simple Mail Transfer Protocol）に追加された認証の機能です。SMTPはもともと、メールを転送することを主な目的に作られました。そのため、初期の設計では送信者を厳しく確かめる作りではありませんでした。SMTP-AUTHは、その弱い所を補うために使われます。

SMTP-AUTHの定義

SMTP-AUTHは、メールを送るときにクライアントがSMTPサーバーへ認証に使う情報を出し、サーバーが利用者を確かめた後で送信を許可するものです。多くの場合、Outlook や Thunderbird などのメールソフト、または送信アプリが、ユーザー名とパスワードなどで認証します。

ここで大事なのは、SMTP-AUTHが主に「利用者がメールを送る入口」で使われる点です。多くの環境では、利用者の送信は 587 番ポートで受け、サーバー間の転送で使う 25 番ポートとは分けて考えます。環境によっては 465 番ポートを使うこともあります。

SMTP-AUTHが要る理由

SMTP-AUTHが重く見られるのは、メールを送る経路を認証済みの利用者にしぼれるからです。主な意味は次の通りです。

1. 勝手な送信を防ぎやすい：認証なしで送れると、第三者に悪用されてスパム送信に使われるおそれがあります。
2. だれが送ったかを追いやすい：社外から送る場合でも、認証を必須にすると、どのアカウントで送ったかを見やすくなります。
3. 見直しや監査で使いやすい：送信ログをアカウントと結び付けやすくなり、問題が起きた後の確認もしやすくなります。

なお、SMTP-AUTHは受信者が「そのドメインを信じてよいか」を決めるものではありません。受信側でのなりすまし対策は SPF、DKIM、DMARC が受け持ちます。ここを混同すると、対策に穴が開きます。

SMTP-AUTHのやり取り

SMTP-AUTHのやり取りは、おおむね次の通りです。

1. メールクライアントがSMTPサーバーへ接続します。多くは 587 番ポートです。
2. サーバーが使える拡張を知らせ、その中に AUTH が含まれます。
3. クライアントが認証の型を選び、認証に使う情報、またはそれに相当する応答を返します。
4. サーバーはその内容を確かめ、成功した場合だけ MAIL FROM、RCPT TO、DATA を受け付けます。

ここで気を付けたいのは、認証に使う情報をどう守るかです。認証の型そのものは暗号化を行わないものもあるため、STARTTLS や暗黙TLSと組み合わせることが実質的に必要です。

SMTP-AUTHの認証の型

SMTP-AUTHでは複数の型が使われます。実際に見ることが多い例は次の通りです。

ここは単純に「CRAM-MD5なら安全」「PLAINやLOGINは危険」と切ってしまわない方がよい所です。実際には、TLSを強制できているか、パスワードやトークンをどう守るか、漏えい時にどう止めるかといった条件で安全性が変わります。

SMTP-AUTHの設定のしかた

SMTP-AUTHを使うには、サーバー側とクライアント側の両方で設定が要ります。ここでは、製品ごとの細かな手順ではなく、共通して見る点を挙げます。

メールサーバー側で決めること

サーバー側では、どの入口で認証を必須にするか、どこで利用者を確かめるか、TLSをどう扱うかを決めます。

1. Submissionポートを決める：利用者の送信は 587 番、または環境に応じて 465 番に集めます。
2. 認証元を決める：ローカルアカウント、LDAP や AD など、どこで利用者を確かめるかを決めます。
3. TLSを必須にする：認証に使う情報を守るため、暗号化しない接続を許さない設計にします。
4. 送信の範囲を決める：認証後にどこまで送信を許すか、送信元ドメイン、通数、添付の大きさなどを決めます。
5. ログと監視を用意する：失敗した回数や急に大量に送ることを見つけられるようにします。

SMTP-AUTHは、入れた瞬間に終わる対策ではありません。アカウントが盗まれた後に大量に送ることをどう早く止めるかまで考えて、送る通数の上限や警告も一緒に決める方が現実的です。

メールクライアント側で合わせること

クライアント側では、主に次の項目を合わせます。

1. 送信サーバーのホスト名とポート番号
2. TLS の有無や方式
3. 「送信サーバーは認証が必要」といった設定
4. ユーザー名とパスワード、または組織で決めた別の資格

組織によっては、通常のパスワードではなく、アプリ用のパスワードやトークンを使うこともあります。ユーザー向けには、なぜ送信にも認証が要るのか、パスワードを使い回してはいけない理由、失敗したときの連絡先をまとめて知らせると、問い合わせを減らしやすくなります。

SMTP-AUTH設定時の注意点

• TLSを外さない：特に PLAIN と LOGIN を使う場合、暗号化しない接続を許さないことが大事です。
• 認証の型をそろえる：サーバー側で使える型と、クライアント側が選ぶ型が合わないと認証に失敗します。
• ポートの使い分けを崩さない：25 番はサーバー間転送が中心で、利用者の送信は 587 番や 465 番で受けるのが基本です。
• アカウント流出に備える：SMTP-AUTHがあっても、盗まれた正規のアカウントからスパム送信されることがあります。

SMTP-AUTHで起きやすい不具合

SMTP-AUTHまわりのエラーは、原因を順に切り分けると戻しやすくなります。よくある例は次の通りです。

同じ設定でも、一部の利用者だけ失敗することがあります。その場合は、パスワード変更の直後か、MFAの追加があったか、アクセス制限の方針が変わっていないかも見ます。

SMTP-AUTHの利点と弱点

SMTP-AUTHの利点

• 勝手な送信を減らしやすい：認証した人以外の送信を止めやすくなります。
• だれが送ったかを残しやすい：送信ログをアカウントと結び付けやすくなります。
• 送信ルールを決めやすい：通数、送信元アドレス、社外からの送信などを決めやすくなります。

ただし、SMTP-AUTHを入れれば、受信側でのなりすましを防げるわけではありません。SMTP-AUTHは送る側の入口を締める技術です。

SMTP-AUTHの弱点

• 設定と保守の手間がかかる：サーバーとクライアントの設定、証明書、ユーザー向けの案内が要ります。
• アカウント流出時は悪用される：正規のアカウントが盗まれると、その資格で大量に送ることができてしまいます。
• 問い合わせが起きやすい：TLS の不一致、ポートの誤り、認証の型の違いなどで詰まりやすい分野です。

SMTP-AUTHを使う方がよい場面

• 社外ネットワークからも正しい利用者にメールを送らせたい
• オープンリレーや悪用を抑えたい
• だれが送ったかを見返せる形にしたい

SMTP-AUTHを使わない方がよい場面はあるか

「使わない方がよい」と言い切れる場面はあまりありません。外部へメールを送るなら、SMTP-AUTHに相当する送信の制御が要ることが多いためです。入れにくい事情があるなら、クラウドのメールサービス側の認証に寄せる、送信元を限定するなどの代わりの手を考える方が現実的です。

導入の可否は、組織の大きさよりも、メールを送る経路が外へ開いているか、アカウント管理と監視を続けられるかで見る方が実態に合います。

SMTP-AUTHとほかの技術の違い

メールの安全性は、複数の技術が分担して支えています。ここを分けて理解すると、抜けを減らせます。

SMTP-AUTHとSSL/TLS（STARTTLS）の違い

• SMTP-AUTH：送信者である利用者を確かめ、送信の許可を決めます。
• SSL/TLS（STARTTLS）：クライアントとサーバーの間の通信を暗号化し、盗み見や改ざんを防ぎます。

SMTP-AUTHは認証、SSL/TLSは暗号化です。多くの環境では、SMTP-AUTHとTLSをセットで考えます。

SMTP-AUTHとPOP before SMTPの違い

• SMTP-AUTH：SMTP接続の中でその場で認証します。
• POP before SMTP：先に POP3 で認証した記録を使い、しばらくの間だけSMTP送信を許すやり方です。

POP before SMTP は仕組みが間接的で、NAT環境や複数の利用者で同じ回線を共有する環境では扱いにくいことがあります。今は SMTP-AUTH を基本にする設計が一般的です。

SMTP-AUTHとSPFの関係

• SMTP-AUTH：送信時に利用者を確かめます。
• SPF：受信側で、そのドメインから送ってよい送信元IPかを確かめます。

SMTP-AUTHが整っていても、SPF が整っていなければ、なりすましや到達率の問題が残ることがあります。

SMTP-AUTHとDKIMの関係

• SMTP-AUTH：送る人やアカウントが正しいかを送信側で確かめます。
• DKIM：メールに署名データを付け、受信側で改ざんの有無や署名したドメインを確かめます。

実際には、SMTP-AUTHで送信の入口を締め、DKIMや必要に応じてDMARCで受信側の判定を助ける形で使い分けます。

まとめ

SMTP-AUTHは、メール送信時に利用者を認証し、許可した人だけに送信を認めるものです。オープンリレーや勝手な送信を抑えやすくなり、だれが送ったかも追いやすくなります。とくに社外から送信させる環境では、要る度合いが高くなります。

ただし、SMTP-AUTHだけでメールの安全性が十分になるわけではありません。TLS、SPF、DKIM、必要に応じてDMARCまで含めて考える必要があります。入れるときは、Submissionポートの分離、TLSの強制、アカウント流出を想定した通数の上限や監視までセットで決めることが大事です。