Podcast: Embed
Webで購読する Apple Podcasts | Spotify | Amazon Music | Pandora | RSS | More
ラウンドナップWebコンサルティングの中山陽平です。 今回は、Gmailの迷惑メール対策(送信者ガイドライン)の強化を題材にしながら、「大事なWeb関連情報を、社内できちんと受け取れる状態になっているか」を見直すお話です。
このPodcast/書き起こしで得られること(要点)
Gmail宛のメールが届きにくくなる、迷惑メールフォルダに入る、といった話は技術論に見えますが、実はもっと根の深いテーマにつながっています。 この回を読むと、「そもそも重要な変化に気づけない状態」を抜け出し、配信や運用の異変を早めに察知できるようになるための考え方と、具体的な見直しポイントが整理できます。
- Gmailの変更を「知らなかった/知っていたが動けなかった」状態がなぜ危険か
- 配信状況(到達・開封など)を把握せずに運用を続けるリスクと、整え方
- リスト運用(承諾・クリーンアップ)の考え方と、見直しの手順
Gmailの変更は「メールの話」だけでは終わりません
Gmailは、多くの方が日常的に使っているメール基盤です。業務でGoogle Workspaceを使っていなくても、やり取りの中心がGmailというケースは少なくありません。 そのGmail側で、迷惑メール対策や送信者に求める要件が強化され、条件を満たさないと「送ったのに届かない」「迷惑メールフォルダに入る」といったことが起きやすくなります(参考:Email sender guidelines – Google Workspace Admin Help)。
ただ、私がこの回で強くお伝えしたいのは、細かな設定方法そのものではありません。 大きな変更が起きたのに気づけなかった、あるいは聞いたのに分からなくて放置したという状態は、メール以外の領域でも「危険に気づけない」ことにつながりやすいからです。たとえばWebサイトの脆弱性や、フィッシング、セキュリティのトレンドなども、社内に入ってくる経路が弱い可能性があります。
こういう状況の方は、特に注意が必要です
ここからは「今回の件に限らず、危険が起きやすい状態」を整理します。 当てはまるものがある場合は、メール配信だけでなく、運用全体の受け取り方・判断の仕方を一段整えておくことをおすすめします。
- Gmailの変更をそもそも知らなかった
- 知っていたが、結局分からなくて放置した
- 配信状況を把握せず、異変に気づかないまま配信を続けている
1) 変更を知らなかった場合:情報の入り口が足りないサインです
今回の件は「Gmailという大きなインフラで変更があった」という話です。ここに気づけないのは、たまたまではなく、重要な情報が自然に入ってくるルートが弱い可能性があります。 個人情報漏洩のような重大事故と比べれば、今回の話はリスクの種類が違いますが、だからこそ「情報を受け取る体制」を整える良いきっかけになります。
2) 知っていたが動けなかった場合:判断と実行の仕組みが必要です
知っていたのに何もしなかった、は結果として「やっていない」のと同じです。忙しい、難しそう、うちは関係ないだろう、と思っているうちに後回しになりがちです。 この状態を避けるには、社内でインシデント系の情報を共有し、単に回覧して終わるのではなく「やるべきことはやる」と判断できるようにすること、そして実行担当を決めておくことが大切です。社内で難しいなら、外部パートナーに判断ごと任せられる体制を持つのも選択肢になります。
3) 配信状況を把握していない場合:気づかない損失が積み上がります
今回のようにGmail側の条件が変わると、これまで受信トレイに届いていたメールが迷惑メールフォルダに入ったり、届かなくなったりすることがあります。 そのとき、到達状況や開封状況を把握していないと、「反応が落ちた原因」を取り違えやすくなります。本当は到達が落ちているだけなのに、件名や送信時間、内容を疑って、せっかく整えてきた運用を崩してしまう可能性があるわけです。
特に、古い自前の仕組み(昔に作ったCGIなど)で「ただ分割して送るだけ」の状態だと、開封の把握、リストの整理、配信停止の導線などが整いにくいことがあります。 少人数に送る運用でも、反響を期待しているなら、開封や反応の把握、リスト整理まで含めて扱える「きちんとしたメール配信の仕組み」を持っておくほうが安心です。
リスト運用は「数を誇る」ほど危険になりやすい
リストについては、昔から同じ危険があります。登録者数を誇るような運用はリスクが高い、ということです。必要のない人にも大量に送り、その中の一定数が反応すればいい、という考え方は、今の状況では通りにくくなっています。 ここは言いにくいのですが、「ほぼほぼスパム」と言ったら失礼なんですけれども、そういう時代に近い発想のままだと、特に危ないと感じています。
長年積み重なって消されないままのリストを、私は悪い意味で「秘伝のタレリスト」と呼ぶことがあります。数が多くて反応が鈍いなら、数を増やすよりも、反応がある方に絞ってコンパクトに送るほうがよい結果になりやすいです。 「売れた1%」よりも「売れなかった99%」に目を向けて、なぜ反応がないのか、そもそも送るべきなのか、を点検するほうが健全です。
実質未承諾になっているフローは、早めに見直してください
名刺交換した相手に自動で配信対象としてメールが飛ぶ、という運用は注意が必要です。受け取った側は、配信停止の手続きをするよりも先に、迷惑メールとして報告してしまうことがあります。 その積み重ねが、到達性の悪化につながります。承諾を得ることを基本にして、運用の流れを整えてください。
「買ったかもしれない」「相乗りしたことがある」リストはクリーンアップの対象です
前任者がリストを購入していたかもしれない、他社と相乗り配信をしたことがある、プレゼント企画のような形で集めたアドレスが残ったまま、という場合は、早めに整理したほうが安全です。 受け手側がすでに多くのメールを受け取っている状態だと、ニーズが合う前に「怪しいメール」として扱われやすくなり、読まれにくくなります。
リストクリーンアップの考え方と目安
クリーンアップの前提は、開封状況などを把握できる仕組みがあることです。送ってみると、開封しない方が一定割合で出ます。 開封率が一桁の状態なら、かなり危険度が高いと考えています。目安としては3割程度を目指し、10%〜20%の状態が続くなら、整理を検討したいところです。私たちの場合は4〜5割ほどです。
ただし、開封は完全に正確ではありません。セキュリティの都合で「開いているのに開いていないように見える」ことや、画像を読み込まない設定で開封扱いにならないこともあります。 そのため、「5回連続で開封が確認できない方」に対して、今後も送ってよいか確認のメールを送り、反応がなければ配信を止める、といった段階的な整理が現実的です。配信停止後の再開導線を用意しておくのもよいと思います。
ここから先は技術の話:押さえるべき要件だけ整理します
細かな設定手順は、各サービスの案内が充実していますし、依頼すれば対応できることが多い部分です。この回では「何が求められているか」だけ、要点に絞って整理します。 特にGmail宛に送る場合は、送信規模にかかわらず、満たしておくべき要件が増えています(参考:Email sender guidelines FAQ – Google Workspace Admin Help)。
1) 送信ドメインの認証(SPF / DKIM / DMARC)
基本は、送信元ドメインが「なりすましではない」ことを示す設定です。 具体的には、DNS(ドメインに紐づく行き先情報)に、SPF(送信を許可するサーバーの宣言)やDKIM(署名による改ざん検知)を設定し、規模が大きい場合はDMARC(整合のルールと運用方針)も設定します(参考:RFC 7208、RFC 6376、RFC 7489)。
最近は、レンタルサーバーやメール配信サービス側がワンクリックで設定できる機能を用意していることも増えています。ドメイン管理会社とサーバー会社が別だと設定が面倒になりやすいので、運用を楽にする意味では、まとめて管理する判断も出てきます。
2) 迷惑メール報告率(スパム率)を低く抑える
受信者が「迷惑メールとして報告」した割合を低く保つことが求められます。Googleの案内では、Postmaster Toolsで確認できる迷惑メール率を0.3%未満に保つことが示されています(参考:Email sender guidelines)。 大量配信している場合は、Postmaster Tools(ポストマスターツール)で状況を確認できます(参考:Set up Postmaster Tools – Google Workspace Admin Help、Postmaster Tools by Gmail)。
一方で、小規模配信だと絶対数が足りず、データが出ないこともあります。その場合は、メール配信サービス側の配信停止理由(「迷惑」などの選択肢)や反応状況を見ながら、悪化の兆しがないか点検していく形になります。 また、一度スパム判定が強く出る状態になると、戻すのは大変です。基本は、開いて読んでくださる方に絞り、迷惑メール報告が起きにくい運用を維持していくことになります。
3) TLS(送信時の暗号化)
送信時のTLS(暗号化)についても要件に含まれます。ただ、一般的なメール配信サービスや、きちんと運用されている環境であれば、過度に構えなくてよいことが多いと思います。 とはいえ、古い自前システムなどの場合は、まとめて点検しておくと安心です。
(一定規模以上)ワンクリック登録解除の実装
24時間あたり約5,000通以上をGmail宛に送る場合は、追加の要件として、ワンクリック登録解除が求められます。ここで勘違いしやすいのは、「解除フォームへ移動できるリンク」では足りない、という点です。 メールソフト上で解除が完結できるように、List-Unsubscribeヘッダーなどを、仕様に沿って実装する必要があります(参考:Email sender guidelines FAQ、RFC 8058)。
これは配信システム側の対応が必要になることが多いので、メール配信サービスを使っている場合は、ベンダーに「対応済みか、対応予定か」を早めに確認しておくのがよいと思います。Googleの案内では、対応時期の目安として2024年6月1日が示されています。
見落としがちな落とし穴:フォーム送信の差出人がGmailになっていませんか
意外と多いのが、Webサイトのお問い合わせフォームの自動返信メール(サンクスメールなど)で、差出人(From)にGmailアドレスを入れているケースです。 Webフォームは自社ドメイン上にあるのに、FromがGmailだと認証の整合が崩れ、届きにくくなる可能性があります。心当たりがある場合は、差出人は自社ドメインのメールアドレスにそろえるのが安全です。
どうしてもGmailで共有管理したい場合は、自社ドメインのメールアカウントを作り、そこから転送するか、Gmail側でポストオフィスプロトコル(POP)で取り込む方法があります。安定性の観点では、Gmail側で取り込む運用を好む方も多いと思います。設定方法は公開情報も多いので、必要なら依頼して整えてください。
メールはまだ重要です。だからこそ、運用の土台を整えましょう
BtoBでは特に、メールは今も現役の手段です。チャットツールやメッセージングがすべてを置き換える、という話もありましたが、用途が違いますし、コストや安定性の面でも簡単に置き換わるものではありません。 だからこそ、メールを「送りっぱなし」にせず、必要な情報が社内に入り、判断でき、配信状況を把握し、リストを健全に保つ。ここを土台として整えていくことをおすすめします。
関連リンク
- Email sender guidelines – Google Workspace Admin Help
- Email sender guidelines FAQ – Google Workspace Admin Help
- Set up Postmaster Tools – Google Workspace Admin Help
- RFC 8058 – Signaling One-Click Functionality for List Email Headers
- RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC)
FAQ
- Gmailの迷惑メール対策強化で、何が起きやすくなりますか?
-
送信者側の条件(ドメイン認証や迷惑メール率など)を満たせていないと、Gmail宛のメールが「届かない」「迷惑メールフォルダに入る」といったことが起きやすくなります。 特に怖いのは、そうした変化に気づけないまま配信を続け、反応低下の原因を取り違えてしまうことです。
- まず最初に見直すべきポイントはどこですか?
-
技術設定の前に、「重要な変更が社内に入ってくる仕組み」と「判断して動ける体制」を見直してください。 担当や実行者が曖昧だと、知っていても放置が起きやすくなります。難しい場合は、外部パートナーに判断ごと任せる形も選択肢です。
- 配信状況を把握できていないと、どんな問題がありますか?
-
到達が落ちているのに気づかず、件名や送信時間、内容だけを疑って運用を崩してしまうことがあります。 反応が落ちた原因が「届いていない」ことなら、どれだけ内容を工夫しても結果が出にくいので、把握の仕組みが重要です。
- リストのクリーンアップは、どのように進めるのがよいですか?
-
開封などの状況を把握できる仕組みを前提に、反応が見えない方を段階的に整理します。 たとえば「一定回数開封が確認できない方に、今後も送ってよいか確認する」など、誤判定の可能性も踏まえた進め方が現実的です。
- お問い合わせフォームの自動返信で、差出人がGmailになっている場合は?
-
差出人(From)は原則として自社ドメインのアドレスにそろえるのが安全です。 共有管理の都合でGmailを使いたい場合は、自社ドメインのメールをGmail側で取り込む(POP)など、整合を崩さない形に切り替えてください。
配信スタンド
- Apple iTunes 公式ストア Podcast(おすすめ)
https://itunes.apple.com/jp/podcast/zhong-shan-yang-pingno-non/id750899892 - GooglePodcast
http://bit.ly/google-podcast-jp - Spotify
https://open.spotify.com/show/0K4rlDgsDCWM6lV2CJj4Mj - Amazon Music
Amazon Podcasts
■Podcast /Webinar への質問は
こちらのフォームへどうぞ。
https://forms.gle/Lvy4nVauyJ2SRhJM7
運営・進行
株式会社ラウンドナップ(ラウンドナップWebコンサルティング)
代表取締役・コンサルタント 中山陽平
Webサイト:https://roundup-inc.co.jp/


