IMAPとは｜POP3・SMTPとの違いとポート・設定をコマンド原文で

メールは「送る」と「受け取る」で使う規格が分かれています。送る側は SMTP、受け取る側は IMAP か POP3 です。相手に届くまでの流れを先に図にします。

flowchart TD
    A[自分のメールソフト] -->|SMTP 587<br>認証して送る| S[送信サーバー]
    S -->|SMTP 25<br>サーバー間| R[相手の受信サーバー]
    R -->|IMAP 993<br>置いたまま読む| B[相手のメールソフト]
    R -->|POP3 995<br>取り込む| C[相手の別のソフト]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、Dovecot 2.3.21（Ubuntu のパッケージ dovecot-imapd・dovecot-pop3d）を自分の設定ファイルで 127.0.0.1 のポート 46143（IMAP）・46993（IMAPS）・46110（POP3）・46995（POP3S）に起動し、自己署名証明書で TLS を有効にしました。SMTP は Python 3.13.18 で書いた最小のサーバー（EHLO・STARTTLS・AUTH・MAIL・RCPT・DATA に応答し、Maildir に配達する）を 127.0.0.1:46587（サブミッション）と 46025（サーバー間を模した受け口）で動かし、外部のメールサーバーには一切接続していません。コマンドと応答は Python の socket で1行ずつ送受信して記録し、プログラムからの利用は標準ライブラリの imaplib・poplib・smtplib、手での確認は OpenSSL 3.0.13 の s_client で行いました。平文認証の拒否は、ip netns の中に別の Dovecot を 10.206.0.1 に立てて確かめています（Dovecot は localhost からの接続を安全とみなす仕様のため）。Gmail・Outlook.com の設定値は Google と Microsoft の公式ヘルプ、各規格は RFC 9051・3501・1939・5321・6409・8314・2177 で確かめました。図は mermaid で描画を確かめています（確認日 2026年10月29日）。

IMAPとは（意味と役割）

この節では、IMAP が何をする規格で、メールソフトのどの設定に関わるのかが分かります。

IMAP（Internet Message Access Protocol）は、メールサーバーに置いてあるメールを、端末に取り込まずにサーバー上で読み書きするための通信の規格（プロトコル）です。 メールの本体はサーバーにあり、メールソフトはその「見え方」を同期します。既読にした、フォルダーに移した、削除した、といった操作はサーバーに記録されるので、パソコンでもスマートフォンでも同じ状態で見えます。

いま使われている版は IMAP4rev1（RFC 3501）と、その改訂版の IMAP4rev2（RFC 9051、2021年）です。手元の Dovecot も最初の応答で IMAP4rev1 と名乗りました。

S: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot (Ubuntu) ready.

IMAP・POP3・SMTPの違い（一覧表）

この節では、3つの規格の役割の違いと、メールソフトのどの欄に対応するのかが一覧で分かります。

SMTP は「送る」、IMAP と POP3 は「受け取る」の規格です。 受信は IMAP か POP3 のどちらか一方を選び、送信は必ず SMTP なので、メールソフトの設定は「受信サーバー＋送信サーバー」の2つになります。

「SMTP と IMAP の違い」は、比べるものではなく組み合わせて使うものです。送信だけできて受信できない、受信だけできて送信できない、というときは、片方の設定だけが間違っています。

メールが届くまでの流れ（SMTP→受信サーバー→IMAP/POP3）

この節では、自分のメールソフトから相手のメールソフトまで、メールがどの規格でどこを通るのかが分かります。

1. 1メールソフト → 自分の送信サーバー（SMTP・587）ユーザー名とパスワードで認証（SMTP AUTH）してから送る。サブミッション（RFC 6409）
2. 2送信サーバー → 相手ドメインの受信サーバー（SMTP・25）相手ドメインの MX レコードを DNS で引いて配送する。サーバー同士のやりとり
3. 3受信サーバーがメールボックスに保存Maildir や mbox などの形式でディスクに置く
4. 4相手のメールソフト → 受信サーバー（IMAP・993 か POP3・995）IMAP ならサーバー上で読む。POP3 なら端末に取り込む

手元の環境で、この流れを 127.0.0.1 だけで再現しました。自作の SMTP サーバーに 46587 で認証して送ると Maildir に保存され、直後に IMAP で SELECT INBOX すると件数が1つ増え、POP3 の STAT でも +OK 5 1394（5通・1394バイト）と同じ件数が返りました。同じメールボックスを IMAP と POP3 のどちらで見るかの違いであって、メールの置き場所は同じです。 MX レコードの引き方は、関連記事「nslookupの使い方｜逆引き・DNS指定・MX・エラーの意味を実例で」で扱っています。

IMAPとPOP3の違いを2台の端末で確かめる

この節では、「既読が同期する・しない」「別の端末で受信できなくなる」を、実際に2つの接続を張って確かめた結果が分かります。

IMAP では端末 A の操作が端末 B にそのまま見え、POP3 では端末 A が何をしたかを端末 B は知らず、削除すると端末 B では受信できなくなりました。 同じ INBOX に対して、接続 A と接続 B（端末2台のつもり）を Python から張った結果です。

--- IMAP: 端末A と 端末B が同じ INBOX を開く ---
B 最初: ['1 (FLAGS ())', '2 (FLAGS ())', '3 (FLAGS ())', '4 (FLAGS ())', '5 (FLAGS ())']
A: 2 を既読、3 にフラグ
B NOOP後: ['2 (FLAGS (\\Seen))', '3 (FLAGS (\\Flagged))', '1 (FLAGS ())', '2 (FLAGS (\\Seen))', '3 (FLAGS (\\Flagged))', ...]

--- POP3: 端末A が受信（サーバーに残す）→ 端末B ---
A STAT: (5, 1394)
A: 1,2 を RETR（DELE せず）して QUIT
B STAT: (5, 1394) -> 既読かどうかは B に伝わらない
--- POP3: 端末A が受信してサーバーから削除 → 端末B ---
A: 1 を RETR + DELE して QUIT
B STAT: (4, 973) -> 1通減った。B では受信できない

IMAP の B の結果に 2 (FLAGS (\Seen)) が2回出ているのは、NOOP を送った瞬間にサーバーが「2番のフラグが変わった」と自分から知らせ（* 2 FETCH (FLAGS (\Seen))）、そのあと改めて一覧を取ったためです。

ポート番号一覧（143/993・110/995・25/587/465）とSSL/TLS・STARTTLSの違い

この節では、メールの各ポートが何のためにあり、「SSL/TLS」と「STARTTLS」でなぜポートが変わるのかが分かります。

同じ規格でも、「最初から暗号化する（SSL/TLS・暗黙の TLS）」と「平文で始めて途中から暗号化する（STARTTLS）」でポートが分かれています。 RFC 8314（2018年）は、メールソフトからの接続には最初から暗号化するポート（993・995・465）を優先するよう勧めています。

STARTTLS の実物

143 に平文でつないで STARTTLS を送ると、サーバーが「いまから TLS を始める」と答え、そこから先が暗号化されます。暗号化のあとに CAPABILITY を取り直すと、STARTTLS が消えて AUTH=PLAIN AUTH=LOGIN が現れました。

S: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot (Ubuntu) ready.
C: a1 STARTTLS
S: a1 OK Begin TLS negotiation now.
-- TLS handshake done: TLSv1.3 TLS_AES_256_GCM_SHA384
C: a2 CAPABILITY
S: * CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN
S: a2 OK Pre-login capabilities listed, post-login capabilities have more.

ポートと暗号化方式の組み合わせを間違えると、認証の前に接続そのものが失敗します。143 に「SSL/TLS（最初から）」でつなぐと [SSL: WRONG_VERSION_NUMBER] wrong version number、993 に「暗号化なし」でつなぐとサーバーの挨拶が来ずにタイムアウトしました（エラーの節で一覧にしています）。

• 1993・995・465 には「SSL/TLS」メールソフトの暗号化の欄が「SSL/TLS」「SSL」「暗黙の TLS」ならこちら
• 2143・110・587 には「STARTTLS」欄が「STARTTLS」「TLS」「可能なら TLS」ならこちら。Outlook の「TLS」はこの意味
• 3「なし」は使わないパスワードがそのまま流れる。手元のサーバーは平文の LOGIN を [PRIVACYREQUIRED] で拒否した
• 425 はメールソフトに書かないサーバー間用。送信は 587 か 465

ポート番号の全体像と、どのポートが開いているかの調べ方は、関連記事「ポート番号一覧【2026年版】well-knownポートと確認コマンドの早見表」で扱っています。

IMAPのコマンドと応答の原文（LOGIN・LIST・SELECT・FETCH・STORE）

この節では、メールソフトが裏で送っている IMAP のコマンドと、サーバーの応答の読み方が、実際のやりとりで分かります。

IMAP は「タグ コマンド」を送り、サーバーが「* で始まるデータ行」を返したあと、「同じタグ OK/NO/BAD」で締める会話です。 手元の Dovecot に STARTTLS 後に送った原文です（パスワードは伏せています）。

LOGIN：失敗と成功

C: a3 LOGIN alice ********        ← 違うパスワード
S: a3 NO [AUTHENTICATIONFAILED] Authentication failed.
C: a4 LOGIN bob ********          ← 存在しないユーザー
S: a4 NO [AUTHENTICATIONFAILED] Authentication failed.
C: a5 LOGIN alice ********        ← 正しい
S: a5 OK [CAPABILITY IMAP4rev1 ... IDLE SORT THREAD=REFERENCES ... UIDPLUS LIST-EXTENDED ... MOVE ...] Logged in

パスワード違いと存在しないユーザーで、クライアントに返る文言は同じでした（どちらが間違いかを相手に教えないため）。サーバーのログには区別して残ります。

auth: Info: passwd-file(alice,127.0.0.1,<T16Fi/Zenph/AAAB>): Password mismatch
auth: Info: passwd-file(bob,127.0.0.1,<T16Fi/Zenph/AAAB>): unknown user
imap-login: Info: Login: user=<alice>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=7818, TLS, session=<T16Fi/Zenph/AAAB>

LIST・SELECT：フォルダーの一覧と受信箱を開く

C: a6 LIST "" "*"
S: * LIST (\HasNoChildren) "." INBOX
S: a6 OK List completed (0.004 + 0.000 + 0.003 secs).
C: a7 SELECT INBOX
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
S: * 3 EXISTS
S: * 3 RECENT
S: * OK [UNSEEN 1] First unseen.
S: * OK [UIDVALIDITY 1793262887] UIDs valid
S: * OK [UIDNEXT 4] Predicted next UID
S: a7 OK [READ-WRITE] Select completed (0.001 + 0.000 secs).

3 EXISTS が「3通ある」、[UNSEEN 1] が「最初の未読は1番」です。UIDVALIDITY と UIDNEXT は、メールソフトが「前回からどれが増えたか」を判断するための番号です。

FETCH：件名だけ、本文だけ、全部

C: a8 FETCH 1:* (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
S: * 2 FETCH (FLAGS (\Recent) INTERNALDATE "29-Oct-2026 17:31:47 +0900" RFC822.SIZE 293 ENVELOPE ("Wed, 29 Oct 2026 09:05:00 +0900" "[CI] build #42 passed" (("Build Bot" NIL "notify" "example.test")) ... "<m2@example.test>"))
S: a8 OK Fetch completed (0.001 + 0.000 secs).
C: a10 FETCH 2 BODY[TEXT]
S: * 2 FETCH (FLAGS (\Seen \Recent) BODY[TEXT] {30}
S: All 128 tests passed in 42s.
S: )
S: a10 OK Fetch completed (0.001 + 0.000 secs).

メールソフトの一覧画面は ENVELOPE（差出人・件名・日付）だけを取り、開いたときに BODY[] を取ります。BODY[TEXT] を取った瞬間に \Seen（既読）が付いた点に注目です。既読にせず中身を見たいときは BODY.PEEK[...] を使います（IDLE の節で使っています）。日本語の件名は =?UTF-8?B?...?= の形（MIME エンコード）で返り、復号はメールソフトの仕事です。

STORE・SEARCH・CREATE・MOVE・EXPUNGE：既読・検索・フォルダー・削除

C: a12 STORE 2 +FLAGS (\Seen)
S: a12 OK Store completed (0.001 + 0.000 secs).
C: a14 SEARCH UNSEEN
S: * SEARCH 3
C: a15 SEARCH FROM "hanako"
S: * SEARCH 3
C: a16 CREATE Archive
S: a16 OK Create completed (0.003 + 0.000 + 0.002 secs).
C: a18 MOVE 3 Archive
S: * OK [COPYUID 1793262888 3 1] Moved UIDs.
S: * 3 EXPUNGE
C: a20 STORE 1 +FLAGS (\Deleted)
S: * 1 FETCH (FLAGS (\Deleted \Seen \Recent))
C: a21 EXPUNGE
S: * 1 EXPUNGE
S: a21 OK Expunge completed (0.001 + 0.000 secs).

IMAP の削除は2段階です。\Deleted を付けただけでは消えず、EXPUNGE で初めて消えます。メールソフトで「削除したのに別の端末に残っている」ときは、この2段階目がまだのことがあります。

プログラムから使う（Python imaplib）

Python の標準ライブラリで同じことができます。手元の 46993 に対して実行した例です。

import imaplib, ssl
ctx = ssl.create_default_context(cafile="cert.pem")   # 本番は公的な証明書なので cafile は不要
m = imaplib.IMAP4_SSL("127.0.0.1", 46993, ssl_context=ctx)
m.login("alice", "********")
typ, data = m.select("INBOX")          # ('OK', [b'5'])  ← 5通
typ, nums = m.search(None, "UNSEEN")   # 未読の番号
typ, msg = m.fetch(b"2", "(BODY.PEEK[HEADER.FIELDS (SUBJECT)])")
m.logout()

IMAP IDLE（新着のプッシュ通知）の実物

この節では、スマートフォンに新着がすぐ届く仕組み IMAP IDLE が、実際にどう動くのかが分かります。

IDLE（RFC 2177）は、クライアントが「待つ」と宣言して接続を開けたままにし、サーバーが新着やフラグの変化を自分から知らせる拡張です。 定期的に見に行く（ポーリング）必要が無くなります。手元で IDLE を送り、3秒後に別の経路で Maildir にメールを置いた結果です。

C: a3 IDLE
S: + idling
-- (3.0s) new mail written to Maildir/new
S: * 4 EXISTS
   (received 3.5s after IDLE)
C: DONE
S: * 1 RECENT
S: a3 OK Idle completed (3.504 + 3.502 + 3.503 secs).
C: a4 FETCH 4 (FLAGS BODY.PEEK[HEADER.FIELDS (SUBJECT)])
S: * 4 FETCH (FLAGS (\Recent) BODY[HEADER.FIELDS (SUBJECT)] {33}
S: Subject: new mail during IDLE
S: )
C: a5 FETCH 4 FLAGS
S: * 4 FETCH (FLAGS (\Recent))        ← PEEK なので \Seen は付かない

POP3 には IDLE に当たるものが無く、メールソフトが「○分ごとに確認」で取りに行きます。「スマートフォンで新着通知がすぐ来るのは IMAP」と言われるのは、この差です。サーバーは IDLE 中の接続を 30 分で切ってよい（RFC 2177）ので、メールソフトは 29 分以内に DONE と IDLE を送り直します。

POP3のコマンドと応答の原文（USER・PASS・LIST・RETR・DELE）

この節では、POP3 の一連のやりとりと、「サーバーにメッセージを残す」設定が何をしているのかが分かります。

POP3 は「+OK」「-ERR」の2種類で答える単純な会話で、取り込んで（RETR）、削除の印を付け（DELE）、QUIT で確定します。 46995（最初から TLS）に送った原文です。

S: +OK Dovecot (Ubuntu) ready.
C: USER alice
S: +OK
C: PASS ********                  ← 違うパスワード
S: -ERR [AUTH] Authentication failed.
C: USER alice
C: PASS ********                  ← 正しい
S: +OK Logged in.
C: STAT
S: +OK 3 995                      ← 3通・合計 995 バイト
C: LIST
S: +OK 3 messages:
S: 1 421
S: 2 293
S: 3 281
S: .
C: UIDL
S: +OK
S: 1 000000016ae30549
S: 2 000000026ae30549
S: 3 000000036ae30549
S: .
C: TOP 2 0                        ← ヘッダーだけ
S: +OK
S: From: Build Bot <notify@example.test>
S: Subject: [CI] build #42 passed
S: .
C: RETR 2                         ← 全文を取り込む
S: +OK 293 octets
S: ...（ヘッダーと本文）
S: All 128 tests passed in 42s.
S: .
C: DELE 2
S: +OK Marked to be deleted.
C: STAT
S: +OK 2 702
C: RSET                           ← 削除の印を取り消す
S: +OK
C: STAT
S: +OK 3 995
C: QUIT
S: +OK Logging out.

メールソフトの「サーバーにメッセージのコピーを置く」「○日後にサーバーから削除」は、RETR のあと DELE を送るかどうか、いつ送るかの設定です。RFC 1939 の元の設計は「取り込んだら消す」ですが、いまは残す設定が既定のメールソフトが多くなっています。

SMTPのコマンドと応答の原文（EHLO・STARTTLS・AUTH・MAIL・RCPT・DATA）

この節では、送信のときに流れる SMTP の会話と、「認証が要る」「中継を断られた」がどの応答なのかが分かります。

SMTP は3桁の数字で答え、2xx が成功、3xx が続きを促す、5xx が失敗です。 自作の SMTP サーバーの 46587（サブミッション）に送った原文です。認証の前に送ろうとすると 530、暗号化のあとに AUTH が現れ、宛先が無ければ 550 になりました。

S: 220 mail.example.test ESMTP lab-smtpd ready
C: EHLO laptop.local
S: 250-mail.example.test
S: 250-SIZE 10485760
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<alice@example.test>      ← 認証せずに送ろうとした
S: 530 5.7.0 Authentication required
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
-- TLS handshake done: TLSv1.3
C: EHLO laptop.local
S: 250-AUTH PLAIN LOGIN                 ← 暗号化後に AUTH が現れる
S: 250 ENHANCEDSTATUSCODES
C: AUTH PLAIN AGFsaWNlAHdyb25ncGFzcw==  ← 違うパスワード（Base64）
S: 535 5.7.8 Authentication credentials invalid
C: AUTH PLAIN AGFsaWNlAHNlY3JldDEyMw==
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<alice@example.test>
S: 250 2.1.0 Ok
C: RCPT TO:<nobody@example.test>
S: 550 5.1.1 <nobody@example.test>: Recipient address rejected: User unknown in local recipient table
C: RCPT TO:<alice@example.test>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Alice <alice@example.test>
C: Subject: sent via SMTP lab
C:
C: Hello from SMTP.
C: .
S: 250 2.0.0 Ok: queued as 1A186CD84F0
C: QUIT
S: 221 2.0.0 Bye

AUTH PLAIN の後ろは「ユーザー名とパスワードを Base64 にしただけ」で暗号ではありません。STARTTLS の前に AUTH を出さないのはそのためで、Python の smtplib も暗号化前に login() を呼ぶと SMTP AUTH extension not supported by server. と断りました。

サーバー間（25番）の受け口は認証ではなく「宛先」で判断する

C: EHLO other-mail.example.org
C: MAIL FROM:<someone@example.org>
S: 250 2.1.0 Ok
C: RCPT TO:<alice@example.test>        ← 自分のドメイン宛 → 受け取る
S: 250 2.1.5 Ok
C: RCPT TO:<friend@example.net>        ← よそ宛を中継させようとした
S: 554 5.7.1 <friend@example.net>: Relay access denied

メールソフトの送信で 554 5.7.1 Relay access denied が出るときは、認証の設定が無いまま 25 番や認証不要の受け口に送っていることが多いです。送信は 587 か 465 で、「送信サーバーは認証が必要」を有効にします。送信の実装は、関連記事「Python smtplibでメール送信｜添付・HTML・Gmail対応コード」と関連記事「Spring Bootでメール送信｜HTML・添付・Gmail設定」で扱っています。

メールソフトの設定項目の読み方（受信サーバー・送信サーバー・SSL/TLS・認証）

この節では、メールソフトの設定画面に並ぶ項目が、ここまでのどの話に対応するのかが分かります。

設定画面は「受信（IMAP か POP3）」と「送信（SMTP）」の2組で、それぞれにサーバー名・ポート・暗号化・認証の4つがあります。

GmailとOutlook.comのIMAP・POP3・SMTP設定値（公式ヘルプ）

この節では、よく設定する2つのサービスのサーバー名・ポート・暗号化を、公式ヘルプの記述で確かめた値で示します。

どちらも「IMAP は 993・SSL/TLS、SMTP は 587・STARTTLS」で、認証は OAuth2（Google でログイン／先進認証）が前提です。 2026年10月29日時点の公式ヘルプの値です。

• Gmail：公式ヘルプは、Google のユーザー名とパスワードをそのまま渡すサードパーティ製アプリをサポートしなくなったこと、「Google でログイン」を使うこと、アプリパスワードは推奨されずほとんどの場合は不要なこと、2025年1月以降「IMAP を有効にする」の設定が無くなり IMAP は常に有効なこと、1アカウントに追加できるメールクライアントは最大15個であることを説明しています。
• Gmail の POP について：2026年に「Gmail が POP をやめる」という話題がありますが、公式ヘルプ（Gmailify と POP の今後の変更）が終了を案内しているのは「他のアカウントのメールを Gmail に POP で取り込む機能」と Gmailify で、新規は2026年第1四半期以降、既存ユーザーは2027年1月までです。同じページの FAQ に、サードパーティ製アプリから Gmail のサーバーへ POP または IMAP で接続できることが書かれています。
• Outlook.com：公式ヘルプは「POP & IMAP アクセスは既定で無効になっています」「Outlook.com には、先進認証/OAuth2 を使用する必要があります」と書いています。メールソフトで使うには、まず Outlook.com の設定で POP・IMAP を有効にします。

認証エラー・接続エラーの原文と直し方

この節では、設定を間違えたときに出る文言と、どの設定を疑えばよいかが、手元で再現した原文で分かります。

エラーは「つながらない（接続・暗号化）」と「つながるがログインできない（認証）」に分けて見ると早いです。 Python の標準ライブラリで、わざと間違えた設定を12通り試した結果です。

平文での認証を断られたときの原文は、別 IP（10.206.0.2 → 10.206.0.1）から 143 に送ったときのものです。サーバーは警告も一緒に返しました。

S: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS LOGINDISABLED] Dovecot (Ubuntu) ready.
C: a2 LOGIN alice ********
S: * BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed.
S: a2 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.
C: a3 STARTTLS
S: a3 OK Begin TLS negotiation now.
C: a5 LOGIN alice ********
S: a5 OK [CAPABILITY ...] Logged in

最初の挨拶に LOGINDISABLED があるのが「暗号化するまでログインは受け付けない」の合図です（127.0.0.1 からの接続は Dovecot が安全とみなすため、この拒否は出ません）。証明書のエラーの読み方は、関連記事「opensslコマンドの使い方｜目的別一覧と実行結果・エラー対処【3系】」で扱っています。

openssl s_client で手で確かめる

メールソフトを使わずに、サーバー名・ポート・証明書・ログインまでを1行で確かめられます。993 の例です。

$ openssl s_client -connect 127.0.0.1:46993 -CAfile cert.pem -quiet
depth=0 CN = mail.example.test
verify return:1
* OK [CAPABILITY IMAP4rev1 ... AUTH=PLAIN AUTH=LOGIN] Dovecot (Ubuntu) ready.
a1 LOGIN alice ********
a1 OK [CAPABILITY ...] Logged in
a2 STATUS INBOX (MESSAGES UNSEEN)
* STATUS INBOX (MESSAGES 4 UNSEEN 3)
a2 OK Status completed (0.001 + 0.000 + 0.001 secs).
a3 LOGOUT
* BYE Logging out

143 の STARTTLS は openssl s_client -connect ホスト:143 -starttls imap、587 は -starttls smtp、110 は -starttls pop3 で同じように確かめられます。

IMAPとPOP3どちらを選ぶか（判断表）

この節では、自分の使い方に合わせて IMAP と POP3 のどちらを設定するかが決められます。

端末が2台以上、または複数人で見るなら IMAP です。 POP3 を選ぶ理由は「1台で、手元に全部残したい」「サーバーの容量が小さい」に限られます。

よくある質問

Q. IMAP とは何ですか？ A. メールをサーバーに置いたまま読み書きするための受信の規格です。既読・フォルダー分けもサーバーに記録されるので、パソコンとスマートフォンで同じ状態が見えます。現行の版は IMAP4rev1（RFC 3501）と IMAP4rev2（RFC 9051）です。

Q. IMAP と POP3 の違いは何ですか？ A. IMAP はサーバーが本体で端末は同期、POP3 は端末に取り込んで端末が本体です。手元の実験では、IMAP は端末 A の既読が端末 B に見え、POP3 は端末 A が削除すると端末 B で受信できなくなりました。

Q. SMTP と IMAP の違いは何ですか？ A. SMTP は送信、IMAP は受信の規格で、比べるものではなく組み合わせて使います。メールソフトには送信サーバー（SMTP）と受信サーバー（IMAP か POP3）の両方を設定します。

Q. IMAP のポート番号は何番ですか？ A. 993（SSL/TLS・最初から暗号化）か 143（STARTTLS・途中から暗号化）です。POP3 は 995 か 110、SMTP の送信は 587（STARTTLS）か 465（SSL/TLS）です。

Q. SSL/TLS と STARTTLS はどちらを選べばよいですか？ A. ポートと組で決まります。993・995・465 なら SSL/TLS、143・110・587 なら STARTTLS です。組み合わせを間違えると WRONG_VERSION_NUMBER やタイムアウトになりました。

Q. 「認証に失敗しました」と出ます。 A. パスワードのほか、ユーザー名がアドレス全体か @ の前か、2段階認証でアプリパスワードが要るか、Gmail・Outlook.com なら OAuth2 が必要かを順に見ます。サーバーの応答は [AUTHENTICATIONFAILED]（IMAP）・-ERR [AUTH]（POP3）・535 5.7.8（SMTP）です。

Q. 受信はできるのに送信だけ失敗します。 A. 送信サーバー（SMTP）の設定だけが違います。「送信サーバーは認証が必要」が無効だと 530 5.7.0 Authentication required、25 番に送って中継を断られると 554 5.7.1 Relay access denied になります。587 か 465 で、認証を有効にします。

Q. IMAP で削除したのに別の端末に残っています。 A. IMAP の削除は \Deleted の印を付ける段階と EXPUNGE で消す段階の2つです。メールソフトの「削除済みを整理」や「完全に削除」で2段階目が行われます。

Q. スマートフォンで新着がすぐ届くのはなぜですか？ A. IMAP IDLE です。接続を開けたままにして、サーバーが新着を自分から知らせます。手元では新着を置いてから 0.5 秒で * 4 EXISTS が届きました。POP3 には同じ仕組みが無く、定期的に取りに行きます。

Q. Gmail は POP をやめるのですか？ A. 公式ヘルプが終了を案内しているのは「他のアカウントのメールを Gmail に POP で取り込む機能」と Gmailify です（新規は2026年第1四半期以降、既存は2027年1月まで）。同じページに、サードパーティ製アプリから Gmail のサーバーへ POP または IMAP で接続できると書かれています。

Q. IMAP と POP3 を同じアドレスで両方設定してもよいですか？ A. 動きはしますが、POP3 側が「サーバーに残さない」設定だと IMAP 側からメールが消えます。どちらかに揃えるのが安全です。

Q. telnet や openssl で接続を確かめられますか？ A. 暗号化ポートは openssl s_client -connect ホスト:993、STARTTLS のポートは -starttls imap（smtp・pop3 も同様）で接続し、a1 LOGIN ユーザー名 パスワード を手で送れます。手元の実行例を本文に載せています。

まとめ

• IMAP はサーバーに置いたまま読む受信の規格、POP3 は端末に取り込む受信の規格、SMTP は送信の規格。メールソフトには受信（IMAP か POP3）と送信（SMTP）の2組を設定する。
• ポートは IMAP 993/143・POP3 995/110・SMTP 587/465（25 はサーバー間）。993・995・465 は SSL/TLS、143・110・587 は STARTTLS と組で覚える。
• 手元の2端末の実験で、IMAP は既読・フラグが同期し、POP3 は端末 A の削除で端末 B が受信できなくなった。端末が2台以上なら IMAP。
• IMAP の会話は LOGIN → LIST → SELECT → FETCH → STORE → EXPUNGE。削除は2段階、IDLE で新着が 0.5 秒で届いた。POP3 は USER/PASS → STAT → RETR → DELE → QUIT。
• 認証エラーは [AUTHENTICATIONFAILED]・535 5.7.8、組み合わせ違いは WRONG_VERSION_NUMBER・タイムアウト、中継拒否は 554 5.7.1。Gmail と Outlook.com は OAuth2 が前提で、設定値は公式ヘルプのとおり。

参考・出典

確認日はいずれも 2026年10月29日です。

• IETF「RFC 9051 Internet Message Access Protocol (IMAP) - Version 4rev2」：https://www.rfc-editor.org/rfc/rfc9051
• IETF「RFC 3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1」：https://www.rfc-editor.org/rfc/rfc3501
• IETF「RFC 2177 IMAP4 IDLE command」：https://www.rfc-editor.org/rfc/rfc2177
• IETF「RFC 1939 Post Office Protocol - Version 3」：https://www.rfc-editor.org/rfc/rfc1939
• IETF「RFC 5321 Simple Mail Transfer Protocol」：https://www.rfc-editor.org/rfc/rfc5321
• IETF「RFC 6409 Message Submission for Mail」：https://www.rfc-editor.org/rfc/rfc6409
• IETF「RFC 8314 Cleartext Considered Obsolete: Use of TLS for Email Submission and Access」：https://www.rfc-editor.org/rfc/rfc8314
• Google ヘルプ「他のメール プラットフォームで Gmail を確認する」：https://support.google.com/mail/answer/7126229?hl=ja
• Google ヘルプ「POP を使用して他のメール クライアントで Gmail のメールを読む」：https://support.google.com/mail/answer/7104828?hl=ja
• Google Workspace 管理者ヘルプ「サードパーティのメール クライアントで Gmail を設定する」：https://support.google.com/a/answer/9003945?hl=ja
• Google ヘルプ「Gmail の Gmailify と POP の今後の変更について」：https://support.google.com/mail/answer/16604719?hl=ja
• Microsoft サポート「Outlook.com の POP、IMAP、および SMTP 設定」：https://support.microsoft.com/ja-jp/office/d088b986-291d-42b8-9564-9c414e2aa040
• Dovecot「Core settings」（disable_plaintext_auth・login_trusted_networks）：https://doc.dovecot.org/2.3/settings/core/
• Python「imaplib」「poplib」「smtplib」：https://docs.python.org/ja/3/library/imaplib.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。