3ステップで行うなりすまし対策、DMARCポリシー引き上げの実践

1. 対象ドメインの特定

　最初に、自社でメール送信に使用しているドメインを全て洗い出します。会社の代表ドメイン（例: example.co.jp）だけではなく、グループ会社のドメインやメール専用のサブドメイン等も含めて確認してください。どのドメインからメールが送信されているかを把握することが出発点です。

補足：仮にメール送信に使っていないドメインがあっても、後述のDMARCレコードだけ設定しておくことでそのドメインが悪用され、なりすまされることを防ぐことができ安心です（例えばDMARCをp=rejectで設定）

2. 利用メールサービスの確認

　次に、上で特定した各ドメインについて、どのメール送信サービスやサーバーが使われているかを洗い出します。主要な社内メール（例: Microsoft 365 や Google Workspace）だけではなく、ニュースレター配信、システムからの通知メール、外部のクラウドサービスからのメール送信などあらゆる経路を確認します。社内担当者へのヒアリングを行い、「このドメインでメール送信を行っているシステムはほかにないか？」を調べます。

補足：実際の導入では、事前の聞き取りだけでは把握できなかった送信元が後から見つかるケースもあります。DMARCレポートを活用することで、社内認識していなかった外部サービスからの送信も判明した例があります。そのため、後述のレポート確認フェーズで新たな送信サービスが発覚することも念頭に置きましょう

3. SPF・DKIM設定の整備

　各送信サービスについて、SPFレコードの登録とDKIM署名の有効化を確認します。既に多くのサービスでSPFの設定はお済みでしょうが、漏れがあればドメインDNSにSPFレコードを追加します。またDKIMが利用可能なサービスではなるべくDKIM署名を有効化し、公開鍵を自ドメインのDNSに登録してください。

　特に外部のメール配信サービスなどは、オプションでDKIM署名（カスタムドメイン署名）を設定できる場合があります。可能なものは全て設定し、メールヘッダでdkimpassとなることをテストメールで確認します。もしDKIMが提供されていないサービスがあれば、そのサービスから自社ドメイン名でメール送信するのをやめ、サービス提供側の汎用ドメイン（例: service-mail.comなど）を使うことも検討します。

　実際、GMOブランドセキュリティの社内検証では通知機能に使われていた3つの外部サービスが自社ドメインでメール送信していましたが、DKIM未対応だったため送信元ドメインをサービス提供元のドメインに切り替えました。こうした対処により、正規メール送信経路のSPF/DKIM対応度を可能な限り100％に高めることが可能です。

4. DMARCレコードを p=none で追加し、集計レポートの収集開始

　準備が整ったら、DMARCポリシーをnone（監視のみ）でモニタリングを開始します。自社ドメインのDNSにDMARC用TXTレコードを追加し、p=noneを指定します。またDMARC集計レポート（RUA）を受け取る専用メールアドレスを用意し（例：dmarc-reports@自社ドメイン）、そのアドレスをレコードのruaタグに設定します。

DMARCレコード設定例（p=none、RUA送信先指定）

　上図はDNS管理画面でのDMARCレコード設定例です。TXTレコード名は通常_dmarc.<自社ドメイン>とし、値にポリシーや報告先メールアドレス等を記述します。上記例では、次のように記述しています。

　ここでは、「ｐ=none」を設定することで、受信側はメールを拒否せず通常通り受け取りますが、DMARC集計レポートが指定アドレスに送られてくるようになります。主要なメール受信サービス（Gmail、Outlook.comなど）はDMARCレポート機能に対応しており、通常1日ごとにそのドメインから受信したメールの認証結果をXML形式のレポートで送信してきます。まずはこのモニタリング段階でレポートを収集し、自社ドメインのメール送信実態を把握します。

5. DMARCレポートの分析と不合格メールの対策

　p=none運用中は、届いたDMARCレポートを継続的に確認します。レポートには送信元IPアドレスごとにSPFやDKIMの認証結果（PASS（合格）/FAIL（不合格））と受信側で適用された処置（none/quarantine/reject）が記載されています。この段階で重要なのは、正規のメール送信がDMARCでFAIL（不合格）になっていないかを洗い出すことです。

　具体的な確認・対策ポイントは、次項6の通りです。

6. 認証失敗している送信元の調査

　レポート内でdkim=failやspf=failとなっている送信元IPアドレスがあれば、そのIPアドレスが何のサーバーか調査します。社内システムのIPアドレスであれば担当部署に問い合わせ、当該サーバーからメール送信を行っているか確認します。クラウドサービス等であれば提供元を調べ、送信ドメイン認証への対応状況を確認します。必要に応じてDNSの逆引き（dig/nslookupコマンド）やインターネット上の公開情報、WHOISデータベースを使ってIPアドレスの所有者を突き止めます。

7. 設定修正

　原因が判明したら、対応策を講じます。もしその送信元が正規のサービスである場合は、SPFレコードにその送信元を含める、またはDKIM署名を有効化しDNSに公開鍵を登録するといった修正を行います。前述のように、それが技術的に不可能なサービスなら、当該サービスから自社ドメインでメールを送るのを停止する決断も必要です。

　一方、調査した結果、まったく心当たりのない送信元（＝偽メールや第三者中継の可能性）が見つかった場合、それらは将来ポリシー強化時に拒否されるべきなりすましメールと判断できます。そうしたなりすましメールの存在自体もレポートで把握できる点はDMARC導入の利点です。なお、メールの転送（フォワード）やメーリングリスト経由のメールはDMARC認証が失敗する場合がありますが、これらは受信側で自動的に緩和策（ARC等）を適用する場合もあります。本ガイドでは詳細は割愛しますが、必要に応じてそうした特殊ケースも検討してください。

1. ポリシーをquarantineに引き上げ

　DMARCレポートの分析によって正規メール経路の問題を解消できたら、ポリシーを段階的にquarantineへ引き上げます。DNSのDMARCレコードを書き換え、p=quarantineとします。

補足：「pctタグ」でポリシー適用の割合を指定することもできますが、特に理由がなければpct=100で全メールに適用します

　この段階では、DMARC認証に失敗したメールは受信者側で迷惑メールBOXに隔離されるようになります。まずは隔離レベルで運用し、引き続きレポートを監視します。もし万一まだ見落としていた正規メール経路があれば、そのメールが隔離される可能性があります。適切に準備していれば、正規メールが隔離される事態は発生しないはずです。

　実際、GMOインターネットグループ約50社内の検証においても、p=none段階で問題を潰してからp=quarantineに引き上げた結果、正規メールが誤って迷惑メール扱いされるケースは起きませんでした。p=quarantine運用中もレポートは届き続けるので、念のため隔離対象となったメールがないかチェックを続けます。

2. ポリシーをrejectに引き上げ

　最終段階として、DMARCポリシーをrejectに変更します。DNSレコードのp=rejectへ変更後は、DMARC認証に失敗したメールは受信側サーバーで拒否され配信されません。これによりなりすましメールは完全に拒否され、受信者の目に触れることがなくなります。ここまで段階を踏んできたことで、正規メールが拒否されるリスクはほぼゼロになっています。とはいえ、ポリシー変更直後は念のためDMARCレポートや送信メールの配信状況に目を配り、問題がないことを確認すると安心です。