短い回答: この原因は 2 つあります: caching（繰り返しチェックすると保存された結果が返される場合があります）と 一時的なサーバー条件（一時的な unknown は後で実際の回答に解決できます）。force-refresh リクエストは常に新しいライブ チェックを実行します。
キャッシュ
検証を高速に保ち、メール サーバーへのハンマー攻撃を避けるために、確認された結果は約 24 時間キャッシュされます。 そのウィンドウ内で同じアドレスを再度確認すると、新しいライブ チェック — ではなく キャッシュ済み の結果が表示される可能性があり、その料金は再度請求されません。これにより、繰り返しの検索が瞬時に行われます。
1 つの例外: unknown の結果はキャッシュされません。 「これを確認できませんでした」は一時的な答えであるため、unknown アドレスを再チェックすると常に新しいライブ検証 — が実行されます。これがまさに、unknown が後の試行で明確な結果に変わる可能性がある理由です。
キャッシュを無視したまったく新しいライブ検証を強制するには、force_refresh=true でリクエストを送信します。フォースリフレッシュは実際のチェックを実行し、新しい結果に応じて請求されます。
過渡的な条件
以前の unknown の結果の一部は、受信側の一時的な条件によって引き起こされます:
- Greylisting — サーバーは最初の試行を意図的に延期し、後の試行を受け入れます。
- 料金制限 — その瞬間、プロバイダーはトラフィックを抑制していました。
- Timeouts — サーバーが一時的に遅くなったり、アクセスできなくなったりしました。
後で再確認すると、これらの条件はクリアされている可能性があるため、以前の unknown は明確な valid または invalid になる可能性があります。これは予想される動作であり、不一致ではありません。
おすすめするもの
- 決定的な 2 番目の答えを得るには、
force_refresh=trueを使用してください。 - リストをバッチ検証している場合、すべてのアドレスを強制的に更新する必要はありません。— キャッシュされた結果は鮮度ウィンドウ内で正確であり、クレジットを保存します。
- 再試行時に
unknownから明確なステータスに反転する結果は良い兆候です。これは、一時的な条件がクリアされ、実際の答えが得られたことを意味します。