## この記事でわかること - 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 年版の対応ポイント](/blog/google-sender-requirements-2024)も併せて確認してください。 ## 必要なヘッダは「2 行」セット One-Click Unsubscribe は、新旧 2 つの RFC が組み合わさった仕組みです。古い `List-Unsubscribe`（RFC 2369）だけでは要件を満たさず、`List-Unsubscribe-Post`（RFC 8058）を追加することで初めて「ワンクリック解除」として認識されます。 ![List-Unsubscribe ヘッダの 2 行構造](/blog/one-click-unsubscribe-setup/list-unsubscribe-headers.svg) ### 1 行目: List-Unsubscribe（RFC 2369） URL とメールアドレスの 2 つを併記するのが標準です。 ``` List-Unsubscribe: , ``` 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 と POST の処理フロー比較](/blog/one-click-unsubscribe-setup/get-vs-post-flow.svg) 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 設定方法を徹底解説](/blog/dmarc-setup-guide)、義務化の背景は[DMARC 義務化の流れと対応スケジュール](/blog/dmarc-mandatory)を参照してください。 ## 自社の状況を確認してみませんか 設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。