List-Unsubscribeとは？ヘッダの記述例とRFC 8058準拠の実装手順を解説

「List-Unsubscribeを設定してください」と言われたものの、具体的に何をどこに書けばいいのか分からない。メール配信システムの設定画面にそれらしい項目がない。ヘッダを追加したはずなのに、Gmailに「登録解除」リンクが表示されない。

メール配信の担当者やシステム開発者から、こうした相談が当社にも寄せられています。背景にあるのは、Gmail・Yahoo!メール・Microsoft Outlookが相次いで打ち出した送信者要件です。1日5,000通以上のマーケティングメールを送る事業者にとって、List-Unsubscribeへの対応はもはや「やったほうがいい施策」ではなく、メールを届けるための前提条件になりました。

この記事では、List-Unsubscribeというヘッダそのものの仕様を、RFC 2369とRFC 8058の定義に沿って整理します。httpsとmailtoの使い分け、そのままコピーして使える記述例、ワンクリック解除が成立するために満たすべき条件、実装後の確認手順、そして実務でつまずきやすい落とし穴まで。技術要件を正確に押さえたい担当者向けの実装ガイドです。

List-Unsubscribeとは？メールヘッダで配信解除の導線を提供する仕組み

List-Unsubscribeとは、メールのヘッダ領域に記述することで、受信者がメールソフトの画面上から直接配信解除できるようにするヘッダフィールドです。 日本語では「登録解除」と訳されます。

このヘッダが付与されたメールをGmailで開くと、送信者名の横に「メーリングリストの登録解除」というリンクが表示されます。受信者はこれをクリックするだけで購読を停止できます。

重要なのは、List-Unsubscribeが「本文」ではなく「ヘッダ」の話であるという点です。ヘッダはメール本文の上部に付随する制御情報の集まりで、通常は受信者の目に触れません。SubjectやFrom、DKIM-Signatureなどと同じ領域に、解除用の情報を書き込む。これがList-Unsubscribeの正体です。

メール本文の「配信停止リンク」との決定的な違い

多くのメルマガには、フッターに「配信停止はこちら」というリンクが設置されています。これは特定電子メール法が求める受信拒否の意思表示先の表示にあたるもので、法律上必要な措置です。しかし、本文のリンクを設置しただけでは、Gmailなどが求めるワンクリック解除の要件を満たしません。 両者は別物です。

法律とガイドラインは別の軸で動いています。Gmailの要件を満たしていても法令上の表示義務は免除されず、法令を守っていてもガイドライン未対応ならメールは届きません。両方に対応する必要があります。

関連記事：メルマガの「オプトアウト」とは？特定電子メール法に基づく書き方と解除URLの設定ガイド

RFC 2369とRFC 8058。2つの仕様の関係を整理する

List-Unsubscribeを正しく理解するには、2つのRFC（インターネット技術の標準仕様書）の関係を押さえる必要があります。

RFC 2369（1998年）は、List-Unsubscribeヘッダそのものを定義した仕様です。メーリングリストの購読解除先として、mailto形式のメールアドレスやURLを指定できる、という枠組みを定めました。ただしこの時点では「解除ページへ案内する」程度の位置づけで、ワンクリックで完結する仕組みではありませんでした。

RFC 8058（2017年）は、そこに「ワンクリック」の概念を追加した仕様です。正式名称は「Signaling One-Click Functionality for List Email Headers」。List-Unsubscribe-Postという新しいヘッダをセットで送ることで、メールソフトがURLへPOSTリクエストを送り、その場で解除を完了させる動作を定義しました。

つまり、List-Unsubscribeヘッダだけを書いてもRFC 8058のワンクリック解除にはなりません。 GmailやOutlookが求めているのは後者です。この区別が、実装でつまずく最初のポイントになります。

送信者側にとってのメリットは「迷惑メール報告の回避」

List-Unsubscribeは受信者のための機能に見えますが、実際に最も恩恵を受けるのは送信者です。

不要なメールを止めたい受信者が取れる行動は2つあります。配信解除するか、「迷惑メールを報告」ボタンを押すか。解除の導線が見つけにくいほど、スパム報告が選ばれやすくなります。

スパム報告は送信ドメインとIPアドレスのレピュテーション（送信者評価）を直接的に押し下げます。Googleは迷惑メール報告率0.3%未満の維持を求めており、この水準を超えると、解除していない読者に対してもメールが迷惑メールフォルダへ振り分けられるようになります。

100人の不満を持つ読者がいたとして、全員が解除リンクを押せば損失はリスト100件。全員がスパム報告を押せば、リスト全体の到達率が損なわれます。目立つ場所に解除ボタンを置くことは、リストを減らす施策ではなく、リスト全体を守る施策だと捉えるべきです。

List-Unsubscribeが必須化された背景と、各社の要件

対応を急ぐべき理由は、主要な受信側プロバイダが要件として明文化したことにあります。時系列で整理します。

Gmail・Yahoo!メールの送信者ガイドライン（2024年2月〜）

GoogleとYahoo!は2023年10月に新しい送信者要件を発表し、2024年2月から段階的に適用を開始しました。個人向けGmailアカウント宛に1日5,000通以上を送る送信者に対して、以下が求められます。

このうち最後の2項目がList-Unsubscribeに関わる部分です。なお、パスワード再設定通知や購入確認といったトランザクションメールは、この要件の対象外とされています。

関連記事：【2026年版】Gmailガイドライン完全ガイド｜SPF・DKIM・DMARCと5,000通ルールを解説

Microsoft Outlookの送信者要件（2025年5月5日〜）

Microsoftも同様の要件を導入しました。Outlook.com、Hotmail.com、Live.comなどのMicrosoft系ドメイン宛に1日5,000通以上を送る送信者が対象で、2025年5月5日から適用されています。

必須要件はSPF・DKIM・DMARCの設定で、DMARCは最低でも p=none を設定し、SPFまたはDKIMとアライメントしている必要があります。要件を満たさないメールは迷惑メールフォルダへの振り分けや受信拒否の対象となり、運用は段階的に強化されています。

ここで注意したいのは、MicrosoftはGoogleやYahoo!と違い、RFC 8058のワンクリック解除までは義務化していないという点です。配信停止については「分かりやすく機能する配信停止手段を提供すること」がベストプラクティスとして挙げられている位置づけになります。

とはいえ、認証要件を満たさなければList-Unsubscribe以前にメールが届きません。自社リストにMicrosoft系ドメインがどれだけ含まれているか、一度集計しておくことをおすすめします。

3社の要件を「必須」と「推奨」で切り分けて整理する

同じ「1日5,000通以上」でも、求められる水準は各社で揃っていません。横並びで理解すると誤りやすい部分なので、配信停止まわりに絞って整理します。

List-Unsubscribeの実装を必須要件として求めているのは、GmailとYahoo!メールです。 Microsoftは認証要件を厳格化する一方、解除手段については推奨にとどめています。ただし、GmailとYahoo!の要件を満たしていればMicrosoftの推奨事項も自然に満たせるため、実務上は3社まとめて対応するのが効率的です。

5,000通未満なら対応不要、とは言い切れない

各社とも「1日5,000通以上」という線引きを示していますが、これはあくまで必須要件が適用される閾値です。

Microsoftは公式FAQで、まず大規模送信者を対象とするものの、これらのベストプラクティスはすべての送信者に利益があるとの見解を示しています。将来的に閾値が引き下げられる可能性もあります。

また、5,000通という基準は「1日あたり」であり、日々の配信量が変動する事業者にとっては境界が曖昧です。閾値の内外を気にするより、対応してしまったほうが運用コストは低いというのが実務上の結論になります。

List-Unsubscribeヘッダの記述例。httpsとmailtoの使い分け

ここからは具体的な記述方法です。List-Unsubscribeヘッダには、解除リクエストの受け付け方法として「https」と「mailto」の2種類を指定できます。

httpsを指定する場合（RFC 8058のワンクリック解除）

現在の要件を満たすうえで必須となるのが、https URIの指定です。List-Unsubscribe-Postヘッダとセットで記述します。

List-Unsubscribe: <https://example.com/unsubscribe?token=a1b2c3d4e5f6>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

受信者が解除リンクをクリックすると、メールソフトが指定URLに対して以下のようなPOSTリクエストを送信します。

POST /unsubscribe?token=a1b2c3d4e5f6 HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click

このリクエストを受け取ったサーバー側で、tokenから受信者を特定し、配信リストから除外する。ここまでが送信者側の実装範囲です。

mailtoを指定する場合

mailtoは、解除依頼をメールで受け付ける方式です。受信者がリンクをクリックすると、指定アドレス宛に解除依頼メールが送信されます。

List-Unsubscribe: <mailto:unsubscribe@example.com?subject=unsubscribe>

歴史的にはこちらが先に普及した方式ですが、mailtoのみの指定ではRFC 8058のワンクリック解除として扱われません。 GmailやOutlookの要件も満たせないため、これ単独での運用は避けてください。

httpsとmailtoを併記する場合

両方を記述することも可能です。カンマで区切って並べます。

List-Unsubscribe: <mailto:unsubscribe@example.com?subject=unsubscribe>, <https://example.com/unsubscribe?token=a1b2c3d4e5f6>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

かつては、https URIを解釈せずmailtoしか扱わないメールソフトも存在したため、併記が安全策とされてきました。現在も互換性を重視するなら併記は有効ですが、mailto宛に届いた解除依頼を人手で処理する運用が残る点には注意が必要です。処理体制がないなら、httpsのみに絞ったほうが取りこぼしは起きません。

なお、RFC 8058の仕様上、List-Unsubscribe-Postが付与されていてもhttps URIが含まれていなければ、ワンクリック解除としては動作せず、従来のRFC 2369の挙動にフォールバックします。

ワンクリック解除が成立するための5つの条件

ヘッダを2行追加すれば動く、というものではありません。RFC 8058が「MUST（必須）」「SHOULD（推奨）」として定めている条件を整理します。

List-Unsubscribeにhttps URIを1つ含める

RFC 8058は、List-Unsubscribeヘッダに1つのHTTPS URIを含めることを必須としています。mailtoなど他のスキームを追加することは任意です。httpではなくhttpsである点にも注意してください。

List-Unsubscribe-Postの値は固定文字列

List-Unsubscribe-Postヘッダには、List-Unsubscribe=One-Click というキーと値のペアを1つだけ記述します。この文字列は完全に固定で、独自のパラメータを追加したり表記を変えたりすると仕様違反になります。

両ヘッダをDKIM署名の対象に含める

見落とされやすいのがこの条件です。RFC 8058は、メッセージが有効なDKIM署名を持ち、その署名が最低限List-UnsubscribeヘッダとList-Unsubscribe-Postヘッダをカバーしていることを求めています。

ヘッダは経路上で第三者が書き換えられる領域です。署名の対象外だと、悪意ある第三者が解除URLをすり替えられてしまう。だからこそ署名でカバーする必要があります。

自社のメールサーバーやリレーサービスでDKIM署名を行っている場合、署名対象ヘッダ（h=タグ）にList-Unsubscribeが含まれているかを確認してください。ヘッダを追加しただけで署名設定を見直していないケースは珍しくありません。

URIに推測困難な識別子を含める

RFC 8058は、POSTリクエストを受けるサーバーが送信元を判別できないことを前提に、URIへ不透明な識別子や偽造困難な要素を含めることを推奨しています。

?email=user@example.com のように解除対象をそのまま埋め込む実装は避けてください。第三者がメールアドレスを差し替えるだけで、任意の相手を勝手に解除できてしまいます。ハッシュ値や署名付きトークンなど、推測・改ざんができない値を使ってください。

POSTを受け取り解除処理を行うエンドポイントを用意する

ヘッダを書いても、リクエストの受け皿がなければ何も起きません。POSTリクエストを受理し、識別子から購読者を特定し、配信対象から除外するまでの一連の処理を実装する必要があります。

Googleは解除リクエストを2日以内に処理することを求めています。手作業での運用は現実的ではなく、自動で除外まで完結する仕組みが前提です。

主要メールソフトの対応状況と、受信者からの見え方

実装が正しくても、受信者が使うメールソフトの挙動によって見え方は変わります。

Gmail は、送信者名の横に「メーリングリストの登録解除」リンクを表示します。クリックすると確認ポップアップが出て、承認すると解除が完了します。ただし、Googleは送信者の適格性を独自に審査しており、ヘッダが正しくても表示されないことがあります。送信量の急増や迷惑メール報告率の高さは、表示可否の判断材料になります。

Yahoo!メール（米国Yahoo!）もList-Unsubscribeヘッダをサポートしています。Googleと歩調を合わせた送信者要件を打ち出しており、迷惑メール報告率の閾値も同水準の0.3%が示されています。なお、Yahoo! JAPANは独自のガイドラインを公開しているため、国内向けの配信では別途確認が必要です。

Microsoft Outlook も解除導線の表示に対応しています。前述のとおりRFC 8058のワンクリック解除は義務化されていませんが、Web版・アプリ版いずれも配信停止の導線を提示します。

Apple Mail（iOS/macOS） も解除リンクの表示に対応しています。メール上部に配信停止の案内が表示される形式です。

いずれのメールソフトでも共通するのは、表示位置や文言を送信者側で指定できないという点です。「登録解除」というリンクの文言を変えたい、といった要望には応えられません。

実装後に必ず行う確認手順

設定したつもりで動いていない、というケースが最も厄介です。実際に配信されたメールのソースを確認するのが確実です。

Gmailの「原文を表示」でヘッダを確認する

チェックすべき項目

表示されたソースコードに対して、検索機能（Ctrl+F / Command+F）で以下を確認します。

特に4番目のDKIM署名対象の確認は忘れられがちです。 ヘッダの存在確認だけで終わらせないでください。

解除リンクが表示されないときに考えられる原因

ヘッダを正しく実装したのにGmailにリンクが出ない場合、次の順で切り分けます。

まずList-Unsubscribe-Postヘッダの記述漏れを確認し、次にDKIM署名の対象に含まれているかを確認します。それでも解決しなければ、送信者評価の問題を疑います。Googleは要件を満たした送信者のメッセージにのみ解除リンクを表示するとしており、送信ドメインのレピュテーションが低い状態では表示されないことがあります。

この場合はヘッダをいくら見直しても改善しません。SPF・DKIM・DMARCの設定、送信量の推移、迷惑メール報告率といったメール運用全体を点検する必要があります。

実務でハマりやすい5つの落とし穴

仕様どおりに実装しても、運用面で問題が起きるパターンがあります。事前に把握しておきたいポイントを挙げます。

GETリクエストで意図しない解除が発生する

セキュリティ製品やメールソフトが、本文中のURLを安全性チェックのために自動アクセスすることがあります。解除エンドポイントがGETリクエストでも解除処理を実行する実装になっていると、受信者が何もしていないのに解除されてしまいます。

RFC 8058がPOSTを採用したのは、まさにこの誤動作を避けるためです。エンドポイントはPOSTのみを受け付ける設計にしてください。

cc/bccを含む配信で他人の購読が解除される

1通のメールを複数の宛先に送る配信で、List-Unsubscribeに単一の識別子を埋め込むと問題が起きます。ccで受け取った人が解除を実行すると、to宛の別人が解除されるという事故につながります。

List-Unsubscribeは1通1宛先の配信を前提とした仕組みです。cc/bccを使う配信では、ヘッダを付与しない判断も必要になります。

トランザクションメールへの付与を一律で判断しない

パスワード再設定通知や注文確認メールは、各社のガイドライン上ワンクリック解除の対象外です。むしろ受信者が誤って解除すると業務上重要な通知が届かなくなるリスクがあります。

一方で、同じシステムから送る通知メールでも、性質上マーケティング要素を含むものは対象になり得ます。メールの種類ごとに付与の可否を設計してください。

解除の反映が遅れてレピュテーションが下がる

解除リクエストを受け付けても、実際の配信除外が次回配信に間に合わなければ、受信者は「解除したのにまた届いた」と受け取ります。この状況で押されるのは迷惑メール報告ボタンです。

解除リクエストの受付から配信リストへの反映まで、自動で完結しているかを必ず確認してください。バッチ処理のタイミング設計が甘いと、ここが穴になります。

解除ページの「引き止め」が逆効果になる

解除ページで理由の入力を求めたり、別のプランを提案したりする設計を見かけますが、ワンクリック解除の文脈ではこれらは不要です。仕様上、POSTを受けた時点で解除が完了している必要があります。

引き止めたい気持ちは分かりますが、解除までの手間が増えるほど、スパム報告に流れるリスクが高まります。配信頻度の変更オプションを提示するなら、解除完了後の画面で行うのが安全です。

List-Unsubscribeの実装方法は2通り

ここまでの要件を踏まえると、実装のアプローチは大きく2つに分かれます。

自社でヘッダとエンドポイントを実装する

自社のメールサーバーやアプリケーションから直接配信している場合、ヘッダの生成から解除エンドポイントまでを自前で構築します。SMTPリレー経由で配信する構成なら、メッセージを組み立てるアプリケーション側でヘッダを付与できるため、解除フローを自社の会員基盤と密結合させたい場合に適しています。

ただし、DKIM署名の対象ヘッダ設定については、利用中の配信基盤の仕様を確認する必要があります。

List-Unsubscribeに対応したメール配信システムを利用する

多くのメール配信システムは、配信するだけで必要なヘッダが自動付与され、解除リクエストの受付から配信リストの除外までをシステム側で完結させます。専門知識なしで要件を満たせる点が最大の利点です。

判断基準はシンプルです。 解除フローを自社の会員システムと深く連携させる必然性があるなら自社実装、そうでなければ配信システムに任せたほうが、構築工数も運用リスクも小さく収まります。

List-Unsubscribeに確実に対応するならメール配信システムを活用する

List-Unsubscribeの実装には、ヘッダの記述だけでなく、DKIM署名の設計、解除エンドポイントの構築、2日以内の除外処理、そして送信ドメイン全体のレピュテーション管理までが関わります。技術要件を1つでも取りこぼすと、解除リンクが表示されないという結果に直結します。

これらをまとめて解決する現実的な選択肢が、メール配信システムの活用です。

メール配信システムを使うメリット

メール配信システムは、各社の送信者ガイドラインに対応することを前提に設計されています。送信者が個別にヘッダやサーバーを用意する必要がありません。

自社でメールサーバーを維持するコストと、要件変更のたびに発生する改修工数を考えると、配信基盤は外部に任せ、自社はコンテンツと導線の設計に集中する判断が合理的です。

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、自社システムとSMTPリレーまたはAPIで連携することで、一斉配信からトランザクションメールまでを扱えるメール配信サービスです。メールサーバーの構築・運用が不要になるため、解除フローの設計といった本来注力すべき実装にリソースを振り向けられます。

解除の仕組みを自社で作り込みたい開発者にとって、土台となる配信基盤の品質は成果を左右します。初期費用無料・月額3,000円から利用でき、メールアドレスの入力のみで無料トライアルが可能です。日本語での電話・メールによるテクニカルサポートも用意されています。

ブラストエンジン公式サイト：https://blastengine.jp/

おすすめのメール配信システム「ブラストメール」

ブラストメールは、15年連続で導入社数シェアNo.1を獲得しているメール配信システムです。導入実績は27,000社以上。専門知識がなくても直感的に操作できる管理画面が支持されています。

自社で配信システムを開発せず、マーケティング担当者が主体となってメルマガを運用するなら有力な選択肢です。無料トライアルで操作感を確認できます。

公式サイト：シェア1位のメール配信システム「ブラストメール」

まとめ

List-Unsubscribeは、メールヘッダに解除の導線を持たせるための仕組みです。RFC 2369がヘッダ自体を定義し、RFC 8058がワンクリックでの解除完了を定義しました。GmailとYahoo!メールは2024年2月から、1日5,000通以上の送信者に対してこの実装を必須要件としています。Microsoft Outlookは2025年5月から送信ドメイン認証を必須化しており、配信停止手段の提供は推奨事項に位置づけられています。

実装で押さえるべき要点を整理します。

まず取るべきアクションは、自社が現在配信しているメールのソースを1通確認することです。List-Unsubscribe-Postヘッダが存在するか、DKIM署名の対象に含まれているか。ここを確認すれば、いま何が足りていないかがはっきりします。

自社実装のハードルが高いと判断した場合は、要件に対応した配信基盤への移行を検討してください。