Googleが2026年1月に廃止するのは、Webブラウザ版Gmailの設定にある「他のアカウントのメールを確認」という機能だ。これは、Gmail側から外部のメールサーバ（POP3）にアクセスし、メールを取り込む機能だ。この機能を利用して、個人のGmailフォルダに社用のメールを受信し、1つの受信トレイで統合管理するという“隠れBYOD”の形で個人Gmailで社用メールを閲覧していたという事例がある。

自動転送が招く「メール認証」の破綻

　従業員が個人のGmailへの自動転送を設定した場合、起こり得ることは何か。SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail）、DMARC（Domain-based Message Authentication, Reporting and Conformance）の判定プロセスにおける「認証失敗」の多発だ。

SPF認証の破綻メカニズム

　SPFは、メールの送信元IPアドレスが、そのドメインの所有者によって許可されているかを確認する仕組みである。通常であれば、正規のメールサーバから送信されたメールはSPF認証に成功する。しかし、転送が入ると状況は一変する。以下は一例だ。

1. 取引先（example.com）から、あなたの会社のメールアドレス（company.co.jp）にメールが届く。
2. 会社のメールサーバが、従業員の個人Gmail（gmail.com）へそのメールを自動転送する。
3. Gmail側で受信した際、送信元IPアドレスは「company.co.jpの転送サーバ」となるが、メール上の差出人（Envelope From）は「example.com」のままであるケースがある。
4. Gmailは「example.com」のSPFレコードを参照するが、当然ながらそこに「company.co.jp」のIPアドレスは記載されていない。
5. 結果、SPF認証は失敗となる。

　このように、転送という行為そのものが、送信元ドメインの正当性を証明するSPFの仕組みと矛盾してしまうのだ。

DKIM署名の破損リスク

　「SPFがダメでも、DKIMがあれば問題ないのではないか」と考えることもできる。DKIMは非対称暗号化を使用してメールのなりすましを防ぐ標準規格だが、転送プロセスにおいて無力化されることがある。

　一部のメールサーバや転送設定は、転送時に件名に「[Fwd:]」を付加したり、本文末尾にウイルスチェック済みのフッターを挿入したりする。メールのエンコーディング形式を変換することもある。メールの内容が1ビットでも変更されれば、DKIMのハッシュ値は一致しなくなり、DKIM認証が失敗する。

DMARCが「拒否」した場合の損失は

　SPFもDKIMも失敗したメールを、受信側であるGmailはどう扱うか。それを決定するのが、メールの認証に、DKIMとSPFを使用するDMARCのDMARCポリシーだ。取引先（example.com）が高いセキュリティ意識を持ち、DMARCポリシーを「p=reject（拒否）」に設定していた場合、転送されたメールはGmailの受信トレイに届かない。

　従業員にとっては「取引先からのメールが届かない」事態となる。そこで、IT部門に相談する。しかし、その原因を作ったのは従業員自身の設定だ。この事態は、不便さの問題ではなく、ビジネス機会の損失につながるインシデントとなり得る。

自社ドメインが「スパム」判定される恐れも

　リスクは「メールが届かない」だけでは済まなくなる恐れもある。自社ドメインの信用が低下する可能性がある。

　自動転送設定の大半は、フィルタリングをせず届いたメール全てが転送される。スパムメールやフィッシングメールも転送されてしまう。Gmail側から見ると、あなたの会社のサーバから、スパムメールが大量に転送されてくることになる。Googleのアルゴリズムは、「あなたの会社のドメインがスパムを配信している」と判断するリスクがある。

　一度、ドメインやIPアドレスのレピュテーションが低下すると、回復は容易ではない。転送とは無関係な、他の従業員が送った正規の業務メールが、Gmailや他のプロバイダーで「迷惑メール」フォルダに振り分けられる場合もある。1人の従業員の「便利に使いたい」という思いで進めた設定が、全社のメールインフラを異常な状態に向かわせる恐れがあるのだ。

IT部門が講じるべき3つの「封じ込め策」

　リスクが顕在化する前に、Google Workspaceの管理者として管理コンソールで実行可能な3つの具体的なアクションを提示する。

封じ込め策1．監査ログで「隠れPOP利用者」をあぶり出す

　転送設定をする可能性が高い従業員を特定する。これにはGoogle Workspace管理コンソールの「ユーザーレポート」機能が有効だ。

• パス
  • レポート＞ユーザーレポート＞アプリの使用状況＞Gmail
• 確認項目
  • Gmail（POP）の最終使用日時が直近90日以内のユーザーをリスト化する
  • 該当するユーザーに「POP取得使用の有無」を照会する
  • 照会に対する回答と、管理画面の設定を確認し「隠れPOP利用者」を確定する

　ここに日付が入っているユーザーは、Web版Gmail以外のメーラーやPOPフェッチ機能でメールにアクセスしている。特に「IMAP」ではなく「POP」のみを利用しているユーザーは、仕様変更の影響を受ける可能性が高い。

封じ込め策2．管理コンソールで「自動転送」を強制無効化する

　Google Workspaceには、ユーザーによる自動転送設定そのものを禁止する機能がある。

• 設定パス
  • アプリ＞Google Workspace＞Gmail＞エンドユーザーのアクセス＞自動転送
• 設定内容
  • 「ユーザーが自分のメールを別のアドレスに自動転送できるようにする」のチェックを外す。

　この設定を適用すると、ユーザーのGmail設定画面から「転送とPOP/IMAP」タブ内の転送オプション自体が表示されなくなる。さらに、ユーザーが過去に設定した既存の転送設定も無効化される。

封じ込め策3．正規の代替手段へ誘導する

　設定を無効化するだけでなく、業務効率を落とさないための代替案を提示する。2026年以降もGoogleが公式にサポートする手段は以下の通りだ。

• モバイルアプリ（IMAP）の活用
  • スマートフォン版のGmailアプリでは、引き続きIMAP接続によるマルチアカウント管理が可能だ。外出先でのメール確認が主目的であれば、この利用で代替可能だ。
• アカウントの委任
  • チーム内でのメール共有が目的である場合、転送ではなく「メールの委任」機能を使う。パスワードを共有することなく、正規の権限で代理操作が可能になる。