解除は1回の操作で終わらせる｜送信者に求められる形

「解除のリンクは本文の末尾に置いてある」「長い間それで問題は起きていない」——配信の設定を見直す場面で必ず出てくる言い分です。解除の導線は、置いてあれば足りるという話ではありません。受信箱の側に解除の操作を出すことが、一定の規模の送信者には求められています。この記事では、求められている形と、実装で詰まりやすい箇所を整理します。

本文のリンクだけでは足りない

以前は、本文の末尾に解除のリンクを置けば十分でした。それが長く標準として扱われてきました。

2024年2月以降、要件が強化されました。マーケティングのメールには、1回の操作で解除できる機能の搭載が求められます。

この機能は、メールを開かなくても受信箱の一覧から解除できる形を指します。本文のリンクとは別の仕組みです。

実装は、メールの見えない部分に指定の記述を追加することで行います。本文には手を入れません。

記述があると、受信箱の側に解除のボタンが表示されます。読む側の手間が大きく減ります。

実装していないと、届きにくくなる恐れがあります。要件を満たさない送信者と見なされます。

配信の道具を使っている場合、道具の側で対応済みのことも多くあります。まず確認します。

以下では、対象と実装の中身を整理します。

対象になる送信者

すべての送信者が対象ではありません。件数の目安が示されています。

目安は、24時間以内に5,000件近く、あるいはそれ以上を送る送信者です。この水準を超えると要件の対象になります。

件数は同じ主たるドメインからのメール全体で数えられます。部署ごとに分けて送っていても合算されます。

一度でも超えると、その後も対象として扱われる可能性があります。継続的に満たす前提で考えます。

自社が対象かは、月の配信の件数を数えれば分かります。1日あたりに換算して5,000件に近づくなら、対応を進めます。

対象になるメール

対象はマーケティングと宣伝のメールです。すべてのメールが対象ではありません。

取引に関わるメールは除外されます。注文の確認や、申し込みの受付の通知などです。

ただし、取引の通知に宣伝の内容を混ぜると、対象と見なされる恐れがあります。混ぜない設計が安全です。

配信の一覧に登録した相手へ送る案内は、多くが対象になります。定期の配信は該当します。

判断に迷う場合は、対象として扱っておくのが無難です。実装しても不都合はありません。

受信箱の側に表示が出る

実装すると、受信箱の一覧やメールの上部に解除のボタンが表示されます。

読む側は、そのボタンを押すだけで解除できます。本文を開いてリンクを探す必要がありません。

この手軽さが、迷惑メールとして報告される代わりの選択肢になります。ここが要件の狙いです。

解除が簡単でないと、読む側は迷惑メールとして報告します。報告が増えると届きにくくなります。

つまり、解除を簡単にすることが送信者の利益にもなります。要件は理にかなっています。

別の主要なサービスでも同じ記述に対応しており、対応するメールを開くと解除のボタンが表示されます。

実装は1つの記述で複数のサービスに効きます。個別の対応は要りません。

表示の仕方はサービスによって異なります。位置や文言は制御できません。

本文のリンクとの役割分担

受信箱の側のボタンと、本文のリンクは両方を残します。片方だけでは足りません。

受信箱の側は、すぐに解除したい人向けです。1回の操作で完了させます。

本文のリンクは、頻度や内容を選びたい人向けにします。選択肢を示す画面へ導けます。

両方あることで、目的に応じた経路が用意されます。解除の総数は増えても、報告は減ります。

本文のリンクを消してはいけません。受信箱の側の表示が出ないサービスもあります。

実装に必要なもの

実装は、メールのヘッダーに指定の記述を追加する形で行います。

必要なのは、解除の窓口を示す記述と、1回の操作での解除を受け付ける記述の2つです。

解除の窓口には、安全な接続のURLを含めることが必須とされています。メールでの解除の指定は任意です。

この2つの記述が揃って、はじめて受信箱の側にボタンが表示されます。片方だけでは機能しません。

記述の書き方は仕様書で定められています。仕様に沿っていないと認識されません。

指定されたURLは、押されたときに解除の処理を受け付ける必要があります。表示だけでは足りません。

処理を受け付ける仕組みを用意するのが、実装の実体です。ここに開発の作業が発生します。

配信の道具を使っている場合は、道具の側が用意しています。

署名の対象に含める

仕様では、なりすましを防ぐ署名への対応が必須とされています。記述だけでは足りません。

追加した2つの記述を、有効な署名の対象に含める必要があります。署名の設定に関わる作業です。

署名の対象から外れていると、記述が信頼されず表示されない場合があります。実装の見落としが起きやすい部分です。

署名の設定は、送信のドメインの管理に関わります。情報システムの担当と一緒に進めます。

配信の道具を使う場合も、署名の設定は自社で行う必要があります。道具の設定と署名の設定は別の作業です。

48時間以内に処理する

解除の要求を受けたら、速やかに処理します。時間の目安が示されています。

公式の説明では、解除の要求には48時間以内に対応することが推奨されています。

手作業で処理している場合、この時間に間に合わない恐れがあります。自動で処理する仕組みが前提になります。

処理が遅れると、次の配信が届いてしまいます。読む側は解除できていないと感じ、報告に至ります。

解除の処理は、配信の一覧から確実に外す形にします。印を付けるだけでは、次の抽出で漏れます。

複数の一覧を持っている場合、すべてから外す設計が必要です。1つだけ外しても届き続けます。

処理の記録も残します。いつ解除されたかが分かる状態にします。

記録があれば、届いたという指摘にも答えられます。

解除の画面で引き止めない

解除の要求が来たとき、引き止めたくなります。ただし要件の趣旨からは外れます。

1回の操作での解除は、追加の操作を求めない形を指します。理由を尋ねる画面を挟むと趣旨に反します。

認証を求めたり、複数の確認を挟む形も避けます。読む側の負担が増えると報告に流れます。

配信の頻度や内容を選ばせる画面を出したい場合は、本文のリンクの側に用意します。

本文のリンクなら、選択肢を示す設計も可能です。2つの経路を役割で分けます。

受信箱の側からの解除は即座に完了させ、本文のリンクからは選択肢を示す。この分担が現実的です。

解除した後に、理由を任意で尋ねる画面を出す方法もあります。解除は完了させたうえで尋ねます。

任意であることを明示します。答えないと解除されない形は避けます。

迷惑メールの報告率の基準

解除を簡単にする理由は、報告率を抑えることにあります。基準が示されています。

公式の説明では、0.1%未満に抑え、決して0.3%以上にならないようにするとされています。

0.3%を超過した場合、緩和の申し立てができないとされています。取り返しがつかない水準です。

報告率は毎日計算されます。1回の配信で悪化すると、その日の数字に反映されます。

0.3%は、1万件の配信で30件の報告に相当します。多くないように見えますが、簡単に超える水準です。

報告を減らす最も確実な方法は、解除を簡単にすることです。要件の狙いと一致します。

配信する相手の質も影響します。同意を得ていない相手に送ると報告が増えます。

報告率は管理の画面で確認できる場合があります。定期的に見ます。

0.3%を超えると戻せない

超過した後の影響は大きくなります。届きにくくなり、改善の申し立ても難しくなります。

そのため、0.1%を目安に運用します。0.3%は上限ではなく、絶対に近づけない線として扱います。

1回の配信で急に悪化することがあります。久しぶりの配信や、購入した一覧への配信が原因です。

久しぶりの配信は、相手が登録を覚えていません。報告される確率が上がります。

配信の間隔が空いた場合は、件数を分けて様子を見ます。一度に全件へ送らない設計が、報告率を守ります。

認証の3つの設定

解除の実装とあわせて、認証の設定も要件になっています。3つの設定が求められます。

1つ目は、送信するサーバーとドメインの対応を示す設定です。すべての一括の送信者に必須とされています。

2つ目は、署名による認証の設定です。これも必須とされています。

3つ目は、認証に失敗したメールの扱いを受信側に指示する記録です。送信のドメインへの追加が必要とされています。

加えて、差出人の表示がこれらの認証のドメインと一致する必要があります。食い違うと認証が成立しません。

独自のドメインを差出人にする場合、この3つの設定が前提になります。

設定はドメインの管理の画面で行います。情報システムの担当と進めます。

設定の確認は、専用の確認の道具で行えます。実装の後に必ず確認します。

設定を確認する手順

確認は、自分のメールアドレスに送って結果を見る形が最も手軽です。

受け取ったメールの詳しい情報を開くと、認証の結果が記載されています。

3つの項目がすべて合格になっているかを見ます。1つでも不合格なら設定に不備があります。

外部から確認できる道具もあります。ドメインを入力すると設定の状態が判定されます。

配信の道具から送る場合も、同じ確認を行います。道具ごとに結果が変わることがあります。

要件	内容	確認の方法
1回の操作での解除	ヘッダーに2つの記述を追加	受信箱に解除のボタンが出るか
署名への対応	記述を署名の対象に含める	署名の検証が通るか
48時間以内の処理	自動で一覧から外す	解除の翌日に届かないか
認証の3つの設定	対応の設定と署名と扱いの記録	確認の道具で判定する

配信の道具で対応できるか

多くの配信の道具は、この要件に対応しています。まず自社の道具を確認します。

確認するのは、受信箱の側に解除のボタンが出る設定が用意されているかです。

対応していても、設定を有効にしていない場合があります。既定で無効な道具もあります。

解除の処理が自動で行われるかも確認します。手作業だと48時間に間に合いません。

複数の一覧を持てる道具では、すべてから外す設定になっているかを見ます。

署名の設定は、道具の側だけでは完結しません。ドメインの側の設定が必要です。

道具の提供元が手順を公開している場合が多くあります。手順に沿って進めます。

対応していない道具なら、乗り換えの検討が必要になります。

自社で送っている場合

自社の仕組みで送っている場合、実装は自前で行います。作業量が増えます。

必要なのは、ヘッダーの追加、解除を受け付ける窓口の実装、一覧から外す処理の3つです。

窓口は、押されたときに解除を確定させる必要があります。画面を表示するだけでは足りません。

押された要求が本物かの確認も必要です。誰でも他人の解除を実行できる形は避けます。

確認の方法として、要求に固有の文字列を含める設計が使われます。仕様書に例が示されています。

実装の後は、実際にボタンが表示されるかを複数のサービスで確認します。

開発の作業が発生するため、日程に余裕を持って計画します。

件数が多い送信者なら、配信の道具への移行も選択肢になります。

移行を検討する目安

自前の実装を続けるか、道具に移るかの判断は、要件の変化への追随の負担で決まります。

要件は今後も変わる可能性があります。変わるたびに開発の作業が発生します。

道具を使えば、提供元が要件の変化に追随します。自社の作業は設定の確認だけです。

移行には配信の一覧の移し替えと、解除の記録の引き継ぎが必要です。手間はかかります。

判断の目安は、年間の開発の工数です。追随に人月がかかるなら、道具の費用のほうが安く済みます。

解除されることを恐れない

解除を簡単にすると、解除の件数が増えます。恐れる担当者が多くいます。

ただし、解除する相手はもともと読んでいません。一覧に残っていても成果にはつながりません。

残しておくと、迷惑メールとして報告される恐れが残ります。報告のほうが損失は大きくなります。

解除によって一覧の数は減りますが、開かれる割合は上がります。質が上がる形です。

報告率が下がれば、届きやすさも改善します。全体の成果は上がる方向に働きます。

経営に説明するときは、件数ではなく質の指標で示します。開かれた数と成果の数です。

一覧の件数を成果として報告していると、この説明が難しくなります。指標を見直します。

指標の見直しは、解除の実装と同時に行うのが良い機会です。

解除は健全化の合図

解除の件数が多い配信は、内容や頻度に問題がある可能性があります。合図として読みます。

特定の配信の後に解除が集中するなら、その内容を見直します。原因が絞れます。

頻度が高すぎる場合も解除が増えます。配信の間隔を見直す材料になります。

解除の理由を任意で尋ねると、改善の手がかりが得られます。答えは強制しません。

集めた理由は月ごとにまとめます。傾向が見えれば、配信の設計に反映できます。

実装後の確認

実装したら必ず確認します。設定しただけでは動いていないことがあります。

最も確実な確認は、自分の受信箱に送って解除のボタンが出るかを見ることです。

複数のサービスの受信箱で確認します。表示の仕方が異なるため、片方だけでは不十分です。

ボタンを押して、実際に解除が確定するかも確かめます。表示だけで処理されない事故があります。

解除した相手に、次の配信が届かないことも確認します。翌回の配信で確かめます。

認証の設定も、確認の道具で判定します。3つすべてが通っているかを見ます。

報告率の数字も、管理の画面で確認します。基準に対する位置を把握します。

確認の結果は日付とともに記録します。次の変更のときに比べられます。

確認する項目を一覧にする

項目を一覧にしておくと、抜けが減ります。5項目で足ります。

解除のボタンの表示、押した後の解除の確定、次回の配信の不着、認証の3つの設定、報告率の水準です。

それぞれ期待される結果を書いておきます。書いていないと何を見るか分かりません。

一覧は情報システムの担当と共有します。作業の依頼にそのまま使えます。

配信の道具を変えたときも、同じ一覧で確認します。

対応の手順

実際の進め方を整理します。件数の確認から始めます。

この5段階で対応は完了します。3段目に最も時間がかかります。

認証の設定はドメインの管理に関わるため、社内の調整が必要です。日程に余裕を持って着手します。

やりがちな失敗

対応でつまずく形は、ある程度共通しています。

• 本文のリンクだけで足りていると考える：受信箱の側の表示が出ず、要件を満たさない
• 記述を署名の対象に含めない：記述が信頼されず、ボタンが表示されない場合がある
• 解除の画面で理由や認証を求める：1回の操作という趣旨から外れ、報告に流れる
• 解除の処理を手作業で行う：48時間に間に合わず、解除後に配信が届いてしまう
• 複数の一覧のうち1つだけから外す：他の一覧から届き続け、報告につながる

いずれも、実装の後に受信箱で確認すれば気づけます。設定した時点ではなく、確認を終えた時点を完了とします。

もうひとつ多いのが、久しぶりの配信を一度に全件へ送ることです。報告率が急に悪化します。

間隔が空いた場合は件数を分けます。様子を見ながら段階的に送る設計が、報告率を守ります。

運用の決めごと

配信を続ける前提で、決めごとを用意します。項目は少なく保ちます。

• 受信箱の側の解除のボタンを有効にし、記述を署名の対象に含める
• 解除は自動で処理し、複数の一覧すべてから外す
• 報告率は0.1%を目安に運用し、0.3%には近づけない
• 間隔が空いた配信は件数を分け、報告率を見ながら進める

この4項目を配信の手順書に入れます。配信のたびに読み返せます。

見直しの時期

配信の道具を変えたときは、必ず再確認します。設定が引き継がれない場合があります。

送信のドメインを変えたときも同じです。認証の設定はドメインごとに必要です。

報告率は月に一度確認します。悪化の傾向が見えたら、配信の内容と頻度を見直します。

要件は変わることがあります。年に一度、公式の説明を読み直します。

確認した内容は記録に残します。判断の背景が次の担当者に伝わります。

よくある質問

配信の件数が少なければ対応は不要ですか

要件の対象は一定の件数を超える送信者ですが、対応しておくと報告率が下がり届きやすさが改善します。件数が少ない段階で整えておくほうが、後の負担も軽くなります。

取引に関わるメールにも実装すべきですか

対象からは除外されていますが、実装しても不都合はありません。ただし取引の通知に宣伝の内容を混ぜると対象と見なされる恐れがあるため、混ぜない設計にします。

解除の理由を聞いてはいけないのですか

解除を完了させたうえで、任意で尋ねる形なら問題ありません。避けるべきは、理由の入力や認証を解除の条件にすることです。1回の操作という趣旨から外れます。

報告率はどこで確認できますか

送信者向けの管理の画面で確認できる場合があります。確認できない環境では、配信の道具の側の指標や解除の件数の推移を代わりの手がかりにします。

解除が増えて一覧が減るのが心配です

解除する相手はもともと読んでいないため、成果には寄与していません。残すと報告につながる恐れがあり、そのほうが損失は大きくなります。件数ではなく開かれた数を指標にします。

まとめ

配信の解除は、本文のリンクだけでは要件を満たしません。要点は、ヘッダーに2つの記述を追加し、署名の対象に含めて受信箱の側にボタンを出すことです。解除の要求は48時間以内に自動で処理し、複数の一覧すべてから外す。報告率は0.1%を目安に運用し、0.3%には近づけない。超えると改善の申し立てが難しくなる。解除が増えることを恐れず、開かれた数と成果の数を指標にします。まずは自社の配信を自分の受信箱に送り、解除のボタンが出るかを確かめてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。