List-Unsubscribeヘッダーの実装・監視｜ワンクリック配信停止を止めない運用
BtoBメールの本文に「配信停止はこちら」を置いていても、それだけではRFC 8058のワンクリック配信停止にはなりません。受信画面の配信停止機能を動かすには、送信メールへ2つの専用ヘッダーを付け、DKIM署名で保護し、受信側から届くHTTPS POSTを追加操作なしで抑止処理へつなぐ必要があります。
実装後も、配信サービスの切り替え、テンプレート変更、DKIM設定の更新、抑止リスト同期の失敗によって機能が止まることがあります。送信時のヘッダー確認だけで終えず、解除要求の受付、対象リストの特定、抑止反映、次回配信からの除外までを一つの監視対象として扱うことが重要です。
結論として、ワンクリック配信停止は「ヘッダーを付ける機能」ではなく、「受信画面から届く解除要求を、対象リストの送信停止まで閉じる仕組み」です。ワンクリック配信停止の完了は、受信画面にリンクが出た時ではなく、解除要求が抑止リストへ反映され、次の配信対象から確実に除外された時です。
本記事のポイント
- RFC 8058のワンクリック解除には、HTTPS URLを含むList-Unsubscribeと、固定値を持つList-Unsubscribe-Postの両方が必要です。
- 2つの解除ヘッダーを有効なDKIM署名の対象にし、URLには受信者と購読リストを安全に特定できる偽造困難な識別子を持たせます。
- ヘッダー出力率、POST成功率、抑止反映時間、停止後送信件数を継続監視し、配信基盤変更後も実メールで疎通を確認します。
List-Unsubscribeとワンクリック配信停止の違い
List-Unsubscribeは、メーリングリストから解除するためのURLをメールヘッダーに示す仕組みです。RFC 2369では、HTTPSやmailtoなど複数のURLを左から優先順に並べられます。メールソフトはこの情報を使い、本文とは別の共通UIに配信停止操作を表示できます。
ただし、HTTPS URLをList-Unsubscribeに入れただけでは、RFC 8058のワンクリック解除を表しません。迷惑メール検査がヘッダー内URLを自動取得すると、GETだけで解除する実装では本人操作なしの誤解除が起こり得ます。RFC 8058は、受信者の同意を得たメールソフトが専用のHTTPS POSTを送る方法を定め、通常のURL確認と解除実行を区別します。
| 要素 | 役割 | 実装上の要点 | 単独でできないこと |
|---|---|---|---|
| 本文の停止リンク | 設定画面や停止画面へ案内する | 目立つ位置に置き、スマートフォンでも操作しやすくする | RFC 8058のヘッダー要件を代替できない |
| List-Unsubscribe | 解除先URLを受信側へ伝える | ワンクリック用途ではHTTPS URLを少なくとも1つ含める | POSTによるワンクリック対応を単独では宣言できない |
| List-Unsubscribe-Post | POSTでOne-Clickを実行できると示す | 値はList-Unsubscribe=One-Clickに固定する | 解除先URL自体は持たない |
| DKIM署名 | 解除ヘッダーが送信後に改変されていないことを検証する | 2つの解除ヘッダーをh=の署名対象に含める | 抑止リストへの反映までは保証しない |
典型的なヘッダーは次の形です。HTTPS URLには、メールアドレスをそのまま置くのではなく、受信者と購読リストを特定でき、有効期限や署名を検証できる不透明なトークンを使います。
List-Unsubscribe: <mailto:unsubscribe@example.com>,
<https://example.com/unsubscribe/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickRFC 8058では、List-Unsubscribeに1つのHTTPS URIを含め、List-Unsubscribe-Postに固定のキーと値を置き、両ヘッダーを有効なDKIM署名でカバーすることを求めています。解除用POSTはCookieやHTTP認証へ依存せず、リダイレクトを返さない設計にします。受信者のブラウザ履歴やログイン状態に結び付けず、そのメールに埋め込まれた検証可能な識別子だけで処理を完了させます。
Googleの送信者ガイドラインでは、個人用Gmailアカウントへ1日5,000件を超えるメールを送る一括送信者について、マーケティング目的や配信登録されたメールをワンクリックで解除できるようにすることを要件としています。対象はマーケティング・プロモーションメールであり、パスワード再設定や領収書などのトランザクションメールとは分けて扱います。メール種別の境界は、トランザクションメールとマーケティングメールを分離する運用も参考にしてください。
実装前に決める判断表
最初に決めるべきことは、使用する配信ツールの設定画面ではなく、どのメールをどの購読単位から止めるかです。送信者ドメイン単位の「全配信停止」に寄せすぎると、受信者が残したいニュースレターまで止めます。反対にキャンペーン単位へ細分化しすぎると、停止後も似たメールが別リストから届き、受信者の期待を裏切ります。
| 決定項目 | 推奨する決め方 | 記録する値 | 避けたい状態 |
|---|---|---|---|
| 対象メッセージ | マーケティング、プロモーション、定期購読を対象にする | message_type、送信元、テンプレート群 | 取引通知と販促メールを同じ判定にする |
| 購読単位 | 受信者が内容の違いを理解できるリスト単位にする | list_id、表示名、Fromアドレス | キャンペーンごとに別リストを乱造する |
| 受信者識別 | メールアドレス直書きではなく署名付きの不透明トークンを使う | contact_id、list_id、発行時刻、署名版 | 推測可能な連番や平文アドレスだけで解除する |
| 解除の正本 | 全送信経路が参照する抑止台帳を一つ決める | 状態、受付時刻、受付経路、対象範囲 | MA、CRM、配信サービスごとに停止状態が分かれる |
| 反映目標 | 受付直後から送信前ゲートで止め、48時間を上限として監視する | 受付時刻、正本反映時刻、各基盤反映時刻 | 夜間バッチが終わるまで送信を続ける |
| 再購読 | 本人の明示操作と新しい同意記録を要求する | 再購読時刻、経路、対象リスト | CSV取込や担当者更新で停止履歴を上書きする |
プリファレンスセンターとワンクリック解除は競合しません。ワンクリック解除は、そのメールに関連付くリストから追加操作なしで外すための経路です。テーマや頻度を細かく選ぶ画面は別に提供できますが、設定画面への遷移だけでワンクリック要件を満たしたことにはなりません。役割分担は、メール配信プリファレンスセンターの設計で詳しく整理しています。
7ステップで実装と検証を進める
- 対象メールと購読リストを棚卸しする
MA、CRM、メール配信サービス、フォーム、営業担当の個別配信を含め、マーケティングメールを送る経路を列挙します。各テンプレートにmessage_typeとlist_idを割り当て、トランザクションメールと混在していないか確認します。 - 解除トークンと期限を設計する
トークンには受信者と購読リストを特定できる情報を持たせ、署名または十分に推測困難な値で偽造を防ぎます。URL、アプリケーションログ、分析基盤へメールアドレスを平文で残さない設計にし、鍵の版と失効条件も決めます。 - 2つのヘッダーを生成する
List-UnsubscribeへHTTPS URLを入れ、必要ならmailtoを併記します。List-Unsubscribe-Postには正確にList-Unsubscribe=One-Clickを設定します。テンプレート単位の手入力ではなく、対象メールへ共通処理で付与します。 - DKIM署名の対象を確認する
有効なDKIM署名のh=に、list-unsubscribeとlist-unsubscribe-postが含まれることを実メールで確認します。配信サービスによってはヘッダー追加と署名の順序が異なるため、管理画面の設定だけで判断しません。鍵更新を予定している場合は、DKIMセレクタと署名鍵のローテーション手順も合わせて確認します。 - HTTPS POSTを冪等に受け付ける
本文がList-Unsubscribe=One-ClickのPOSTを受け、Cookie、ログイン、確認画面なしで解除します。同じ要求が複数回来ても最初の解除時刻を保ち、成功として扱える冪等な処理にします。RFC 8058ではHTTPSリダイレクトを返さないことが求められるため、最終エンドポイントをヘッダーへ直接設定します。 - 抑止台帳と送信前ゲートへ反映する
解除イベントを正本へ記録し、MA、CRM、配信基盤へ同期します。同期完了を待つ間も送信前ゲートでは即時除外し、古いCSVや過去キャンペーンへの再追加で停止状態が戻らないよう、より制限の強い状態を優先します。 - 外部受信箱と次回配信で閉ループ検証する
Gmailなどの外部受信箱へテスト送信し、元メール、DKIM署名、解除POST、抑止記録、次のテスト配信での除外までを同じcontact_idとlist_idで追います。表示有無だけではなく、停止後送信が0件であることを合格条件にします。
解除URLをブラウザで開くだけの試験は、ワンクリックPOSTの試験になりません。また、実在受信者のURLを監視ツールから定期的にGETすると、意図しないアクセスやログ漏えいにつながります。監視専用のテスト購読者とリストを用意し、制御されたPOSTと次回送信除外を確認してください。
表示されない・解除されない原因と監視方法
Gmailなどの受信画面に配信停止が表示されるかどうかは、ヘッダーだけでなく認証、送信者の評価、メッセージ種別など複数要因で決まります。そのため「UIに出たか」だけをSLAにせず、自社が制御できる実装条件と解除処理を直接監視します。
| 症状 | 主な確認点 | 調査方法 | 復旧の優先順位 |
|---|---|---|---|
| 受信画面に解除が出ない | 2ヘッダー欠落、HTTPS URL欠落、DKIM対象外、認証不合格 | 外部受信メールのraw headerとAuthentication-Resultsを確認 | 生成処理と署名順序を修正して再送する |
| POSTが届かない | 古いURL、DNS・TLS障害、WAF遮断、リダイレクト | 監視用トークンで最終URLへPOSTし、到達ログを確認 | 受信経路を復旧し、旧URLも必要期間維持する |
| POSTは2xxだが再送される | 正本未反映、同期遅延、送信前照合漏れ、別リスト | 受付時刻から抑止台帳、抽出結果、送信ログを追跡 | 対象を即時抑止し、全送信経路を突合する |
| 別の購読まで止まる | list_id欠落、全停止との混同、連絡先単位の一括更新 | URLトークンと解除イベントの対象リストを確認 | 影響範囲を特定し、本人意思を推測で戻さない |
| 配信サービス変更後に失敗 | ヘッダー仕様差、DKIM署名順序、抑止台帳の移行漏れ | 新旧基盤から同条件でテスト送信し、差分を比較 | 新規送信を保留し、停止履歴と経路を先に復旧する |
最低限の監視指標は、対象メールに2つのヘッダーが付いた割合、DKIM署名で両ヘッダーをカバーした割合、解除POSTの2xx率、受付から正本反映までの時間、各配信基盤への同期遅延、停止後送信件数です。解除件数が急に0になった場合も「人気が上がった」と判断せず、ヘッダー欠落や受信経路停止を疑います。
日次の自動検査に加え、配信サービス、送信ドメイン、DKIM鍵、テンプレートエンジン、解除ドメイン、WAFを変更したときは、監視用購読者で閉ループテストを実行します。解除後に送信されたメールが1件でもあれば、到達率の問題としてではなく、抑止違反として送信経路を止めて調べます。メール到達率の異常が併発している場合は、送信元がブロックリストに載ったときの対応も確認してください。
よくある質問
List-UnsubscribeとList-Unsubscribe-Postは何が違いますか？
List-Unsubscribeは解除先のURLを示し、List-Unsubscribe-Postは、そのHTTPS URLへRFC 8058のワンクリックPOSTを送れることを示します。ワンクリック対応では両方を使い、両ヘッダーを有効なDKIM署名で保護します。
ワンクリック配信停止のHTTPSエンドポイントはどう実装しますか？
受信者と購読リストを特定できる偽造困難なトークンをURLに持たせ、List-Unsubscribe=One-ClickのPOSTをCookieやログインなしで受けます。同じ要求を複数回受けても安全な冪等処理にし、リダイレクトせず、対象リストの抑止へ直接反映します。
Gmailなどの受信画面に配信停止が表示されないとき何を確認しますか？
2つの解除ヘッダー、List-Unsubscribe内のHTTPS URL、DKIM署名のh=対象、DKIM・SPF・DMARCの結果、メッセージがマーケティング用途として分離されているかを確認します。表示可否だけでなく、raw headerと解除POSTの疎通を直接検証します。
配信サービス変更後も解除処理が機能していることをどう監視しますか？
監視専用の購読者とリストを用意し、新基盤から送信、raw header確認、解除POST、抑止台帳反映、次回送信除外までを一連で試験します。対象メールのヘッダー付与率、POST成功率、反映時間、停止後送信件数も継続監視します。
mailtoリンクだけでワンクリック配信停止の要件を満たせますか？
満たせません。mailtoはList-Unsubscribeの代替手段として併記できますが、RFC 8058のワンクリック要件にはHTTPS URLとList-Unsubscribe-Postが必要です。本文内の停止リンクや設定画面へのリンクも同様に代替にはなりません。
解除要求はどのくらいで反映すべきですか？
受付直後から送信前ゲートで除外する設計が安全です。Googleは登録解除リクエストを48時間以内に処理するよう案内していますが、48時間ぎりぎりまで送信してよいという意味ではありません。正本と全配信基盤への反映時間を測り、遅延時は送信を保留します。
公式仕様で確認できる実装条件
- IETF RFC 2369は、List-Unsubscribeを含むメーリングリスト用ヘッダーフィールドの構文、複数URLの優先順、URLを山括弧で囲む形式を定めています。
- IETF RFC 8058は、HTTPS POST、List-Unsubscribe-Postの固定値、DKIM署名対象、Cookie・認証への非依存、リダイレクト禁止を定めています。
- Googleのメール送信者ガイドラインは、一括送信者のマーケティング・配信登録メールにおけるワンクリック解除と本文内解除リンクの要件を案内しています。
- Googleの配信登録メッセージ向けガイドラインは、定期購読メッセージの範囲、48時間以内の処理、購読リストの識別、非購読メッセージとの分離を案内しています。
- Googleの送信者ガイドラインFAQは、本文リンクや設定ページだけではRFC 8058の代替にならないこと、ワンクリック解除が関連する購読リスト単位であることを説明しています。
