Cloudflare Email Serviceの送信結果を、pollingや個別callbackではなくQueuesへ流せるようになった。deliveredだけを見るのでは不十分で、deferredを一時状態、bouncedやcomplainedを配信停止判断へ結び付ける必要がある。event-driven化により送信処理と配信後処理を分離できるが、同一イベントの再配信、順序、個人情報を前提にconsumerを設計する必要がある。

何が変わったか

Email SendingをsourceとするQueues event subscriptionが追加された。公開されるevent typeはmessage.delivered、message.deferred、message.bounced、message.failed、message.rejected、message.complainedの6種である。subscriptionはzone apexまたは検証済みsending subdomainの一つへscopeされ、eventにはmessage details、delivery status、SMTP responseが含まれる。Email Routingの受信イベントは対象外である。

変更前後の差

従来、送信APIの受理結果だけでは最終配送、恒久bounce、complaintを同じ処理で扱えなかった。新機能では送信後の状態をQueue consumerで処理し、再試行、suppression list、運用通知、分析へ分岐できる。送信requestの同期応答を長く待つ必要もない。

誰に影響するか

認証メール、請求通知、Agent実行完了、障害通知などをCloudflareから送るサービスが対象となる。複数sending domainを使う場合はdomainごとのsubscription、consumer、データ保持方針を決める。受信Email Routingのイベントも同じsourceから来ると想定してはいけない。

期限

導入期限はない。まず観測専用consumerでeventを保存し、実データの重複、順序、遅延、SMTP code分布を確認してから自動suppressionや再送を有効化する。

必要な対応

message IDなどから冪等keyを作り、同じeventを複数回処理しても副作用が増えないようにする。terminalとstatusを組み合わせ、deferredを即時永久失敗にしない。complaintと恒久bounceは送信停止候補として扱い、誤解除を防ぐ承認または期限付きpolicyを設ける。

実装・移行手順

  1. sending domainと用途を一覧化する
  2. domainごとにQueues event subscriptionを作成する
  3. consumerでraw eventを短期間保存しschemaを検証する
  4. message IDを使った冪等処理を実装する
  5. delivered、temporary、permanent、complaintへ状態を正規化する
  6. retry、suppression、通知を別Queueまたはworkflowへ分離する
  7. 個人情報をmaskした指標をdashboardへ出す
  8. replay test後に自動処理を段階的に有効化する

失敗しやすい点

APIがemailを受理した時点をdeliveredとみなす、deferredを永久bounceとして停止する、SMTP textだけを文字列一致で分類する、複数domainを一つのsubscriptionで扱えると想定する、Email Routingの受信eventも含まれると誤解する、といった問題がある。Queueの再試行でsuppression登録や通知が重複しないようにする。

リスク

recipientやSMTP responseには個人情報・運用情報が含まれ得る。raw eventの長期保存、広い閲覧権限、外部observabilityへの無加工転送は避ける。誤った自動再送はreputationを悪化させ、誤ったsuppressionは重要通知を止めるため、安全側の上限とmanual overrideを設ける。

評価方法

  • delivered、deferred、bounce、complaint率
  • event受信遅延のP95
  • duplicate event率
  • retry後成功率
  • suppression誤登録・解除件数
  • send requestからterminal eventまでの時間
  • consumerのdead-letter件数

ロールバック

subscriptionまたはconsumerの自動actionを無効化し、観測専用へ戻す。送信経路自体は維持し、event処理の障害がメール送信を止めない構成にする。誤ったsuppressionは変更履歴から戻せるよう、追加理由と元eventを保存する。

編集部分析

メール運用で重要なのは「送れたか」ではなく「受信側でどう終わったか」である。Queues統合はその差をCloudflare内で扱いやすくする。最初から自動再送を作るより、event taxonomyとterminal判定を安定させることが先である。

実務チェックリスト

  • [ ] sending domainごとのsubscriptionを設計した
  • [ ] 6種のeventを正規化した
  • [ ] 冪等keyと重複処理を実装した
  • [ ] deferredとpermanent failureを分けた
  • [ ] recipient情報の保存・閲覧を制限した
  • [ ] suppressionとretryに上限を設けた
  • [ ] 自動actionを停止できるようにした

一次情報