メール送信経路の洗い出し方 — 「送信システム台帳」テンプレート付き

DMARCをp=rejectへ引き上げてよいかどうかは、突き詰めれば一つの問いに行き着きます。「自社のドメイン名でメールを送っているシステムを、すべて言えますか？」

即答できる会社は、ほとんどありません。メール送信は、情シスの知らないところで増殖するからです。この記事では、見落としやすい送信元のリストと、洗い出しの具体的な4ルート、そのまま使える台帳テンプレートを提供します。

見落としがちな送信元リスト

チェックしてみてください。「あ」と思うものが1つはあるはずです。

• 問い合わせフォーム・予約システムの自動返信
• WordPressなどWebサイトからの通知（プラグインが直接送信していることも）
• 請求・会計、採用管理、勤怠、電子契約などの業務SaaS
• CRM・MA・カスタマーサポートツール
• 複合機・NAS・監視機器のアラート送信
• 海外拠点・子会社・外部委託先が契約したツール
• 年に1回しか動かないシステム（年末調整、株主通知、更新案内）

最後の「年1回システム」が最大の伏兵です。1か月のレポート観測では絶対に現れません。

洗い出しの4ルート

ルート1：DMARCレポート【技術面から】

p=noneでDMARCを設定すると、自社ドメイン名で送られたメールの送信元が、世界中の受信事業者から報告されてきます。机上の調査では出てこない「実際に送っているもの」が全部見える、最強の棚卸しツールです（→レポートの読み方）。最低2〜4週間、できれば年次イベントを跨いで観測します。

ルート2：部門ヒアリング【組織面から】

各部門に1つだけ質問します。「お客様や社外にメールが飛ぶツール・サービスを使っていますか？（自動送信含む）」。マーケ、人事、経理、店舗——メールを送るのは情シスではなく現場です。

ルート3：経理データ【契約面から】

SaaSの請求一覧・法人カード明細から、メール送信機能を持ちそうなサービスを抽出します。退職者が契約したまま忘れられたツールは、ここで見つかります。

ルート4：DNSの既存レコード【痕跡から】

現在のSPFのinclude:、_domainkey（DKIM）のレコードは、過去に誰かが設定した送信サービスの痕跡です。「このincludeは何の契約？」に答えられないレコードは、要調査リストに載せます。

送信システム台帳テンプレート

洗い出した結果は、次の形式で1枚にまとめます（コピーしてお使いください）。

台帳の効能は3つ。①reject移行の判断材料になる、②解約時の消し忘れを防げる、③担当者が交代しても「このレコードは何か」に答えられる。

運用ルール — 台帳を死なせない2つの仕組み

1. 入口：新しいSaaS・ツールの導入手続きに「メール送信の有無」チェック欄を設け、有りなら台帳登録と認証設定をセットにする
2. 出口：解約手続きのチェックリストに「DNSレコード削除・台帳更新」を入れる

この2つを回すだけで、台帳は生き続けます。逆にどちらか欠けると、1年で現実と乖離します。

よくある質問

Q. 洗い出しにどのくらい期間を見ればいいですか？

A. ヒアリングと契約調査は1〜2週間で終わります。DMARCレポートの観測は最低2〜4週間。低頻度システムを考慮すると、reject移行までは2〜3か月の計画が現実的です。

Q. 台帳の管理は誰の仕事にすべきですか？

A. DNSを変更できる人（情シスまたは外部委託先の窓口担当）に一元化するのが原則です。分散すると、誰も全体を知らない状態に逆戻りします。

Q. 把握できない送信元が最後まで残りました。止めていいですか？

A. 「誰も知らない＝正規の業務で使われていない可能性が高い」ですが、念のためquarantineを挟んで影響を観測してからrejectへ進むと安全です（→reject移行チェックリスト）。

関連：使っていないドメインの保護｜DMARC設定のやり方