eSecurity Planetは8月8日(米国時間)、「Most Organizations Do DMARC Wrong. Here's How to Do It Right.｜eSecurityPlanet」において、ほとんどの組織がDMARC（Domain-based Message Authentication, Reporting and Conformance）のセットアップが完了していないと伝えた。ほとんどの企業がDMARCポリシーを実施するための設定を完了していないため、自分たちが考えているよりもはるかに安全性の低い電子メールシステムを構築しているのが現状だと指摘している。
組織が「quarantine」や「reject」のDMARCポリシーを設定しない限り、不正と認識された電子メールでも受信箱への通過が許可されてしまう。厳格なポリシーを設定しない限り、企業はメールセキュリティソリューションに不必要な負担をかけることになり、ブランドを装ったフィッシング攻撃が成功する可能性が高くなるとされている。
DMARC導入時の一般的な問題点として、以下が紹介されている。
- DMARC拒否ポリシー: 組織は不適切に設定されているが正当なメールを拒否することを避けるために、「p=none」で開始する
- DMARCのアップデート: クラウドへのアップグレードまたは移行に伴い、電子メールサーバのIPアドレスを切り替える可能性があり、登録済みのポリシーを更新する必要がある
- DMARCのミスは簡単に起こる: DMARCレコードはシンプルであるが故に間違えると大きな問題を引き起こす可能性がある
- ITリソースの不足: DMARC に専念するIT部門を持たない中小企業には、実装するためのリソースがない
これらのDMARCの問題を解決するには、DMARCの要件を正確に理解し、初期不良のトラブルシューティングを効果的に行うことが必要とされている。トラブルシューティングのベストプラクティスは次のとおり。
- SPF、DKIM、DMARCポリシーを詳細に検証する
- DMARCを監視モード（p=none）で導入する
- 数週間にわたりDMARCレポートをチェックし、拒否された正当なメールソースを特定する
- 適切なポリシー(SPF、DKIM、DMARC、またはメールベンダーの設定)を更新することで、拒否の問題を解決する
- 正規のメールに関する問題が解決された場合、「p=quarantine」または「p=reject」を徐々に適用し、新たな拒否の問題が発生していないか確認し、すべての送信ドメインが検証され、実施され、完全に保護されるまで手順を繰り返す
- IPアドレスの変更や新たなドメインの競合を解決するため、定期的にレポートを確認する
メールサーバにとってDMARCポリシーが施行されていれば、サーバはヘッダーをざっと調べただけですぐにメールを拒否することができる。また、Microsoft 365やGmailなどの電子メールプロバイダーは、顧客向けにDMARCポリシーを適切に構成するためのチュートリアルや専門的な説明書を提供している。ITチームはこれらのガイドを確認し、その指示に従えばよい。
リソースのない多忙なITチームには要件を調べたり、プロセスのトラブルシューティングを行ったりする時間がないかもしれない。そのような場合は、DMARC専門のベンダーが時間とコストを節約する効果的なソリューションになるとしている。
トラブルシューティングや正しく設定されたDMARCポリシーの導入には、今後も正確さと時間が必要となる。すべてのメール攻撃を阻止できるわけではないが、信頼できるなりすまし攻撃を減らすことで、メールセキュリテソリューションの負担が劇的に軽減され、組織や他の受信者のフィッシング被害を減らせることから、あらゆる規模の組織がSPF、DKIM、DMARCの完全な導入に向けて取り組むべき時だという。
