メール認証情報漏洩Web 担当者運用

退職者のメール転送が残るリスク

2026年5月18日ドメイン番人約 5 分で読めます

退職者メール転送のリスク構造

この記事でわかること

退職者のメール転送設定が残ると何が起きるか
棚卸しの具体的な手順
Microsoft 365 / Google Workspace / Exchange での確認場所
再発を防ぐオンボーディング / オフボーディング設計

なぜ「転送設定が残ったまま」が問題なのか

退職者の業務メールアドレス（taro@example.co.jp 等）が、アカウント停止後も次のような状態で残ることが現場で頻繁にあります。

個人 Gmail / プロバイダメールへの自動転送が残っている
退職前に本人が「念のため」と設定した転送ルールが見落とされる
グループメール（info@、sales@）のメンバーに退職者の個人メールが残る

ここに業務メール（取引先・請求書・契約書）が流れ続けると、情報漏洩や金銭被害（請求書詐欺）の温床になります。

ステップ 1: 棚卸し対象を 4 系統に分解

棚卸し前に、転送先の発生パターンを 4 系統に分けて頭を整理します。

個人メールボックスの転送ルール: ユーザーが設定したフィルタ / forward
グループメール（配布リスト）のメンバー: info@、sales@ 等の宛先に残っている個人アドレス
共有メールボックスのアクセス権限: 退職者のアカウントが Send As / Full Access で残っている
メーリングリスト / 外部 SaaS: SendGrid / ML サービスの転送リスト

それぞれ確認場所が異なります。

ステップ 2: Microsoft 365 で確認する

2-1. 個別ユーザーの転送設定

PowerShell で全ユーザーの転送設定を一括取得します。

Get-Mailbox -ResultSize Unlimited | Select-Object Name, PrimarySmtpAddress, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward

ForwardingSmtpAddress / ForwardingAddress に値が入っているユーザーは転送設定済みです。

2-2. Inbox Rule で転送

ユーザーが Outlook 側で個別に設定した「受信ルール」も拾います。

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-InboxRule -Mailbox $_.Identity | Where-Object {
    $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo
  } | Select-Object MailboxOwnerId, Name, ForwardTo, RedirectTo
}

2-3. 配布リストのメンバー確認

Get-DistributionGroup | ForEach-Object {
  Get-DistributionGroupMember -Identity $_.Identity | Select-Object @{N='Group';E={$_.Identity}}, Name, PrimarySmtpAddress
}

退職者のアドレスが残っていないか、または個人 Gmail がメンバーに含まれていないかを確認します。

ステップ 3: Google Workspace で確認する

3-1. 自動転送の確認

管理コンソール → アプリ → Google Workspace → Gmail → 詳細設定で組織全体の転送ポリシーを確認。個別ユーザーは GAM（Google Apps Manager）コマンドラインを使うと一括で取れます。

gam all users print filters
gam all users show forward

3-2. 退職者アカウントのライセンス停止後の挙動

ライセンス停止だけでは転送ルール自体は残ります。アカウント削除前に転送設定をリセットするステップを必ず入れます。

ステップ 4: 共有メールボックスとエイリアス

info@、sales@、support@ など複数人で共有するアドレスは、退職者の個人アドレスが「送信権限」「閲覧権限」で残っているケースが見落としされやすい部分です。

Microsoft 365: 管理センター → 共有メールボックス → メンバー
Google Workspace: グループ → メンバー一覧
Exchange Online: PowerShell Get-MailboxPermission で IsInherited が False のエントリを確認

ステップ 5: 外部 SaaS の通知メール

中小企業で見落とされがちなのが、SaaS の通知メールアドレスです。

Stripe / Salesforce / freee / マネーフォワード等の通知先
SendGrid / Resend / Mailgun の bounce 通知
AWS / GCP のルートアカウントの請求通知

退職者の個人アドレスが残っていると、解約手続きや請求情報が流れ続けます。SaaS の管理画面から通知先を順に確認します。

棚卸し対象 4 系統と確認場所

ステップ 6: 再発防止フロー

退職者対応のチェックリストに次の項目を追加します。

最終出社日 7 日前: 自動転送 / Inbox Rule をスクリーンショット保存 + 棚卸し
最終出社日: 個別転送設定をリセット
退職日: 配布リストから除外
退職 +7 日: 共有メールボックス権限を見直し
退職 +30 日: 外部 SaaS の通知先を確認
退職 +90 日: アカウント削除

サブドメインや WordPress 等で退職者が個人で設定したインフラがあるかも合わせて棚卸ししたい場合は、制作会社にドメインを任せたまま 5 年経った会社の引き継ぎも参考になります。

メール認証側の再点検

退職者対応と合わせて、自社ドメインの SPF / DKIM / DMARC が最新状態か確認します。退職した管理者しか触れない設定が残っていることもあります。確認手順は SPF / DKIM / DMARC の確認方法を参照。

なりすましメールが社内に届いていないかはなりすましメールの確認方法も読んでおきましょう。

まとめ

退職者の転送設定は 4 系統（個別 / 配布 / 共有 / 外部 SaaS）で棚卸し
Microsoft 365 / Google Workspace いずれも PowerShell / GAM で一括取得可能
退職者対応はチェックリスト化して再発防止
ドメインのメール認証側も合わせて再点検

まずは現状を把握しましょう

自社ドメインのメール認証とサブドメイン棚卸しの状況は、ドメイン番人の無料診断で確認できます。退職者対応の見落とし防止にもお使いください。