対策としてDMARCが拡大中、しかし運用面で課題も
今、フィッシング対策協議会が力を入れて導入を促しているのが、送信ドメイン認証技術「DMARC（ディーマーク）」だ。人による判別が困難なフィッシングメールを識別し、なりすまし被害を未然に防ぐ技術である。同じ送信ドメイン認証技術である「SPF」や「DKIM」が、認証に失敗したメールの取り扱い方を受信側に委ねるのに対し、DMARCは、認証できなかった場合の処理を送信側が宣言したポリシーに基づいて実行できる点が特徴だ。
たとえば、自社のドメインになりすましたメールを、送信側が設定したポリシーで「隔離（quarantine）」や「拒否（reject）」に設定できるため、より能動的にブランドと顧客を脅威から守ることができる。また、自社ドメインを使用して送信されているメールに関するレポートを受け取り、脅威の状況を可視化することも可能だ。
Gmailは2024年2月から、1日5,000通以上のメールを配信する事業者に対し、DMARCなどの送信ドメイン認証の対応を必須とした。そのため、事業者での導入や検討が急速に進んでいる。
DMARCの設定は、自社（送信側）のドメインを管理する権威DNSサーバにSPFやDKIMの設定が入っていれば、TXTレコードにDMARCレコードを追加するだけの比較的簡単な作業で完了する。しかし実際の運用では、たとえばキャンペーン用の一時的なドメインを自社内の部門が運用するケースなどで、正規メールの認証が失敗し、送信先に届かない事故が頻発している。
このようなメールの不達を嫌って、いまだにDMARCポリシーを「none（レポートはするがメールの隔離や拒否はしない）」設定で運用している企業が多い。フィッシングの被害を減らすためには「Reject」化が必須だが、そのためには日々大量に届くレポートの解析や、各部門での運用実態の把握、地道な調整・確認作業が必要となる。
ただ、この面倒な作業を支援するコンサルティングサービスや、権威DNSをハイジャックされる恐れのある設定ミスを確認するツールなど、DNS管理を強化するソリューションは市場に出てきている。自社運用に限界を感じるようなら、ベンダーに相談してみるのもよいだろう。
