送信者向けSMTP応答コードの解説

結論から#

メールサーバーは、別のメールサーバーと通信するたびに、受け取った各コマンドに3桁のコードで応答します。最初の桁がカテゴリを示します。2xxは成功、4xxは一時的な失敗、5xxは恒久的な失敗です。到達率について言えば、この最初の桁がほぼすべてを物語っています。メールアドレス検証ツールも、プローブの際に同じコードを読み取り、メッセージを一切送らずに、メールボックスが到達可能、到達不能、または判定不能のどれなのかを判断します。このガイドでは、実際によく目にするコードと、それぞれから導かれる判定を解説します。

応答コードの読み方#

SMTPコードには一貫した文法があります。最初の桁は結果の区分です。

• 2xx：成功です。コマンドが正常に処理されました。250（「requested action completed」）が、期待される応答です。
• 4xx：一時的な失敗です。問題が起きましたが、後で再試行すれば成功する可能性があります。これは拒否ではなく、保留です。
• 5xx：恒久的な失敗です。サーバーは拒否しており、再試行しても結果は変わりません。

多くのサーバーは拡張ステータスコードも返します。5.1.1のようにドットで区切られた2つ目の数字で、RFC 3463で定義されています。中央の数字が理由を絞り込みます。x.1.xはアドレス、x.2.xはメールボックス、x.7.xはセキュリティまたはポリシーに関するものです。このx.7.xの区分があるおかげで、人間向けのテキストがあいまいでも、検証ツールはレピュテーションによるブロック（「送信者を拒否している」）と、単純なメールボックスの不在を区別できます。

検証における対応づけは、驚くほど明快です。

実際によく見るコード#

250：OK#

受信者が受け付けられたことを示します。検証プローブでは、これが最も強い肯定的なシグナルです。ただし、文脈の中で読む必要があります。キャッチオールドメインでは、サーバーが実在するかどうかにかかわらずすべてのアドレスに250を返します。そのため、実在しない適当なアドレスへの並行プローブが拒否される場合にだけ、その250に意味があります。

421：サービスを利用できない#

サーバーが接続を閉じようとしています。過負荷か、送信側へのスロットリングが原因であることが多くあります。区分としては一時的なものです。検証ツールは保留として扱って再試行し、それでも続く場合はunknownと報告します。

450 / 451：メールボックスを利用できない / ローカルエラー、再試行してください#

典型的なグレーリスティングの応答です。サーバーは見慣れない送信者を一時的に拒否し、再試行を促しています。実際のメールサーバーは自動で再試行します。検証ツールは、制限時間の範囲内で再試行し、保留がそれより長引く場合はunknownに切り替えます。451では、テキストに「greylisted, please try again later」と含まれることがよくあります。

452：システムの記憶域が不足 / 受信者が多すぎる#

メールボックスが満杯であることを意味する場合が多くあります。メールボックスは存在しています。そのためQualisendでは、満杯のシグナルを到達不能ではなくrisky（low_deliverability）として扱います。今はバウンスしても、アドレスが失われたわけではなく、満杯のメールボックスは回復することが多いからです。

550：メールボックスを利用できない / ユーザー不明#

最も多用される拒否の応答です。アドレスが存在しないか、サーバーが配信を恒久的に拒否しています。判定はundeliverable / rejected_emailです。拡張コードが5.1.1なら、「bad destination mailbox」を表します。「該当するユーザーなし」であることが、明確に示されています。

551 / 553：ユーザーがローカルにいない / メールボックス名が許可されない#

あまり多くない恒久的な拒否です。サーバーがその受信者へのリレーに応じない、またはアドレスの形式が受け入れられないことを示します。どちらもundeliverableです。

554：トランザクションの失敗#

あらゆる恒久的な失敗をまとめて受ける応答で、ポリシーによるブロックによく使われます。「transaction failed」「message refused」、またはスパム対策による拒否といった内容です。5.7.xの拡張コードやブラックリストに関するキーワードを伴う場合は、サーバーがメールボックスではなく送信者を拒否していることを示します。優れた検証ツールは、この2つを区別して記録します。レピュテーションの問題が、無効なアドレスと誤読されないようにするためです。

そのほかのステップで見るコード#

判定を左右するのはRCPT TOへの応答ですが、検証プローブはそこに至るまでに、他のコードもいくつか読み取ります。それらを知っておくと、生のSMTPログやバウンスメッセージを読むときに役立ちます。

• 220：サービスの準備完了。 接続したときにサーバーが送るあいさつです。220がなければ、そもそも接続できていません。多くは接続レベルのブロックで、検証ツールはunavailable_smtpとして記録します。
• HELO/EHLOとMAIL FROMのあとの250。 ハンドシェイクの各ステップに、それぞれ250が返ります。たとえばMAIL FROMなど、RCPT TOの前に拒否された場合は、通常、サーバーが受信者ではなく送信者を拒否しています。
• 354：メール入力の開始。 サーバーがメッセージ本文の送信を促しています。検証ツールは、意図的にここまで進みません。RCPTで止めて切断するため、メッセージは送信されません。
• 221：接続を閉じる。 QUITのあとの、丁寧な別れのあいさつです。
• 501/502/503：構文またはシーケンスのエラー。 コマンドの形式が不正、または順序が誤っています。これはアドレスではなくやり取り自体の問題です。堅牢な検証ツールは、メールボックスの判定と誤読せずに処理します。

実務上のポイントは、250以外がすべて無効なメールボックスを意味するわけではないことです。やり取りの途中の誤ったステップでの拒否は、通常、送信者や接続に関するものです。どのステップで失敗したかを読み取ることで、検証ツールは、サーバーの機嫌の問題を受信者のせいにしなくて済みます。

恒久的か一時的か、そして正直に「不明」と答えること#

検証ツールが下す最も重要な判断は、4xxをどう扱うかです。恒久的な5xxは簡単です。アドレスは不良なので、抑制します。250も簡単です。キャッチオールの注意点を除けば、到達可能です。しかし4xxは、サーバーがまだ答えないと明示している状態です。正直な対応は、再試行し、保留が続くならunknownと報告することであり、推測することではありません。

このことは、ツールが嘘をついていなくても、同じアドレスが実行のたびに異なる判定を返しうる理由でもあります。メールボックスの状態は変わらなくても、返されるコードはサーバーの機嫌に左右されます。最初の試行ではグレーリスティング、再試行では250ということが起こります。コードはデータベースの検索ではなく、リアルタイムのやり取りです。

検証のどの段階でコードを読み取るか#

検証パイプラインでは、応答コードはステージ6、つまりSMTPメールボックスプローブの素材になります。検証ツールは、HELO、MAIL FROM、RCPT TOという配信のやり取りを行い、RCPTのコードを読み取って、DATAの前に切断します。そのため、メールボックスの所有者には何も届きません。ここまでに説明した内容が、その1つのRCPTコードを、対応できるステータスに変える仕組みです。