配信停止の導線は、法的な義務であると同時に到達率を守るための実務上の要です。ここでは List-Unsubscribe ヘッダの仕組みと、実装で必ず踏む落とし穴を整理します。

なぜヘッダに書くのか

配信停止のリンクは本文にも書きます。ではなぜヘッダにも書くのか。理由はメールソフト側にボタンを出させるためです。

導線受信者の手間選ばれやすさ
本文のリンクを探す本文を下までスクロールして探す低い
メールソフトのボタン画面上部のボタンを押す高い
迷惑メールを報告ボタンを押す（同じ手間）高い

3行目が競合相手です。「配信停止」と「迷惑メール報告」が同じ手間なら、どちらを押されても不思議はありません。ヘッダを入れて配信停止ボタンを出させることは、報告ボタンに流れる分を引き取る作業です。

ヘッダ中身役割
List-Unsubscribe停止用のURL（またはmailtoアドレス）を山括弧で囲んで記述停止先の指定
List-Unsubscribe-PostList-Unsubscribe=One-Click確認を挟まずPOSTで実行してよいと宣言

2つ目が RFC 8058 で定義されたワンクリック配信停止です。これを併記すると、メールソフトは受信者が停止ボタンを押した時点で、指定URLにPOSTリクエストを送ります。受信者はページを開く必要すらありません。

最大の落とし穴 ― GETで停止させてはいけない

実装でもっとも危険なのがここです。配信停止URLをGETで開いた時点で停止を実行する作りにすると、本人が読む前に停止されます。

本人より先にURLを開くものタイミング
メールソフトのリンクプレビュー受信時
企業のメールセキュリティ製品（リンク検査）受信直後
ウイルス対策ソフト・社内プロキシ受信時
各種のクローラ不定

この結果、送った直後に見込み客が「配信停止済み」になり、以後永久に接触できなくなります。しかも配信停止は正常な動作として記録されるため、異常として気づけません。リストが黙って減っていきます。

正しい実装は次のとおりです。

  1. POSTだけが停止を実行する
  2. GETでアクセスされた場合は、押すものが1つだけのページを表示する（確認ダイアログは挟まない）
  3. そのボタンはPOSTで送信する
  4. RFC 8058 のPOST（メールソフトが送るもの）は本文を返さず200を返す

これで規格どおりのワンクリックを保ちながら、機械の先読みによる誤停止を防げます。

確認画面を挟まない理由

「本当に停止しますか？」という確認を挟みたくなりますが、これは逆効果です。

止め方都合が悪い受信者の行動
確認を何度も挟む／理由の入力を求めるやめて迷惑メール報告に回る
ボタン1つで完了停止して終わる

止めにくくして減らせるのは配信停止の件数だけで、止めたいという意思は減りません。行き先が苦情に変わるだけです。

停止の処理は即座に、横断で

停止を受けたら、その宛先へは以後送りません。実装上の要点は2つです。

要点理由
即座に反映する次の配信までに反映されないと同じ相手に届く
案件・クライアント横断で1つのリストにする別案件のリストに同じアドレスがあると再送してしまう

特定電子メール法は、受信拒否の意思表示があった者への送信を禁じています（同法3条3項）。「別の案件だったので」は理由になりません。

また、停止の意思は配信停止ボタン以外の形でも来ます。次はすべて同じ扱いにします。

  • 「配信不要」「今後の連絡は不要」といった返信
  • 電話での拒否
  • フォーム経由での拒否

表示義務との関係

ヘッダを入れても、本文の表示義務は消えません。特定電子メール法4条は次の表示を求めています。

  • 送信者の氏名または名称
  • 受信拒否の通知を受けるための連絡先（URLまたはメールアドレス）
  • 送信者の住所
  • 問い合わせ等を受け付ける連絡先

つまりヘッダは実務上の工夫、本文の表示は法的な要件です。両方を入れます。

まとめ

  • ヘッダに書くのは、メールソフト側に配信停止ボタンを出させるため。競合相手は「迷惑メール報告」ボタン
  • List-Unsubscribe と List-Unsubscribe-Post の2つで RFC 8058 のワンクリックになる
  • 🔴 GETで停止を実行してはいけない。機械が本人より先に踏み、見込み客が黙って消える
  • GETは押すものが1つだけのページ、実行はPOST。確認は挟まない
  • 停止は即座に反映し、案件横断で1つのリストに入れる
  • ヘッダは工夫、本文の表示は義務。両方入れる

出典