昨今、実在する人物や組織を偽り、電子メールを送付する「なりすましメール」による被害が増加・拡大しています。IPA（Information technology Promotion Agency, Japan）から発表されている「情報セキュリティ10大脅威 2023」では、「ビジネスメール詐欺による金銭被害」が第7位に位置付けられています[1]。
受信者（被害者）が、なりすましメールを本物のメールとして扱うことで、最終的にはマルウェアに感染したり、金銭を要求されたり、重要情報が漏洩したり、被害を受けたりする恐れがあります。また、これらのサイバー犯罪は詐称された企業のブランドイメージや信頼性を脅かすだけでなく、顧客やパートナーとの信頼関係にも影響を及ぼします。
こういった被害の予防や対策として、「DMARC」と呼ばれる技術の活用が推奨されています。DMARCは、送信者ドメインがSPFやDKIMにより認証されているドメインかどうかに基づいて、受信者に対してメール処理方式を指定できる電子メール認証技術です。
また、送信ドメインは受信者から定期的にDMARCの結果を「DMARCレポート」として受け取ることができます。このDMARCレポートに従いSPFやDKIMの設定やDMARCポリシーを適切に設定することで、自社になりすましたメールやスパムメールから受信者を保護し、自社ブランドを保護することが可能になります。
本記事では、なりすましメールなどを防ぐための技術であるDMARCと、受信メールサーバからフィードバックされるDMARCレポートについて解説します。
DMARC以前のメール送信ドメイン認証技術には、DKIMやSPFが利用されてきました。
DKIMは、送信サーバ内に有する秘密鍵で生成した署名をメッセージヘッダにDKIM-Signatureとして付与します。受信サーバは DKIM-Signatureのdパラメータに指定されたドメインのDNSに登録されている公開鍵を用いて、付与された署名を検証することで、送信ドメインを認証する技術です[2]。
SPFは、受信者がエンベロープFromドメインのDNSサーバからSPFレコードをひいて、この送信元サーバのIPアドレスが含まれているか確認することで、送信サーバの正当性を検証する技術です[3] 。
しかし、DKIMやSPFには幾つか課題が存在します。
DMARCでは、SPFやDKIMの課題を解決するために、ヘッダーFromドメインの認証や送信者と受信者で相互に情報共有を行います。DMARCはヘッダーFromドメインを利用し、DKIMとSPFを組み合わせて利用し、DKIMとSPFの認証に通過したドメインがヘッダーFromドメインであるか確認します[4]。
DMARCを利用することで、以下の効果を享受することが可能になります。
DMARCはヘッダーFromドメインを利用します。これにより、利用者が差出人の識別に利用するヘッダーFromドメインの適切さを確認することができます。なお、文字の形が似ている（見た目が似ている）ドメイン（ドッペルゲンガードメイン）を用いた詐欺メールを防ぐことはできません。
SPF/DKIMで検証したドメインとヘッダーFromドメインが相違していてDMARC検証に失敗した場合の受信ポリシーを提供できます。これにより、送信者（送信ドメイン管理者）が検証に失敗したときにメールを受信してほしいか、適切なSPF/DKIMを設定済であることから拒否を前提としてほしいか、明確に指定することができます。
DKIMとSPFは送信者の指定したポリシーに沿って、受信サーバが評価し処理します。送信者はこの評価結果を受け取る仕組みがなく、設定が正しいか、厳格なポリシーとしたときに意図せず破棄されていないか、確認することができませんでした。
DMARCは、DMARCレポートを受け取るための設定を提供しています。送信者は受信サーバが実施したDMARC検証結果をDMARCレポートとして受け取ることができるので、受信したDMARCレポートを分析することで、SPFとDKIMの設定を効果的にチューニングすることが可能です。
BIMI はDMARCにより認証成功と判断されたメールにブランドロゴを表示させる送信ドメイン認証技術です。受信者は受信メールのブランドロゴを確認することにより、正規の送信元からのメールであることを確認することができます。
これにより、なりすましメールの防止につながる他、ブランドロゴの認知度の向上やメール閲覧率の改善につながります。
DMARCはDKIM/SPFと同様に受信側のメールサーバで評価・処理をします。DMARC検証ではヘッダーFromドメイン（RFC5322.Fromドメイン）が、DKIMとSPFの検証に利用したドメインと整合（一致）しているか確認します。一致している場合はメールボックスへの配信がされます。
DMARCは、ヘッダーFromドメインに対して公開されているDMARCポリシーを取得します。ヘッダーFromドメインがSPFまたはDKIMを通じて検証されない場合、そのメッセージは受信者に配信されるときにそのDMARCポリシーに沿って振り分けられます[4]。
DMARCポリシーには、None（監視）、Quarantine（隔離）、Reject（拒否）の3つのポリシーが存在し、それぞれ送信ドメイン所有者が受信者に対して求める処理が異なります。
|
None（監視） |
メッセージの配信に関して特定のアクションを要求しません。つまり、DMARC検証に失敗した場合にも、受信者のメールボックスにメールが配信されます。 |
|
Quarantine（隔離） |
DMARC検証に失敗したメールに対して隔離処理を要求します。例えば、スパムフォルダーに配置するや疑わしいとしてフラグを立てるなどの処理を要求します。 |
|
Reject（拒否） |
DMARC検証に失敗したメールを拒否または破棄するように要求します。 |
DMARCでは、DMARCポリシーに従ってメールを処理した結果を、送信者ドメインの所有者に対して報告することで、送信者と受信者で相互に情報共有を行います。この時、送信者ドメインの所有者に対して送られる結果をDMARCレポートと呼び、このレポートを活用して適正化を進めます。
まずDMARCを導入したドメイン所有者は、DMARCポリシーを「None」で使用し、受信サーバからDMARCレポートを収集します。DMARCレポートより正当なメールがSPFやDKIMに合格していることを確認し、失敗したメールを隔離するようにDMARCポリシーを「Quarantine」に変更します。そして最終的に、正当なメッセージが誤って隔離されていないことの確認がとれたら、DMARCポリシーを「Reject」に設定することが推奨されています[5]。
しかし、Proofpointの調査（2023年1月公表）[6]では、日本において69%の企業はDMARCを未導入という調査結果が報告されています。また、DMARC導入済みの企業のうち81%を占める企業がDMARCポリシーをNone（監視）に設定しており、Quarantine（隔離）とReject（拒否）に設定していた割合はそれぞれ13%と6%でした。つまり約8割の企業は認証されていないメールが受信者に到達することを許していました。
DMARCレポートは、主に2種類存在します。
一つは「集計レポート」と呼ばれ、ドメインに対するDMARCの結果を集計したもので、どのIPアドレスからどれだけのメールが送られ、それがどのように処理されたかを示しています。これにより、送信元のIPアドレスや送信数、DMARC/SPF/DKIMの検証結果（pass、fail）などを把握することができます。
もう一つは「障害レポート」と呼ばれ、DMARC認証に失敗したメールの詳細情報を提供します。これにより、具体的なエラー内容や、認証に失敗した理由を詳細に把握することができます。
二つのレポートの形式は同じであるため、本記事では集計レポートについて解説します。
<?xml version="1.0"?><!-- 送信元IPアドレス -->
<feedback>
<version>0.1</version>
<!-- DMARC レポートのメタデータを格納している。レポートを送付した事業者の名前などの情報が格納される -->
<report_metadata>
<!-- レポートを生成した組織の名前 -->
<org_name> NRI Secure Technologies</org_name>
<!-- レポートを送信するために使用される電子メールアドレス -->
<email>dmarc@example.com</email>
<!-- レポートの一意のID -->
<report_id>1234567890</report_id>
<!-- レポートに含まれるデータの期間 -->
<date_range>
<!-- 開始日時 -->
<begin>1679961600</begin>
<!-- 終了日時 -->
<end>1680048000</end>
</date_range>
</report_metadata>
<!-- 送信ドメインに関するポリシー情報 -->
<policy_published>
<!-- DMARCレコードが設定されたドメイン -->
<domain>nri-secure.co.jp</domain>
<!-- DKIMアライメントモード。値は strict(s) または relaxed(r) のどちらか。 -->
<!-- rは署名したドメインとヘッダFromドメインが同じであれば許可する（組織ドメインが同一であればサブドメインでも許可する）。sはFQDNが完全一致している場合に許可する -->
<adkim>s</adkim>
<!-- SPFアライメントモード。 -->
<!-- rは認証したドメインとヘッダFromドメインが同じであれば許可する（組織ドメインが同一であればサブドメインでも許可する）。sはDNSドメインと完全一致している場合に許可する -->
<aspf>s</aspf>
<!-- DMARCポリシーの最終的なアクション-->
<p>reject</p>
<!-- サブドメインに対するDMARCポリシーの最終的なアクション -->
<sp>reject</sp>
<!—ポリシーが適用されるメールの割合 -->
<pct>100</pct>
<!-- 障害レポートを送信する条件 -->
<fo>0</fo>
</policy_published>
<!-- 個々の送信元IPアドレスとそれに対応する認証結果 -->
<record>
<!-- 特定のメールイベントに関する情報 -->
<row>
<source_ip>192.2.0.1</source_ip>
<!-- 送信元IPアドレスから受信したメールの数 -->
<count>14</count>
<!-- 認証結果に基づくポリシー評価結果 -->
<policy_evaluated>
<!-- DMARCポリシーに基づくメールの処理結果 -->
<disposition>none</disposition>
<!-- DKIMの認証結果 -->
<dkim>pass</dkim>
<!-- SPFの評価結果 -->
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<!-- メールのエンベロープ Fromアドレス -->
<envelope_from>nri-secure.co.jp</envelope_from>
<!-- メールのヘッダー Fromアドレス -->
<header_from>nri-secure.co.jp</header_from>
</identifiers>
<!-- メールの認証結果が含まれるタグで、DKIMとSPFの両方の結果が含まれる -->
<auth_results>
<!-- dkimの結果 -->
<dkim>
<!-- ドメイン（DKIMは、メールヘッダから特定したドメインのDNSサーバから公開鍵を取得し、その電子署名を検証するため、ヘッダーFromドメインを記載） -->
<domain>nri-secur.co.jp</domain>
<!-- 評価結果 -->
<result>pass</result>
</dkim>
<!-- spfの結果 -->
<spf>
<!-- ドメイン（SPFは、エンベロープFromドメインを管理するDNSサーバからSPFレコードを取得するためエンベロープFromドメインを記載） -->
<domain>nri-secure.co.jp</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
前述の通り、DMARCポリシーは最終的に「Reject」に設定することが推奨されています。
しかし、急にDMARCポリシーを「Reject」に設定するした場合、スパムメールが遮断されるだけでなく、正規送信者が配信に利用しているサービスをDKIM/SPFのポリシーへ登録を漏らすことで、受信者へ配信されないことが生じます。
そのために、DMARCレポートを正しく活用してSPF/DKIMのポリシーを調整するとともに、DMARCのポリシーもNone（監視）から Quarantine（隔離）、 Reject（拒否）へと徐々に変えていくことが推奨されます。
DMARCはXML形式であり機械可読なため、DMARCレポートを表示・分析するツールを使うことで効率化できます。DMARC導入支援を受けることで、DMARCレポートを分析し、DMARCポリシーと関連するSPF/DKIMポリシーの助言を受けることができます。
NRIセキュアでは、DMARC導入・運用支援にて本稿で触れてないDMARCポリシーのチューニング支援を行ったり、SEC Team Servicesにて本稿のようにプロダクト開発組織のセキュリティチームが対応しなければならない課題の解決をご支援することが可能です。ぜひご相談ください。
[1] 情報セキュリティ10大脅威 2023
[2] Domain Keys Identified Mail (DKIM) Signatures
[3] Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
[4] Domain-based Message Authentication, Reporting, and Conformance (DMARC)
[5] DMARC.org website. Why is DMARC needed?
[6] プルーフポイントの調査により、日経225企業の69％が「なりすましメール詐欺」に有効な対策ができておらず、調査対象18か国のうち最下位であることが判明