Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

なりすましメール対策 BIMIを導入した経験の共有

こんにちは、マネーフォワードCISO室セキュリティガバナンス部の亀井です。 個人情報やクレジットカード情報保護に関する統制の策定・運用、そして外部認証取得の業務を担当しています。 マネーフォワード / マネーフォワードケッサイでは、なりすましメール対策の強化のため、自社から送付するメールにブランドロゴを表示するBIMI(Brand Indicators for Message Identification)を導入しました。 本記事では、私たちのBIMI導入の具体的な経緯と取り組みについてご紹介します。

なりすましメール対策の目的

近年、フィッシングの被害が増加しています。フィッシングサイトは精巧になり、見た目だけで正規のサイトと見分けることは非常に困難です。そして、こうした悪質なフィッシングサイトへの誘導には、しばしば巧妙ななりすましメールが利用されています。 フィッシングメール以外にも当社を騙るスパムメールが横行すれば、ユーザーの利便性が低下し、ブランドイメージが毀損される恐れがあります。 これらへの対策としてフィッシング対策協議会のフィッシング対策ガイドラインでは、重要5項目の筆頭に「利用者に送信するメールでは送信者を確認できるような送信ドメイン認証技術等を利用すること」が挙げられています。 BIMIを導入することで、対応するMUA(Mail User Agent:GmailやYahoo!メールアプリなど)では受信者のメールボックス上で企業のブランドロゴが表示されるようになります。このブランドロゴにより、受信者はそのメールが正規のものであることを視覚的に、かつ迅速に確認できるようになるため、なりすましメールを見分けることが格段に容易になると期待しています。

BIMIイメージ

BIMIを利用することで、受信者のメールボックス上で商標登録済みのロゴを表示することができます。 受信メールボックスに表示されるBIMIロゴのイメージ(商標登録済みのロゴが送信元の隣に表示される様子)

BIMI導入にはDMARCへの対応が必要

BIMIは、DMARC(Domain-based Message Authentication, Reporting & Conformance)と認証マーク証明書(VMC: Verified Mark Certificate)という、二つの要素によって構成されています。 DMARCは、送信ドメイン認証の仕組みです。これは、受信メールの送信元ドメインが正当な所有者から送信されたものであるかを検証するためのプロトコルを提供します。具体的には、メールの送信元が事前に設定された認証情報(SPF:Sender Policy FrameworkやDKIM:DomainKeys Identified Mail)と合致するかを確認し、その結果に基づいてメールの取り扱いを決定します。

DMARCのポリシーを設定することで、送信ドメイン認証に失敗したメールの挙動を詳細に制御することが可能になります。ポリシーには以下のいずれかを指定します。

  • None(監視のみ): このポリシーでは、送信ドメイン認証が失敗したメールに対する具体的な保護措置は講じられません。DMARCレポートを生成し、認証状況を監視する目的で使用されます。
  • Quarantine(隔離): 認証されていないメールを「迷惑メールフォルダ」に移動させるなど、フラグ付けや隔離を行います。受信者に届くものの、注意を促す形になります。
  • Reject(拒否): 認証されていないメールの受信トレイへのアクセスを完全にブロックし、受信者のメールボックスには届かないようにします。これは最も厳格なポリシーです。

BIMIの導入には、DMARCポリシーが「Quarantine」または「Reject」のいずれかに設定されている必要があります。 BIMI導入以前、私たちはDMARCポリシーを「None」で運用していました。これは、メール認証状況のモニタリングは行っていましたが、認証に失敗したメールに対する強制的な措置は講じていなかったことを意味します。そのため、BIMI導入の第一歩として、このDMARCポリシーをより厳格な「Quarantine」または「Reject」へ見直すことから活動を開始しました。

DMARCポリシーの見直し=DMARCレポートの分析

DMARCポリシーを「Quarantine」または「Reject」へ変更するには、当社から送信される全ての正規メールが、送信ドメイン認証を通過(Pass)する必要があります。もし正規のメールが認証に失敗した場合、受信側のメールサーバーによって隔離されたり、拒否されたりするリスクがあるため、重要なステップです。 まず、私たちはDMARCレポートの分析に着手しました。DMARCレポートは、メールを受信したサーバーが、日次で当社のドメインが指定するメールアドレス宛に送付してくれます。つまり、毎日、当社のドメインからメールを受信した世界中の様々なメールサーバーからレポートが送られてくるため、その量は膨大になります。 この大量のDMARCレポートを効率的に分析するためには、専門の分析ツールが不可欠でした。当初はフリーツールでの分析も試みましたが、後述するSPFレコードのDNSルックアップ10回制限への対応も合わせて解決できるという利点から、最終的に「PowerDMARC」の利用を決定しました。 「PowerDMARC」を活用してDMARCレポートを分析した結果、いくつかの外部メールサービスにおいて、適切に送信ドメイン認証が行われていない正規のメールが存在することが判明しました。

DMARCポリシーに準拠していないメールサーバの表示画面

PowerDMARCの管理画面でDMARCポリシーに準拠していないメールサーバーを表示している画面

メール設定の見直し

DMARCレポートの分析で明らかになった課題を受け、私たちは送信メール設定の包括的な見直しを行いました。 IT管理者が管理しているサービスからのメール配信については適切な設定がされていましたが、マーケティングやカスタマーサポートなどが独自にSaaS型サービス経由での顧客とのメール送受信しているケースでは、IT管理者の管理が行き届かず、適切な送信ドメイン認証設定ができていないメールが存在していました。 DMARCでは、メール認証プロトコルであるSPFとDKIMのどちらか一方でも認証を通過すれば、DMARC認証もPassすることが可能です。DMARCをPassするだけであればどちらか一方に対応すれば十分ですが、私たちはDKIMとSPFの両方に対応することが望ましいと考えています。これは認証強度を双方で補完し合うという理由に加えて、DKIMはDNSクエリのタイムアウトやレコード取得失敗により、正当なメールにもかかわらず認証に失敗するケースがあるためです。そのような場合でも、SPFが適切に設定されていればメールが正常に受信者に届けられる可能性が高まります。 DKIMまたはSPFのどちらかのみ対応可能という外部サービスも存在しましたが、対応可能なサービスでは両方を設定するようにしました。

次に課題となったのが、RFC7208で規定されているSPF設定におけるDNSルックアップ10回制限への対応でした。当社では前述の通り、マーケティングサービスやカスタマーサポートサービスといったSaaSを活用することで業務の効率化を図っています。これら外部サービスごとにSPFレコードを登録していくと、SPFレコードの記述が多くなり、結果としてDNSルックアップ回数が制限値を超過してしまうという問題に直面しました。

PowerDMARCの分析機能で問題点を認識

PowerDMARCの分析機能でSPFレコードのDNSルックアップ回数を表示し問題点を可視化している画面

この問題も「PowerSPF」を活用することで解決することができました。「PowerSPF」に必要なSPFレコードを登録すると、約20分ごとにそれらのSPFレコードに含まれるIPアドレスを収集し、事前に一つのIPアドレスリストに変換してくれます。受信側のMTAがSPFレコードを要求すると、「PowerSPF」はSPFマクロ構文を利用した最適化されたSPFレコードを返却するため、このルックアップ制限を効果的に回避することが可能になります。これにより、SPFで設定可能な許可MTAリストに制限が無くなり、SPFとDKIMの双方で認証が可能な送信ドメインを増やすことができました。

DMARCポリシーの変更とBIMIの設定

当初からDMARC認証通過率は90%を超えていました。認証に失敗したメールについて、私たちは送付件数の多い主要なメール送信元から優先的に調査と対応を進め、正規のメールについては設定の追加や修正を行いました。これによりさらに認証通過率が上昇しました。 送信数が一定以上のメールサーバーについて、DMARC認証をPassする状態を確認した後、DMARCポリシーの変更に踏み切りました。一定数以下のメールサーバーでは設定不備により正常なメールが不通となるリスクはあります。しかし、この時点では不正なメールも含まれていることから、全件を調査することは非効率的です。そのため、最終的にはメールが届かなくなった場合の対応を整備した上で、社内の理解を得て変更を推し進めました。 メール送信の状況がPowerDMARCにより可視化されていることも決断の後押しをしてくれたと思います。 DMARCポリシーの変更後、BIMIレコードを設定し、無事にBIMI導入を完了することができました。これにより、当社の正規メールにブランドロゴが表示されるようになりました。

まとめ

対応を振り返ると、いくつかの学びがありました。 まず、BIMIの導入にはDMARCポリシーの厳格化が必要となり、このプロセスで適切な分析ツールを利用することが、プロジェクトを効率的に推進する上で不可欠だったと感じています。分析ツールは、傾向分析はもちろんのことポリシー変更後に発生しうる不着メールの調査においても、迅速な原因特定に貢献してくれました。ログ分析は地道な作業になりがちであるため、こうした便利なツールの活用が重要と考えます。 次に、DMARCポリシー変更による効果です。DMARCポリシーを厳格化したドメインでは、認証をパスしないメールの件数が劇的に減少しました。

2025/5-7のDMARC準拠/非準拠の推移

2025年5月から7月のDMARC準拠メールと非準拠メールの推移を示すグラフ(非準拠メールが劇的に減少している様子)

「Quarantine」に変更したドメインでも同様の傾向が見られました。この結果から、以下の2つの点が考えられます。 一つは、「Quarantine」ポリシーもスパムメールの一定の抑止効果を持つということです。スパムメールを送信する組織も費用対効果を重視しており、迷惑メールフォルダに隔離されるメールを配信し続けることはコストに見合わないと判断しているのでしょう。ただし、受信トレイへの到達を完全にブロックする「Reject」ポリシーへの変更が望ましいと考えます。 もう一つは、配信されなくなったスパムメールの行方です。コストを理由に配信を停止したリソースは、単に別のドメインからのスパムメール配信に転用されている可能性があります。これは、セキュリティ対策が後手に回ると被害を受けるリスクが高まる可能性があり、世間の対応から劣後しないことの重要性を示唆していると思います。

一部の外部サービスを利用した送信メールの管理が不十分であったことが、BIMI導入の足かせとなってしまいました。運用の不備がセキュリティ的な「負債」とならないようにBIMI/DMARCの運用体制を確立し、継続的に維持・改善していきたいと思います。 本記事が、これからBIMI導入を検討されている方々の一助となれば幸いです。

最後に、マネーフォワードは、お客様と会社の資産を守るという思いのもと、セキュリティの最前線で共に挑戦し、未来を切り拓いていく仲間を求めています。セキュリティ領域でキャリアを築きたい方、新しい技術に積極的に挑戦したい方は、ぜひ当社の採用情報をご覧ください。