451 4.7.1 グレーリスティングの遅延対処

この記事では、メールの遅延や 451 4.7.1 の応答がグレーリスティング（greylisting）によるものである場合の仕組み、「待てば届くのか」の見分け方、そして対処が必要なケースを整理します。

エラーコード 451 4.7.1 の意味

メール送信時に送信元へ返る応答には、SMTP（メールを送受信する通信手順、RFC 5321）の応答コードが含まれます。451 4.7.1 は次のように分解できます。

• 451: 一時的な配信失敗を表す応答コード。先頭が 4 なので「いまは受け取れないが、後で再送すれば通る可能性がある」一時エラー
• 4.7.1: 拡張ステータスコード（RFC 3463）。7.x はセキュリティ / ポリシー関連を示し、グレーリスティングの一時拒否でよく使われる

文面としては、次のような形で返ってくることが多いです。

451 4.7.1 Greylisting in effect, please try again later

ここで最も重要なのは、これが 4xx（一時拒否） だという点です。550 5.x.x（永続拒否）と違い、4xx は「再送すれば配信される見込みがある」状態を意味します。一時エラーと永続エラーの違いはメールバウンスの分類と対処で、コード体系全体はSMTP 応答コード早見表で整理しています。本記事は、この 451 4.7.1 がグレーリスティングによって返るパターンに絞ります。

グレーリスティングの仕組み

グレーリスティング（greylisting）は、迷惑メール対策の手法の 1 つです（RFC 6647 で applicability statement として整理されています）。考え方はシンプルで、「初めて見る送信元からのメールは、いったん一時拒否して、もう一度送ってくるかどうかを試す」 というものです。

仕組みの核心は、受信側が次の 3 つの組み合わせ（三つ組、triplet）を記録することにあります。

• 送信元の IP アドレス
• 送信者（差出人）のアドレス
• 受信者（宛先）のアドレス

初めて見る三つ組のメールが来ると、受信側は 451 4.7.1 で一時的に拒否します。正しく設定されたメールサーバ（Postfix / Exim / Microsoft 365 / Google Workspace 等）は、一時拒否を受けると時間をおいて自動的に再送します。再送が届くと、受信側は「先ほどの三つ組がまた来た = まともな送信元だ」と判断して受理します。

なぜこれが迷惑メール対策になるのかというと、大量の迷惑メールを送る仕組みの多くは「一時拒否されたら再送する」という SMTP の正しい振る舞いを省略しているためです。再送してこない送信元はそこで脱落し、再送してくる正規の送信元だけが通過します。

その結果として生じるのが 初回の遅延 です。最初のメールが一時拒否され、再送されるまでの待ち時間ぶん、配信が遅れます。待ち時間は受信側の設定によって異なり、典型的には数分から数十分程度です。一度通過した三つ組はしばらく記憶されるため、2 通目以降は遅延なく届くのが一般的です。「最初の 1 通だけ妙に遅れて届いた」という現象の正体は、多くがこれです。

待てば届くか、対処が必要か

451 4.7.1 を見たとき、まず判断したいのは「待っていれば自動的に届くのか」「こちらで何かする必要があるのか」です。分かれ目は 送信側のサーバが正しく再送する設定になっているか にあります。

待てば届くケース

通常のメールサーバ（Microsoft 365、Google Workspace、一般的なホスティングのメール機能など）は、一時拒否を受けると自動で再送します。この場合、送信者が手で何かする必要はありません。初回だけ数分から数十分遅れて届き、以降は通常どおりです。慌てて同じメールを何度も送り直すと、受信側に「短時間の大量送信」と見なされ、別のエラー（レート制限など）を誘発することもあるため、基本は 再送機構に任せて待つ のが正解です。

対処が必要なケース

問題になるのは、送信側が 一時拒否を受けても再送しない 場合です。具体的には次のような構成です。

• アプリケーションやスクリプトから直接 SMTP 送信していて、4xx を受けたら再送せず諦める実装になっている
• 古い、または簡易な送信機器・複合機からのメール送信で、再送ロジックを持たない
• 送信間隔が極端に短いバッチ処理で、再送前にプロセスが終了してしまう

これらの構成では、グレーリスティングの初回一時拒否でメールが 欠落 します。「送ったはずなのに相手に届かず、エラーにも気づかない」という最も厄介な状態になり得ます。この場合は送信側の再送設定を確認し、再送できる経路（適切なメールサーバや送信サービス経由）に切り替えるのが対処になります。

認証の問題と取り違えない

451 4.7.1 の 4.7 はセキュリティ / ポリシー関連を示すため、SPF / DKIM / DMARC（メールが正規の送信元から送られたことを証明する仕組み）の失敗と紛らわしいことがあります。グレーリスティングは「再送で通過する」のが特徴ですが、認証失敗は再送しても通りません。再送しても繰り返し拒否される場合は、グレーリスティングではなく認証側を疑い、DMARC が fail するときの調べ方やDMARC とは何かを参照してください。

遅延を業務でどう扱うか

グレーリスティングの初回遅延は仕組み上避けにくいものですが、業務影響は運用で抑えられます。

• 時刻認証メールに注意する: ワンタイムパスワードや有効期限の短い通知メールは、初回遅延で期限切れになることがあります。送信元の構成によっては影響が出るため、重要な即時系メールは経路を確認しておきます
• 一斉配信は初回遅延を見込む: 新しい送信元から多数の宛先へ初めて送る場合、相当数が初回一時拒否を受けます。配信完了までに時間がかかる前提でスケジュールを組みます
• 送信ドメイン認証を整える: グレーリスティングとは別軸ですが、SPF / DKIM / DMARC を正しく設定しておくと送信ドメインの信頼性が保たれ、ほかの拒否要因を減らせます。永続拒否側の代表例は550 5.1.1 user unknown の原因と対処も参考になります

「遅れて届く」ことそのものは異常ではなく、迷惑メール対策が働いている正常な動作であるケースが多い、という前提で落ち着いて切り分けることが大切です。

よくある質問

451 4.7.1 は放っておけば届きますか

送信側のサーバが正しく再送する設定なら、多くの場合は自動で再送され、初回だけ遅れて届きます。待ち時間は受信側の設定によって異なり、典型的には数分から数十分程度です。ただし送信側が再送しない構成（直接 SMTP 送信するスクリプトや古い機器など）では届かないことがあるため、再送設定の確認が必要です。

何度も手動で送り直してもいいですか

おすすめしません。4xx は送信側のサーバが自動で再送します。手動で連投すると、短時間の大量送信と見なされてレート制限などの別エラーを招くことがあります。再送機構に任せて待つのが基本です。

毎回 451 が出るのはなぜですか

一度通過した三つ組（送信元 IP・送信者・受信者の組み合わせ）はしばらく記憶されるため、通常は 2 通目以降に遅延は出ません。毎回 451 が返る場合は、送信元 IP が毎回変わる構成だったり、記憶の保持期間が短かったりする可能性があります。また、再送しても繰り返し拒否されるなら、グレーリスティングではなく認証やポリシーによる拒否を疑います。

グレーリスティングと認証失敗はどう見分けますか

グレーリスティングは「再送すれば通過する」のが特徴です。一方、SPF / DKIM / DMARC の認証失敗は再送しても通りません。再送しても同じ拒否が続く場合は認証側を確認します。切り分けの手順はDMARC が fail するときの調べ方を参照してください。

まずは現状を把握しましょう

自社のドメインがどのような状態にあるか、無料のドメイン診断で現状をチェックできます。 SPF・DKIM・DMARC・SSL の状態が数十秒でレポートされます。 設定状況がわからない方は、お問い合わせからお気軽にご相談ください。専門家がわかりやすくサポートいたします。