はじめに
こんにちは、サイバーセキュリティチームの宮﨑です。
2025年1月にウェルスナビへ入社し、現在はシステム基盤グループ内のサイバーセキュリティチームで、セキュリティ体制の強化やセキュリティ・バイ・デザインの推進など、幅広くセキュリティ関連の業務に携わっています。
この記事では、「なりすましメール対策」プロジェクトの一環として、私が2025年3月〜7月にかけて取り組んだ技術的な取り組みについてご紹介します。
プロジェクトでは、DMARC（Domain-based Message Authentication, Reporting & Conformance）のポリシーをp=rejectに変更し、BIMI（Brand Indicators for Message Identification）によるブランドロゴ表示までを実現しました。
これにより、当社ドメインの信頼性とセキュリティの向上に貢献できたと考えています。
なお、本取り組みを始めた当初、私は正直なところ DMARCやDKIM、SPFについての知識はほとんどありませんでした。
そこから文献や他社事例を参考にしながらインプットを進め、DMARC RUAレポート解析ツールを自作したり影響調査を進めるうえで少しずつ理解を深めていきました。
また、事業会社のセキュリティエンジニアとして、初めて非エンジニアの他チームに対してセキュリティリスクを説明する機会がありました。
会社全体のセキュリティ強化に繋がっただけでなく、ハードスキル・ソフトスキルの両面で大きく成長できた取り組みでした。
本ブログについて
対象読者
本記事は、以下のような方々を対象としています。
- 企業内でメール基盤（送信ドメインやメールサーバ）を管理している方
- DMARCやBIMIの導入・設計を検討しているセキュリティ担当者、SRE、または情報システム部門の方
- ブランド保護やなりすまし対策に取り組む情報セキュリティチームの方
- 特に、金融業界など高いセキュリティ対策が求められる業界における事例に関心のある方
記事の内容
この記事では、当社が管理している正規ドメインに対して実施したDMARCおよびBIMI導入の事例をご紹介します。
プロジェクトの背景や技術的な課題、社内調整のプロセスを時系列で振り返りつつ、DMARCやBIMIの技術的要素についても解説しています。
これから導入を検討している方が、実装と運用のリアルなイメージを掴む手助けになれば嬉しいです。
※本記事の内容はあくまで当社の一例です。設定内容やポリシーの変更については、各組織の運用方針やシステム構成を踏まえてご判断ください。
当社なりすましメール被害の状況
今回、DMARCとBIMIの導入に至った背景には、実際に当社のドメインを悪用したなりすましメールの増加がありました。
まずは、その被害状況やメールの傾向について簡単にご紹介します
当社なりすましメールの特徴
今回の取り組み期間中、観測されたなりすましメールの特徴としては、送信元のFromドメインに当社の正規ドメインが悪用されている一方で、メールの件名や本文には他社名が使われているというものでした。
| 観測項目 | 内容 |
|---|---|
| 送信元ドメイン（From） |
xxxx@wealthnavi.jp（実在しないユーザー） |
| 表示名 | 実在の他社名やサービス名 |
| 件名・本文の内容 | 他社を装ったフィッシング目的の内容 |
そのため、直接的に当社お客様が被害を受けるケースは観測されておらず、影響は限定的でした。
しかし、当社ドメインが攻撃者に悪用されている事実や、将来的に当社を騙るフィッシングメールが現れるリスクを踏まえ、早急な対策が必要と判断しました。
なりすましメールの件数
世界中のDMARCに対応したメールの受信サーバーから送られてくるDMARCレポートを集計したところ、2025年5月の1ヶ月間で、当社ドメインを送信元として偽装したなりすましメールが約370万通観測されました。
これは、同月にDMARCレポート上で確認された当社ドメインの全送信メールの約37%に相当します。
なお、DMARCレポートは一部の受信サーバーからのみ提供されるため、実際のなりすまし件数はこの数値を上回っていた可能性があります。
こうしたなりすましメールの多くは、実際には迷惑メールフォルダへ振り分けられたと考えられますが、どの程度の割合がそうであったかは判別できていません。
また、送信元IPを分析した結果、世界各国から分散的に送信されていたことが確認できました。
その中でも中国が最も多く約110万通のなりすましメールが1ヶ月で送信されていました。
| 上位10件 | 国名 | 件数 | 割合 |
|---|---|---|---|
| 1 | China | 1,116,039 | 30.16% |
| 2 | Japan | 741,852 | 20.05% |
| 3 | Unknown（逆引き不可） | 552,703 | 14.94% |
| 4 | Brazil | 463,308 | 12.52% |
| 5 | Singapore | 406,742 | 10.99% |
| 6 | Vietnam | 59,335 | 1.60% |
| 7 | Argentina | 37,141 | 1.00% |
| 8 | Russia | 27,367 | 0.74% |
| 9 | Morocco | 24,719 | 0.67% |
| 10 | Tunisia | 22,122 | 0.60% |
全体の時系列
ここでは、当社がDMARCおよびBIMIの導入に至るまでのプロジェクトの流れを、時系列で振り返ります。
技術面だけでなく、社内調整や広報面も含めた時系列にしているため、導入を検討している方々の参考になれば幸いです。
| 時期 | 内容 |
|---|---|
| 2024年1月 | Gmailの送信ガイドラインに対応するため、初めてDMARCをp=noneで導入。この時点ではガイドラインへの対応が目的。 |
| 2025年1月 | 顧客からなりすましメールに関する問い合わせが複数発生。Google Postmaster ToolsでドメインのDMARC認証低下も確認され、対応の必要性が浮上。 |
| 2025年2月 | なりすましメールへの注意喚起のお知らせをリリース。社内で明確な運用体制がなかったDMARC対応を、サイバーセキュリティチームが引き取り。 |
| 2025年3月 | 自作ツールでDMARCレポートを解析し、被害の実態を定量的に把握。 |
| 2025年4月 | 商用のDMARCレポート分析ツールを導入し、自動集計・可視化体制を構築。本格的な傾向分析と調査を開始。 |
| 2025年5月 |
p=rejectの適用に向けた影響調査を進めつつ、BIMI導入準備もスタート。各技術チームのリーダーが集まる会議で方向性の合意を取り、VMC取得に向けた審査対応なども対応。 |
| 2025年6月 |
p=rejectの適用について経営層から最終承認を取得。CS・広報チームと連携し、プレスリリースやFAQの準備、外部向け説明の整備を実施。 |
| 2025年7月 | DMARCポリシーを正式にp=rejectに変更。BIMI導入も完了し、主要メールサービスでブランドロゴの表示が可能に。広報・CS連携によるお客様告知も展開。 |
技術対応の詳細
全体の流れを踏まえたうえで、ここからは実際に私が担当した技術面での対応や調査内容について、もう少し詳しくご紹介します。
特にDMARC導入の初期対応から、BIMI導入に至るまでの検証・実装・ツール選定など、技術的な観点でどのようなことを行ったのか、実務ベースで振り返っていきます。
なりすましメール対策に関連する専門用語
以下では、DMARCやBIMIなどのメールセキュリティに関する専門用語を簡単にご紹介します。
すでにご存知の方は、この項目は読み飛ばしていただいて問題ありません。
現在学習中の方向けに、用語の意味を簡潔にまとめた表をご用意しました。
| 用語 | 目的 |
|---|---|
| SPF | Return-Pathのドメインが許可したIPアドレスから送信されているか検証する仕組み |
| DKIM | メールが改ざんされていないか、電子署名を用いて検証する仕組み |
| DMARC | SPFとDKIMの検証結果およびアライメント（FromヘッダとReturn-PathやDKIM署名ドメインとの整合性）を基に、受信サーバーがポリシーに応じた処理（none/quarantine/reject）を行う仕組み |
| BIMI | DMARCポリシーをquarantineまたはrejectに設定し、DMARC認証に成功したメールに対してブランドロゴを表示し、正規メールであることを視覚的に示す仕組み |
| ARC | メール転送時にDMARC認証が崩れることを防ぐために、転送者による認証情報を記録・伝達する仕組み |
DMARCの導入
2024年1月、Gmailの送信ガイドラインが変更され、1日5,000通以上のメールを送信するドメインにはDMARCの設定が必須（none/quarantine/reject問わず）となりました。
当社の送信量もこの基準に該当していたため、まずはp=noneのポリシーでDMARCを導入し、ガイドラインへの準拠を行いました。
この時点では、隔離（quarantine）や拒否（reject）といった厳格なポリシーは適用せず、
送信ドメインの認証整備と、対外的なポリシー提示を目的とした導入です。
DMARCの設定は、wealthnavi.jpドメインに対して以下のようなTXTレコードをインフラを管理しているチームに依頼し、追加しました。
実際のレコード（一部マスキング）
- ホスト名：_dmarc.wealthnavi.jp
- レコードタイプ：TXT
- 値（レコード内容）：v=DMARC1; p=none; rua=mailto:{RUAレポートを受信するメールアドレス}
この設定により、Gmailの要件に準拠した状態となり、受信サーバーからのDMARCレポート（RUA）も受信できるようになりました。
なりすましメールの増加
2025年1月、当社のお問い合わせ窓口に「当社名義の不審なメールを受け取った」という報告が複数寄せられました。
この時点では、DMARCのポリシーはp=noneのままで、受信者側のサーバーでは明示的なブロックが行われていない状態でした。
当時、DMARC認証の状況を確認できる手段としては、Google Postmaster Toolsしかなく、そこで当社ドメインの評価スコアを確認したところ、成功率が大きく低下していることがわかりました。
Google Postmaster Tools上のDMARC認証成功率低下
このことから、なりすましメールによる影響が出始めている兆候が見られ、より踏み込んだ分析と対応の必要性を感じました。
ただし、Postmaster Toolsで確認できるのはGmail経由の配信状況と評価スコアのみであり、Yahoo!メールやOutlook.comなど他の主要サービスでの認証状況は把握できません。
また、Postmaster Toolsでは「認証成功率」は確認できるものの、実際にどのIPアドレスから、どれだけのなりすましメールが送られているのかといった詳細情報は取得できません。
そこで、当社ではDMARCレポート（RUA）を活用し、全世界の受信サーバーから集まる情報をもとに、より包括的な分析を行う方針を決定しました。
自作分析ツールによるDMARCレポートの可視化
まず着手したのは、DMARCレポート（RUA）を活用した認証状況の可視化ツールの内製化です。
RUAに指定していたメールアドレス宛に届くXML形式のDMARC集計レポートを解析することで、認証失敗の傾向や、なりすましの実態を把握可能です。
このフェーズの目的は、従来のGoogle Postmaster Toolsでは把握できなかった、Gmail以外の受信サーバーも含めた認証成功率の可視化です。
RUAレポートから得られる主な情報
- 送信元IPアドレスごとの送信件数
- SPF/DKIMそれぞれの認証結果（pass/fail）
- SPF/DKIMのアライメント結果（aligned/mismatch）
- 送信元のドメイン（Fromヘッダ）
- なりすましの発生パターン（特定IPに集中しているか）
- レポート送信元（例：Google, Yahooなど）
- 適用されていたDMARCポリシー（
none/quarantine/reject） - ARCの適用状況（報告がある場合）
RUAレポートから得られない情報
- 実際のメール本文・件名・添付ファイルなどの内容
- SPF/DKIMがfailした詳細な技術的理由
- メールが迷惑フォルダに入ったか、最終的に誰に届いたか
- 実際のユーザー被害（開封やクリック）に関する情報
ツール構成と自動化の工夫
RUAレポートは内容が詳細でファイル数も多く、手動での確認は現実的ではありませんでした。
そのため、Google Apps Script（GAS）とPythonを組み合わせた自動処理の仕組みを構築しました。
- GASで、Gmailに届いたDMARCレポート（XML添付）を定期的に検出し、Google Driveに保存。
- 翌日、ローカル環境のPythonスクリプトにより、保存されたXMLファイルを一括ダウンロード。
- Pythonでレポートをパース・集計し、Googleスプレッドシートに日次データとして記録。
GASのみで完結させる構成も検討しましたが、GASの実行時間制限によりスクリプトが途中で停止することが多く、また処理性能の観点からもPythonを組み合わせた方が効率的でした。
以下は、日次で収集・集計したレポートの可視化例です。
自作ツールによる出力結果
さらに、集計結果を月単位でスプレッドシートに整理することで、1ヶ月間のおおよそのDMARC認証成功率を求めることができました。
自作ツールを用いた集計結果
分析結果と得られた知見
この仕組みによって、以下のような重要な事実を定量的に把握できるようになりました
- なりすまし送信が日常的に発生している
- 想定外の送信元からの大量送信が存在している
これらの知見は、DMARCポリシーを強化するうえでの重要な判断材料となりました。
商用ツールによるDMARCレポートの分析
自作ツールにより、DMARCの認証成功率を日次で可視化することには成功しましたが、
継続的な監視や、攻撃傾向の深掘り、他部門との情報共有といった運用面を考慮すると、自作では限界があると判断しました。
特に以下のような課題がありました。
- 各IPアドレスの属性（地理情報やASなど）を毎回調査する必要がある
- 組織全体で俯瞰できるビューやダッシュボードの整備が難しい
- 複数ドメインを横断して一元管理するニーズが出てきた
こうした背景から、2025年4月よりDMARCレポートの可視化サービスを複数比較検討し、
最終的に、以下のような機能を備えたSaaS型のDMARC分析ツールを導入しました。
- UIベースでのDMARCレポートの可視化（送信元IP単位やドメイン別）
- SPF/DKIM/DMARCの認証成功・失敗・転送の割合と件数の自動集計
- SPF/DKIM失敗傾向のグラフ化と時系列分析
- RUAレポートの自動収集・解析・保管
- 送信元IPに関するWHOIS、地理情報、AS番号の自動取得
- インテリジェンス情報を元にした怪しい送信元のハイライト表示
- 複数ドメイン／サブドメインを統合管理できるビューの提供
これにより、DMARC関連のモニタリングや影響調査を継続的かつ省力的に行える体制が整いました。
特に、セキュリティチーム以外の関係者とも画面を共有しやすくなったことは、大きな効果のひとつです。
DMARCポリシーのReject化
商用ツールによってRUAレポートの詳細な可視化・分析が可能になったことで、DMARCポリシーをnoneからrejectへ強化するための影響調査を本格的に開始しました。
まず技術的な懸念点を整理し、以下の観点から検証を行いました。
- 当社から送信している正規メールが、DMARC認証で失敗していないか
- 転送メールが認証に失敗した場合、受信者側でどう処理されるか
- ARC（Authenticated Received Chain）の導入状況と、その適用割合
特に慎重に確認したのが、ログイン時に送信される追加認証コード（ワンタイムコード）付きのメールです。
当社では2025年6月以降、このコードをメールで配信する運用を導入しており、万一このメールがDMARCの影響でブロックされると、お客様がサービスを利用できなくなるリスクがありました。
追加認証コードのイメージ
調査内容と分析結果
約3ヶ月にわたり、以下のような観点から技術的・運用的な調査と分析を進めました。
- RUAレポートをもとに、正規メールと転送メールの認証通過率を定量的に分析
- SPF/DKIMが失敗したケースにおけるARC適用の有無を確認し、カバレッジを算出
この結果、以下のことが確認できました。
- 正規直送メールは SPF/DKIM ともに認証成功し、問題なし
- 転送メールはDKIMにより多くが保護されており、認証失敗はごく一部に限定
- 転送メールでSPF/DKIMがともに失敗したケースでも、9割以上はARCにより信頼継承されていた
- なりすましメールの送信は依然として大量に確認され、Rejectポリシーによる遮断が有効
ただし、転送メールの取り扱いについては当社側（送信元）での制御ができないため、万一メールが届かなくなるケースを想定し、「転送元のメールの確認」「メールアドレスの変更」の案内をニュースページにて共有しました。
転送メールに関するお知らせ
Reject化の判断と施策
これらの結果を踏まえ、DMARCポリシーをrejectへ移行する判断に至りました。
リリースにあたっては、CS部門と連携し以下の対応も行いました。
- お客様向け案内記事の公開
- よくある質問（FAQ）の整備
- 問い合わせ時の対応方針の明確化
そして、2025年7月15日、当社ドメインにおけるDMARCポリシーを正式に以下のように変更しました。
- ホスト名：_dmarc.wealthnavi.jp
- レコードタイプ：TXT
- 値（レコード内容）：v=DMARC1; p=reject; rua=mailto:{RUAレポートを受信するメールアドレス}
digコマンドの結果
% dig _dmarc.wealthnavi.jp txt +short
"v=DMARC1; p=reject; pct=100; rua=mailto:{RUAレポートを受信するメールアドレス}; ruf=mailto:{RUFレポートを受信するメールアドレス}"
適用後の変化
この変更により、SPFやDKIM認証に失敗したメールは受信側で明確に拒否されるようになり、なりすましメールによるリスクを大幅に軽減することができました。
下図は、Reject化後のRUAレポートの一部です。
赤枠部分では、SPFまたはDKIM認証に失敗したメールがreject処理された様子が確認できます。
DMARC認証失敗したメールにrejectポリシーが適用されている様子
BIMIの導入
DMARCのポリシーをp=rejectに設定することで、BIMIの導入要件を満たすことができました。
BIMIは、対応メールサービス（例：Gmail、Yahoo! Mailなど）上で、送信ドメインにブランドロゴを表示できる仕組みです。
メール受信画面のイメージ
商標登録とブランドロゴ画像の準備
BIMIでロゴを表示するには、商標登録済みのロゴを用意する必要があります。
これは、ロゴの正当性を証明するVMC（Verified Mark Certificate）を取得する際に必須の要件です。
当社では、すでに商標登録済みのブランドロゴがあったため、それをBIMIにそのまま活用しました。
なお、未登録のロゴを新たに登録する場合は、商標登録に通常5〜8ヶ月程度かかるため、導入を検討している場合は早期の準備が重要です。
SVG Tiny 1.2形式への対応
BIMIで使用するロゴ画像は、SVG Tiny 1.2形式に準拠している必要があります。
しかし、一般的なSVGファイル（例：IllustratorやFigmaでの書き出し）では、この仕様を満たさないケースが多いため、対応にはいくつかの注意が必要でした。
当社では以下の対応を行いました。
- デザインチームにSVG Tiny 1.2の仕様を事前に共有し、ロゴを仕様に沿って出力してもらうよう依頼
- 出力されたSVGをテキストエディタで開き、JavaScriptの記述や外部フォント参照、アニメーション要素など、SVG Tiny 1.2で禁止されている要素をすべて手動で削除（この作業は筆者が対応）
BIMI対応ロゴは制約が多いため、仕様共有 → 中間チェック →最終確認といったプロセスをしっかり作っておくことが重要です。
VMCの取得審査
VMCを取得するにあたり認証局と以下の審査対応が必要でした。
申請者（個人）の本人確認やビデオ通話対応が必要となるため、誰を申請者にするかはプロジェクト初期に決めておくとスムーズだと感じました。
また、代表電話に突然の確認連絡があるため、対応チームへの事前共有も重要です。
| 認証項目 | 対応内容 |
|---|---|
| 組織情報の登録 | 認証局が管理するプラットフォーム上で自社や申請者の情報を入力（当社では社内ルールに従い事前にSaaS利用申請を実施） |
| 電話認証（組織確認） | 申請組織の代表番号宛に認証局から電話があり、担当者が対応 |
| ドメイン認証（DCV） | 申請組織のドメインに紐づけている指定アドレスに送られるメールで所有確認を行う |
| 個人認証（申請者） | 顔写真付きの身分証明書を提出し、Zoom通話で本人確認（例：免許証やマイナンバーカード） |
| ロゴの商標確認 | BIMIで使用するロゴに対して、商標登録番号と登録機関を提出 |
| 発行最終承認 | すべての認証完了後、申請者宛に届くメールから承認操作を行い、VMCが発行される |
DNS設定変更
商標登録情報をもとに、VMCを認証局から取得しました。
その後、以下の内容でインフラを管理しているチームに依頼し、BIMIレコードをDNSに追加しています。
- ホスト名：default._bimi.wealthnavi.jp
- タイプ：TXT
- 値：v=BIMI1; l=https://static.wealthnavi.com/images/bimi/wealthnavi_inc.svg; a=https://static.wealthnavi.com/images/bimi/wealthnavi_inc.pem
実際のレコード
% dig default._bimi.wealthnavi.jp txt +short
"v=BIMI1; l=https://static.wealthnavi.com/images/bimi/wealthnavi_inc.svg; a=https://static.wealthnavi.com/images/bimi/wealthnavi_inc.pem"
BIMIのロゴとPEMファイルはHTTPSでアクセスできる必要があります。
事前にインフラチームと会話して、どのようなフォルダ階層にするかなど決めました。
BIMI導入後の変化
BIMI導入後、Gmailなどの対応メールクライアント上で、当社のブランドロゴが表示されるようになりました。
BIMI導入前
従来はGoogleアカウント上で設定している画像が受信者側がGmailであれば表示されていました。そのため、攻撃者も容易にマネができる状態でした。
また、受信者側が他のメールプロバイダを利用していた場合は表示されずお客様にとっては不親切な状態でした。
BIMI導入前
BIMI導入後
BIMIの導入後、BIMIに対応したメールプロバイダを利用されていた場合は商標登録済みのロゴが表示されるようになりました。
BIMI導入後
また、受け取り側がGmailを利用している場合は認証マークもつくようになり、視覚的に正規メールであることがわかりやすくなりました。
DMARCを通過したメールに表示された認証マーク
認証マークの説明
これにより、お客様に対してブランドの正当性を視覚的に示せるようになり、なりすまし対策としてだけでなく、メールコミュニケーション全体の信頼性向上にもつながっています。
一方で、SVG仕様の厳格さやVMC取得の手間（申請〜審査）など、導入には一定の工数とスケジュール管理が求められます。
そのため、導入を円滑に進めるには、関係部門との連携や段取りの明確化が欠かせません。
最後に
今回の取り組みを通して、DMARCやBIMIといった技術の理解を深めるだけでなく、複数の部署と連携して1つのゴールを目指すという貴重な経験を得ることができました。
セキュリティは技術だけで完結するものではなく、影響を最小限にしながら正しく導入し、伝えることが非常に重要だと再認識しました。
DMARCのp=reject化とBIMIの導入により、当社のドメインの信頼性は明らかに向上し、お客様にとってもより安心してメールを受け取っていただける状態が整ったと感じています。
これからも、お客様に見えづらいところで支えるセキュリティ対策を一歩一歩丁寧に進めていきたいと思います。
最後までお読みいただき、ありがとうございました。
筆者プロフィール
システム基盤グループ サイバーセキュリティチーム
セキュリティエンジニア
宮﨑（みやざき）
Discussion