DMARCの脆弱性とは何ですか？

メール偽装を防ぐ鍵！

2024年5月16日
著者: Maitham Al Lawati
翻訳: 逆井 晶子

この記事はPowerDMARCのブログ記事 What is DMARC Vulnerability? の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

DMARCレコードは正しく設定されることで、多くの利点をもたらしてくれます。
これは、メールセキュリティにおける新しい領域であり、ドメイン所有者に対して、送信元やパフォーマンスに関する豊富な情報を提供します。
DMARCの脆弱性とは、ユーザがプロトコルを実装または適用する際によく犯す一般的なエラーを指します。

メール認証システムにおける脆弱性は、単純な構文エラーから、より複雑なエラーまでさまざまです。
いずれにしても、これらの問題をトラブルシューティングしてプロトコルを正しく設定しない限り、メールセキュリティの取り組みが無効になる可能性があります。

メール認証のプロセスにおいて遭遇する可能性のある脆弱性を分析する前に、いくつかの基本的な概念を簡単におさらいしましょう。
それは以下のとおりです。

• メール認証とは何か？
• DMARCはどのようにしてあなたのメールを認証するのか？
• DMARCの脆弱性がメッセージの配信に与える影響

重要なポイント

1. DMARCレコードを適切に構成することは、メールセキュリティを強化し、なりすましを防ぐために不可欠です。
2. 構文エラー、レコードの欠落、非強制ポリシー などの脆弱性は、メールの配信に大きく影響します。
3. DMARCは、SPFおよびDKIM識別子の整合性を確認することで、メールの正当性を検証します。
4. p=rejectなどの厳格なDMARCポリシーを実施することが、フィッシング攻撃からドメインを効果的に保護するために重要です。
5. 定期的なモニタリングと、メールベンダーとの連携により、堅牢なメール認証システムを維持できます。

メール認証とは？

サイバー犯罪者は、メール通信を傍受したり、ソーシャルエンジニアリングを用いて被害者を騙して金銭的利益を得ることができます。

メール認証とは、ドメイン所有者が自ドメインから送信されたメールの正当性を確認するために設定できる特定の検証システムのことです。
メッセージ本文の電子署名やReturn-Pathアドレスの検証に加えて、送信元アドレスが本物かどうかを判断するために、表示されている差出人ドメインと実際の送信元ドメインが一致しているかどうかも確認します。

認証チェックによってメッセージの正当性が確認されると、そのメールは受信者の受信トレイに配信されます。

DMARCはどのようにしてあなたのメールを認証するのか？

企業がユーザにメッセージを送信する際、そのメールは送信サーバから受信サーバへと移動して配信されます。
このメールには、Mail From: ヘッダー（表示される送信元アドレス）と、Return-pathヘッダー（非表示のReturn-pathアドレス）が含まれます。

攻撃者は企業のドメインを偽装して同じドメイン名からメールを送信することができますが、Return-pathアドレスを隠蔽するのははるかに困難です。
以下は、その疑わしいメールの例です。

メッセージに関連付けられたメールアドレスはdereksmith@company.comで、一見正規に見えますが、Return-pathアドレスを調査すると、バウンスアドレスはcompany.comとは全く無関係で、未知のドメインから送信されたものであることが判明します。

このバウンスアドレス（別名：Return-pathアドレス）は、メール受信サーバが送信者のSPFレコードを確認し、DMARCを検証する際に使用します。
送信者のDNSに、送信されたメールのIPアドレスが登録されていれば、SPFおよびDMARCは合格し、そうでなければ失敗します。
その後、送信ドメインで設定されたDMARCポリシーに従い、メッセージは拒否・隔離・配信のいずれかの処理がされます。

代わりに、DMARCはDKIM識別子の整合性を確認して、メールの正当性を検証する場合もあります。

DMARCの脆弱性がメッセージ配信に与える影響

クライアントへのメッセージ配信の成功率は、プロトコルをどれだけ正確に設定しているかに大きく依存します。
組織のメールセキュリティ体制に脆弱性が存在すると、メッセージ配信の成功率が低下する可能性があります。

DMARC認証システムに問題が発生している可能性がある兆候には、次のようなものがあります。

• メール配信の問題
• 正当なメッセージがスパムと判断される
• オンラインツール使用時のDMARCエラーメッセージ

DMARCの脆弱性の種類

DMARC脆弱性 #1：DNSレコードの構文エラー

DMARCレコードは、セミコロンで区切られたメカニズムを含むTXTレコードで、メール受信MTAに指示を与えます。
以下は例です。

v=DMARC1; p=reject; rua=mailto:reports@domain.com; pct=100;

セミコロンのような細かい構文がレコードの有効性を左右するため、見落とすとレコードが無効になる可能性があります。
そのため、正確なTXTレコード作成には、無料のDMARCレコード生成ツールの使用を推奨します。

DMARC脆弱性 #2：DMARCレコード未設定 / レコード欠落の脆弱性

ドメイン所有者はオンラインツールで「DMARCレコードが見つかりません」といったメッセージを目にすることがあります。
これは、DNSに有効なDMARCレコードが公開されていない場合に発生します。

DMARCは、フィッシングやドメインなりすましを含む幅広い攻撃から、ドメインおよび組織を保護するのに役立ちます。
デジタル社会では、常にメールを狙う攻撃者が存在しており、私たちはそのリスクに備える必要があります。
DMARCは、こうした脅威からメールを守り、より安全な通信環境を実現するための仕組みです。

DMARCレコードが見つからないという脆弱性の修正方法については、詳細な記事を用意しておりますので、リンクをクリックしてご参照ください。

DMARC脆弱性 #3：ポリシーがp=none（監視のみ）

DMARCポリシーが「p=none」であれば攻撃から保護できると誤解するユーザが多いですが、実際にはrejectまたはquarantineの強制ポリシーだけが、なりすましに対する防御を構築できます。

緩やかなポリシーは、保護を強制せずにメールを監視したいだけの場合には有効である可能性があります。
しかしながら、運用に問題がないことが確認できた場合には、できるだけ早く「p=reject」へ移行することが推奨されます。

DMARCの主な目的がメールのなりすまし防止、つまり攻撃耐性の強化であるという前提に立てば、「p=none」などの強制力を持たないポリシーは、セキュリティ上の脆弱性とみなされる可能性があります。
そのため、ポリシーに強制力が伴わない状態が続くと、DMARC本来の効果が十分に発揮されないと判断されるリスクがあります。

DMARC脆弱性 #4：DMARCポリシーが有効化されていない

前述の脆弱性と似ていますが、DMARCの強制ポリシーが設定されていない場合に発生します。
「p=none」ポリシーのままだとフィッシング攻撃に脆弱なため、「p=reject」または「p=quarantine」への移行が推奨されます。
これは、既存のDNSレコードのポリシーを少し変更することで対応できます。

DMARCポリシーが有効になっていないというエラーを解決する方法については、詳細なドキュメントを用意しています。
リンクをクリックすることでご覧いただけます。

DMARCの脆弱性をリアルタイムでトラブルシューティングする方法

これらの問題を解決するために、組織内で以下の手順を実施することを検討してください。

1. すべての正規のメール送信元をリスト化し、それらを日次または定期的に追跡するためにDMARC監視ツールを構成します。
2. メールベンダーと話し合い、メールの認証に対応しているかどうかを確認します。
3. SPF、DKIM、DMARCについて詳細に学習し、次のステップに進む準備を整えます。
4. SPFフラットニングツールを用いて、SPFレコードにSPF Permerrorが発生しないようにします。
5. 無料のDMARCアナライザーに登録することで、専門家の知見とガイダンスを活用して、プロトコルの導入を円滑に進めることができます。
   また、リアルタイムで脆弱性や攻撃を検出できる仕組みによって、より安全かつ確実に「p=reject」への移行が可能となります。

ドメインを保護することは、信用を維持し評判を守るための基本的なステップの一つです。
メールセキュリティを今日からセキュリティ体制の一部に取り入れましょう。