メール到達率を守る送信キュー滞留の監視・切り分け｜queue age・再試行・期限切れの運用
メール送信キューは、相手先サーバーへすぐ渡せなかったメッセージを一時的に保持し、時間を空けて再試行するための仕組みです。受信側の一時停止、接続タイムアウト、名前解決の失敗、送信元のレート制御などでも一時的に増えるため、キューにメッセージがあるだけで障害とはいえません。一方で、件数が少なく見えても、重要な宛先に古いメッセージが残り続けていれば、通知や取引メールが期限切れへ近づいている可能性があります。
結論として、メール送信キューは件数だけでなく、queue ageの分布、最古メッセージ、流入・流出速度、宛先ドメイン別の集中、再試行理由、配送期限までの余裕を同じ時系列で監視します。短時間の増加でも最古ageが伸びず、流出が流入を上回っていれば排出中と判断できます。反対に、特定宛先だけ古いメッセージが増え、流出が止まり、同じ一時エラーを繰り返していれば、宛先別障害や経路・設定の問題として切り分けます。
本記事のポイント
- キュー件数だけでなく、age、最古メッセージ、流入・流出、宛先別集中を同じ時系列で監視します。
- 一時的な再試行と障害は、SMTP応答、滞留先の偏り、ageの伸び、配送期限までの余裕で切り分けます。
- 復旧はキュー減少だけで終えず、最古ageの短縮、新着の通常配送、期限切れ・重複再送がないことまで確認します。
件数だけでなくage・流入出・送信先を一緒に見る
キュー監視で最も分かりやすい値はメッセージ件数ですが、件数には業務量の変動が混ざります。定時の請求通知、ウェビナー案内、システムのバッチ処理などが始まれば、正常でも一時的に増えます。そこで、現在件数を単独の固定閾値で見るのではなく、平常時の時間帯別ベースラインと比べ、メッセージがどれだけ古くなっているか、どの速さで入って出ているかを合わせます。
| 監視項目 | 分かること | 異常を疑う変化 | 単独判断の注意点 |
|---|---|---|---|
| キュー件数 | 未配送メッセージの総量 | 平常時より大きく、継続して増える | 大量送信の開始直後は正常でも増える |
| queue age分布 | 滞留が新しい層か古い層か | 古いage帯へ山が移動し続ける | 一部の古いメッセージが平均値に埋もれる |
| 最古メッセージ | 長時間取り残された配送の有無 | 件数減少中でも最古ageが伸びる | 意図的に保留した一件が値を引き上げる場合がある |
| 流入・流出速度 | キューが増加中か排出中か | 流入が流出を上回る状態が続く | 短い観測窓ではバッチの波に左右される |
| 宛先別件数・age | 障害が全体か特定ドメインか | 一つの宛先に古いメッセージが集中する | 取引量の多い宛先は平常時から件数が多い |
| 再試行理由 | 接続、DNS、認証、レート制御などの手掛かり | 同じ一時エラーが長時間反復する | 応答文だけで恒久・一時を決めつけない |
| 配送期限までの余裕 | 最終的な期限切れリスク | 重要メールがgive-up時刻へ近づく | MTA設定や用途ごとに期限が異なる |
Exchangeの公式資料では、キューへ入る毎秒メッセージ数をIncomingRate、出る毎秒メッセージ数をOutgoingRateとして扱い、OutgoingRate - IncomingRateをVelocityとしています。Velocityが正なら排出方向、負なら増加方向ですが、短い平均だけで結論を出さず、MessageCountとageの変化も見ます。たとえば送信開始直後は負でも、数分後に流出が追いついて最古ageが縮まれば、正常なバーストと判断しやすくなります。
Postfixのqshapeは、キューをage帯と宛先または送信者の集中で見るための公式ツールです。デフォルトではincomingとactiveの様子を捉え、qshape deferredでdeferredキューを調べられます。deferredが大きいこと自体を直ちに障害とせず、古いage帯への移動、特定宛先への偏り、排出速度を見てください。
正常な遅延と異常な滞留を分ける基準
SMTPは一回の接続で必ず配送を完了する仕組みではありません。相手側が一時エラーを返したときはキューに残し、後で再試行します。RFC 5321は、失敗した宛先への再試行間隔を一般に少なくとも30分とし、再試行を諦めるまでの期間を通常少なくとも4〜5日とする考え方を示しています。実際の間隔と期限はMTAやサービスの設定で異なるため、自社環境の値を監視台帳に明記します。
正常な一時遅延には「新しいメッセージが増えたが、一定時間後に流出が追いつく」「一部宛先が一時的に遅いが、ageの山が古い層へ移らない」といった特徴があります。異常な滞留では「最古ageが観測のたびに伸びる」「特定宛先へ集中したまま同じ一時エラーを反復する」「流入が止まっても流出しない」「重要メールが配送期限へ近づく」といった複数の兆候が重なります。
| 状態 | 件数 | age・最古 | 流入・流出 | 判断と対応 |
|---|---|---|---|---|
| 送信バースト | 短時間に増加 | 新しいage帯が中心 | 後から流出が上回る | 監視を継続し、排出時間が平常範囲か確認 |
| 相手先の一時制限 | 宛先別に増加 | 一部が段階的に古くなる | 間欠的に流出 | SMTP応答と宛先方針を確認し、再試行間隔を守る |
| 送信経路障害 | 広い宛先で増加 | 全体の最古ageが伸びる | 流出がほぼ停止 | DNS、接続、TLS、認証、次ホップ、サービス状態を切り分け |
| 一部メッセージの取り残し | 総数は少ない | 少数の最古ageだけ伸びる | 新着は流れる | キューID、宛先、最終応答、保留設定を個別確認 |
| 排出能力不足 | 継続して増加 | 古い層が厚くなる | 流出はあるが流入未満 | 送信量、同時接続、相手先制限、上流投入を調整 |
再試行を急ぐために、キュー全体を短い間隔で強制再送するのは避けます。RFC 5321は、同じ利用不能な宛先へ、キュー内の各メッセージが毎回それぞれ接続を試すような実装を避けるよう示しています。相手先のレート制御や障害中に再試行を集中させると、復旧を遅らせたり、自社の接続元をさらに制限させたりするおそれがあります。宛先単位のバックオフと再試行予定を尊重し、原因を直してから制御された再試行を行います。
キュー滞留を切り分ける7段階手順
- 観測時刻と影響範囲を固定する
監視アラートの時刻、対象MTA・コネクタ、全件数、最古age、業務影響を記録します。顧客通知、認証メール、見積・請求、マーケティング配信など用途を分け、同じ基盤でも優先度を混ぜません。 - age分布と宛先別集中を見る
新しいage帯だけが増えているのか、古い帯へ滞留が移っているのかを確認します。宛先ドメイン、次ホップ、送信元サービス、送信者単位で集計し、全体障害か特定経路かを絞ります。 - 流入と流出を時間窓で比較する
一時点の速度ではなく、5分、15分、1時間など複数の窓で増減を見ます。上流アプリが投入し続けている場合は、排出能力を超えていないか、重要用途と大量配信を分離できるかを確認します。 - 代表メッセージの最終応答を確認する
古いage帯、最大集中宛先、重要用途から代表キューIDを選び、最終試行時刻、次回試行、SMTP応答、接続先、送信者、受信者を確認します。個人情報をチケットへ貼り過ぎず、必要な証跡だけをマスキングして残します。 - 原因レイヤーを切り分ける
名前解決、ネットワーク接続、TLS、認証、relay・routing、相手先の一時制限、送信元IP・ドメインの評価、メッセージ内容やサイズを順に確認します。受信者単位のエラー分類はメールDSN・バウンスコードの分類と対応で整理し、MTA内部の滞留監視とは別の記録にします。 - 上流投入と再試行を制御する
原因修正中も上流が同じ速度で投入すれば、復旧前にキューが膨らみます。重要なトランザクションメールを守りながら、大量配信の新規投入を一時停止または減速し、宛先単位のバックオフを壊さない範囲で再試行します。 - 古い滞留と新着の両方で復旧を判定する
件数の減少だけでなく、最古ageが縮まり、古いage帯が消え、新着メッセージも通常時間で配送され、期限切れや重複配送がないことを確認します。確認後に上流投入を段階的に戻し、再発監視を続けます。
アラートは「件数が100件を超えたら」だけではなく、複合条件にします。たとえば、平常時比の件数増加、最古age、古いage帯の割合、流出停止、宛先別集中、重要用途の期限余裕のうち、二つ以上が一定時間続いたら通知する設計です。最初は通知のみで観測し、誤報と見逃しを記録してから重大度や自動措置を調整します。
Postfix・Exchangeで確認する実務ポイント
Postfixではqshapeで年齢分布、postqueueで個別状態を見る
Postfixでは、まずqshapeでage帯と宛先の集中を確認し、必要に応じてdeferredキューを分けます。次にpostqueue -pまたはJSON出力に対応した環境ではpostqueue -jを使い、代表メッセージのキューID、到着時刻、送信者、受信者、遅延理由を調べます。コマンドの可否と出力項目は利用中のPostfixバージョンで確認してください。
qshape
qshape deferred
postqueue -p調査中に全件を削除すると、障害の原因と未配送メッセージの証跡を失います。キューID、到着時刻、宛先ドメイン、最終応答、次回試行を保存し、破棄が必要な場合は業務所有者と配送期限を確認します。配送不能になった受信者を次回送信から除外する運用はBtoBメールリストのクリーニング手順につなげます。
ExchangeではMessageCount、IncomingRate、OutgoingRate、Velocityを組み合わせる
ExchangeのGet-Queueではキューの状態、MessageCount、NextHopDomain、LastErrorなどを確認できます。Microsoft Learnは、MessageCountが100を超えるキューを抽出する例として次のフィルターを示しています。ただし100は環境共通の障害閾値ではありません。自社の平常件数と送信量を基準に変えてください。
Get-Queue -Filter "MessageCount -gt 100"NextHopDomain別に件数と最終エラーを見れば、特定宛先への集中を把握できます。IncomingRate、OutgoingRate、Velocityは増減方向の判断に使い、件数と最古メッセージの実時刻を同じ監視画面へ置きます。再試行や再送信を実行する前に、原因が解消していること、相手先へ負荷を集中させないこと、重要用途を優先できることを確認します。
PostfixでもExchangeでも、監視項目名だけをそろえて終わりではありません。送信基盤、アプリ、メール配信サービスの責任境界、アラート一次対応者、業務判断者、上流停止権限、再試行権限、期限切れ時の通知先を運用表にします。配信基盤全体の要件はメール配信ツールの機能要件、到達率の総合指標はメール到達率を改善する確認項目と合わせて整理できます。
復旧後に確認するチェックリスト
- 対象キューの件数が平常範囲へ戻り、増加傾向が止まった
- 最古メッセージのageが縮まり、古いage帯の滞留が解消した
- 流出が流入を上回る排出期間を経て、新着も通常時間で配送されている
- 宛先ドメイン別の偏りと同じ一時エラーの反復が解消した
- 配送期限切れ、破棄、保留、重複再送の件数と対象を確認した
- 重要なトランザクションメールをテストし、受信側の到着まで確認した
- 一時停止した大量配信を段階的に戻し、再滞留がないことを確認した
- 原因、対応時刻、設定変更、影響、再発防止、担当者を記録した
キュー滞留の解消が完了するのは、件数が減った時ではなく、最古メッセージのageが縮まり、新着メールも通常時間で流れ、期限切れと重複再送がないと確認できた時です。
メール送信キュー監視の一次情報
- IETF RFC 5321：SMTPのキューイング、再試行間隔、配送を諦めるまでの期間、同じ利用不能宛先への再試行集中を避ける考え方を確認できます。
- Postfix QSHAPE_README：キューをage帯と宛先・送信者の集中で表示し、active・incoming・deferredの滞留を読む方法を確認できます。
- Postfix postqueue(1)：キュー一覧、JSON出力、再試行要求などpostqueueコマンドの公式仕様を確認できます。
- Microsoft Learn：Exchangeのキュー：MessageCount、IncomingRate、OutgoingRate、Velocity、NextHopDomainなどの意味を確認できます。
- Microsoft Learn：Get-Queue：Transport queueの取得、フィルター、状態確認のコマンド仕様を確認できます。
よくある質問
メール送信キューでは何を監視しますか？
現在件数、queue ageの分布、最古メッセージ、流入・流出速度、宛先ドメイン・次ホップ別の集中、最終SMTP応答、再試行予定、配送期限までの余裕を監視します。件数だけの固定閾値ではなく、平常時の時間帯別ベースラインと複数指標の継続時間で判断します。
queue ageと最古メッセージをどう使い分けますか？
queue ageの分布は、滞留全体が新しい層にあるか、古い層へ移っているかを把握するために使います。最古メッセージは、総件数や平均値に埋もれた取り残しを発見するために使います。分布で全体傾向を見て、最古のキューIDで個別原因を確認します。
再試行中の遅延と配送不能をどう切り分けますか？
一時エラーか恒久エラーかだけでなく、同じ応答の反復時間、宛先別集中、ageの伸び、次回試行、配送期限までの余裕を確認します。一時エラーでも期限へ近づけば重大度を上げ、宛先単位のバックオフを壊さず、DNS、接続、TLS、認証、routing、相手先制限を順に調べます。
キュー滞留を解消したあとに何を確認しますか？
件数だけでなく、最古ageと古いage帯が縮小し、新着メールが通常時間で配送され、特定宛先への偏りがなく、期限切れ・破棄・保留・重複再送がないことを確認します。一時停止した大量配信は段階的に戻し、再滞留を監視します。
deferredキューが大きければ障害ですか？
必ずしも障害ではありません。相手先の一時制限や大規模送信後には増えることがあります。ageの山が古い帯へ移動しているか、特定宛先へ集中しているか、流出が続いているか、最古メッセージが期限へ近づいているかで判断します。
キューを強制的に再送すれば早く復旧しますか？
原因が残ったまま全件を強制再送すると、同じ失敗を繰り返し、相手先のレート制限を悪化させることがあります。原因を修正し、上流投入を制御し、宛先単位のバックオフを尊重したうえで、影響範囲を限定して再試行します。
まとめ
メール送信キューは、未配送件数を数えるだけでは安全に監視できません。queue ageの分布、最古メッセージ、流入・流出速度、宛先別集中、再試行理由、配送期限までの余裕を同じ時系列で見れば、正常な送信バースト、相手先の一時制限、経路障害、排出能力不足、少数メッセージの取り残しを分けやすくなります。
アラート後は、影響範囲を固定し、ageと宛先を集計し、代表キューIDの最終応答を確認し、原因レイヤーを切り分けます。上流投入と再試行を制御し、復旧後は古い滞留と新着メールの両方を確認してください。件数が減ったことではなく、最古age、新着の配送時間、期限切れ、重複再送まで閉じることが、再現可能なキュー監視の完了条件です。
