RFC8058 One-Click Unsubscribe 設定
目次
この記事でわかること
- One-Click Unsubscribe を構成する 2 種類のヘッダ（RFC 2369 と RFC 8058）の役割
- ヘッダの正しい書き方と、受信側がどのように動作するか
- POST エンドポイントを自社で実装するときの 4 つの注意点
- SendGrid・Mailchimp・HubSpot などツール側で対応している場合の確認ポイント
なぜ今「One-Click 解除」が必須なのか
「メルマガを配信したら Gmail に届かなくなった」「Yahoo 宛だけスパム判定が増えた」——2024 年 6 月以降こうした相談が増えています。背景は Google と Yahoo の共同送信者要件です。1 日 5,000 通以上の送信者には、SPF・DKIM・DMARC に加えて One-Click Unsubscribe（ワンクリック解除）への対応 が求められるようになりました。
技術仕様としては RFC 8058 が定める List-Unsubscribe-Post ヘッダの実装を意味します。配信量が要件に届かないサイト運営者でも、Gmail の到達性スコアに影響するため備えておきたい項目です。Gmail 全体の要件はGoogle 送信者要件 2024 年版の対応ポイントも併せて確認してください。
必要なヘッダは「2 行」セット
One-Click Unsubscribe は、新旧 2 つの RFC が組み合わさった仕組みです。古い List-Unsubscribe（RFC 2369）だけでは要件を満たさず、List-Unsubscribe-Post（RFC 8058）を追加することで初めて「ワンクリック解除」として認識されます。
1 行目: List-Unsubscribe（RFC 2369）
URL とメールアドレスの 2 つを併記するのが標準です。
List-Unsubscribe: <https://example.com/unsubscribe?u=abc123>,
<mailto:[email protected]>
URL 側は HTTPS、メール側は実在のメールボックスを指す必要があります。u=abc123 は受信者を一意に識別するトークンで、推測困難な値（16 文字以上のランダム文字列）にしてください。
2 行目: List-Unsubscribe-Post（RFC 8058）
このヘッダが追加されることで、受信メールサーバーは「URL に POST リクエストを送れば自動解除できる」と判断します。
List-Unsubscribe-Post: List-Unsubscribe=One-Click
値は固定文字列の List-Unsubscribe=One-Click です。改変や省略は許されません。
GET と POST の挙動の違い
旧来方式（GET）と RFC 8058 方式（POST）では、受信者の操作も処理フローも異なります。
GET 方式では、受信者が解除リンクをクリックするとブラウザで URL が開きます。確認画面・ログイン要求・ボタン再クリックが挟まれるのが一般的でした。これが「解除したいのに解除できない」苦情の主因となり、迷惑メール報告ボタンが押される原因にもなります。
POST 方式では、Gmail や Yahoo メールの上部に表示される「メーリングリストの登録解除」ボタン 1 回で完結します。受信メールサーバーが裏側で List-Unsubscribe=One-Click をボディに含めた POST リクエストを送り、送信側はそれを速やかに処理して 200 OK を返すだけ、という設計です。RFC 8058 は応答を「reasonably promptly」と規定しており、明確な秒数は定めていませんが、タイムアウトすると受信側が解除失敗と判断するため、応答は短く保つ実装が現実的です。
POST エンドポイントを自社実装するときの注意
メール送信ツールを使わず自前のシステムから配信している場合、以下 4 点を必ず守ってください。
1. GET ではなく POST で受け付ける
エンドポイントは POST メソッド前提で実装します。GET でも解除できる別実装を残すこと自体は許可されていますが、メインの解除処理は POST で完結させる必要があります。Method Not Allowed を返すと要件未達と判定されます。
2. 認証なしで処理する
ログイン要求、CAPTCHA、確認画面、メールアドレスの再入力。これらをすべて挟んではいけません。受信メールサーバーは認証情報を持たずに POST してくるため、URL に埋め込まれたトークンだけで本人確認を完結させる設計が必須です。
3. レスポンスは速やかに 200 を返す
RFC 8058 は明確な秒数を規定していませんが「reasonably promptly」とされています。DB 書き込みや外部サービス連携は非同期キューに逃がし、エンドポイント自体は即座に 200 を返すのが安全です。タイムアウトすると一部の受信側が「解除失敗」と判断します。
4. URL のトークンは推測困難に
?u=12345 のような連番 ID は、第三者が他人を勝手に解除できてしまいます。ランダム値を発行して管理してください。
メール送信ツール側で対応しているか確認する
自前実装を避けたい場合、主要なメール送信ツールはすでに One-Click Unsubscribe に対応しています。それぞれの確認方法を整理しました。
SendGrid
トラッキング設定の「Subscription Tracking」を有効化し、Subscription Tracking の「Replace tag」に専用タグが入っていれば自動でヘッダが付与されます。Marketing Campaigns 経由の配信は標準で有効です。
Mailchimp
通常のキャンペーン送信では自動付与されます。Mandrill（API 送信）を使う場合は、メタデータに List-Unsubscribe を明示設定し、送信ログのヘッダ欄で 2 行揃っているか確認してください。
HubSpot
マーケティングメールは標準対応。トランザクション拡張を使う場合のみ、サブスクリプション管理を有効化します。
自社配信か外部か迷ったら
実際に自分宛にテスト送信し、受信メールの「ソースを表示」で List-Unsubscribe-Post: List-Unsubscribe=One-Click の行があるか目視で確認するのが最短です。メーリングリストや CRM・CMS の通知機能から大量に送っているケースでは、対応していないシステムが意外と多い点に注意してください。
DMARC とセットで運用する
One-Click Unsubscribe は到達性向上の必須項目ですが、なりすまし対策の本丸は DMARC です。Google・Yahoo の送信者要件では、p=none 以上の DMARC ポリシーも併せて求められています。設定方法はDMARC 設定方法を徹底解説、義務化の背景はDMARC 義務化の流れと対応スケジュールを参照してください。
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。