DMARC対応が（ほぼ）終わりました🏄♂️
2024年1月から始めた社のDMARC対応がほぼおわりました。2024年8月1日からp=quarantineに変更をしました。念のため、1か月間の様子見期間を経て、2024年9月からp=rejectにする予定です。なかなか学びの多い取組だったため、感想をポストしてみようと思います。
そもそもDMARCとは
そもそもDMARCとはって話はいろいろな人がいろいろな記事をあげてくれているので割愛します。このへんの記事や、Youtubeがわかりやすいです。
DMARCに対する取組のきっかけ
2023年に参加した某セキュリティシンポジウムで、某社の事例として聞いたDMARCへの対応は、直感的に自社もすぐに対応すべきと感じました。
その後、DMARCについてさらに調べているとGoogleや米Yahooが、DMARCが設定されているなどの各種条件をクリアしないと、メールをブロックする…なんて話も出てきました。
当時は情報が錯綜していて、Googleのガイドラインも英語と日本語でニュアンスが違う、コロコロ改定されるなど、メール管理者界隈は混乱しました。ただ、ニュアンスの違いをどう読み取ったとしても、DMARCに対して早急に取り組まなければ、Googleに一日5,000通以上送信する可能性がある規模の企業が確実にユーザーに配送できるメール基盤を維持できないと感じました。
取り急ぎ、Gmailのガイドラインにこたえるためにはp=noneで十分なのですが、「どうせなら推奨されるp=rejectまでもっていこう」と決めたことを覚えています。
自社のメール送信環境の把握
DMARCに対応しようとすると、立ちはだかるのが自社のメール送信状況の把握です。
各事業部門が、自社ドメインでどういったメールを、どういった用途で、どこのサーバーから送信しているか、また、そのメールがSPFとDKIMのメール認証を正常に行っているか…を把握する必要がありました。 そのために Proofpoint EFD (Email Fraud Defense)を契約。自社ドメインを利用したメールに対するDMARCレポートの分析を開始しました。
ツールの選定はあまり悩まないで決めちゃいました。Proofpoint EFDに不満はありませんが、もっと使いやすい！とか、もっと安い！とか、日本語対応バッチリ！とか他にもいろいろいいツールはあると思います。
Proofpoint EFD (Email Fraud Defense)を使った実務開始
Proofpoint EFDの画面に表示されたDMARCレポートを眺めながらやることは単純で、自社ドメイン及びそのサブドメインから送信されているメールが、どこのIPアドレスから発信されていて、そのメールがSPFやDKIMの認証と、DMARCの判定がどうなっているか確認する。DMARCはSPFとDKIMの認証がそれぞれどうなっているかの組み合わせでPASSするか決まります。
自社で利用している正規な送信元IPからのメールでSPFやDKIMなどの認証がPASSしていない場合や、Header From Domainとのアライメントがとれていないなどの場合、メール送信をしている部門に連絡し、是正をしてもらう。是正してもらったら1～2週間様子見。その後DMARCレポートの様子をみて、問題ないようであればその送信元への対応は終了。それの繰り返し。
Proofpointの画面で実例を見せると、SenderごとにDMARCやSPF、DKIMなどのPass Rateがどの程度あるのか一覧で確認できます。以下の画像でいえば、Sender名が「Amazon」から発信されているメールが全然DMARCにパスしていないのがわかるわけです。
次は、Amazonの中でも送信元IPごとにドリルダウンしていきます。すると（モザイクだらけでわかりにくいですが）送信元IPや、Hostname、Header From Domainなどと、各認証の状況がわかります。この情報をもとに各事業部と打ち合わせを進めていきます。
担当者間をたらいまわしになることもたびたびありますが、めげずに頑張りましょう🫡
取り組んでいると、少しずつ認証されるメールが増えていきます。目に見えて成果がでる情シス業務って数が少ないと思っているので、楽しい業務の一つになるはずです。
わからない送信元や、認証できていない送信元がなくなるまで、しつこく繰り返すだけ。やっぱり例外はいくつもあるもので、送信元の事情でSPFやDKIMの認証を設定するのが難しい場合も何件かあり（オンプレミスのメールサーバーを使っている場合が多かった）、そのときはSendgridなどへ送信元サービスを変更してもらったりしました。
二つ目の壁 include 10個まで問題
対応を進めていると、SPFをDNS登録していないサービスに対しては、SPFレコードの登録をDNSへしていきます。SPFの登録は、送信サーバーのIPアドレスを指定するやり方と、include:_spf.google.com などとして、Look Upさせる方法があります。サービスによっては、includeの方法しか案内されていないものもあります。サービス側の都合で送信サーバーが増えたりすることもあるので、たしかにサービス側としてはincludeで設定させて、自分たちが自由にIPアドレスを増減させられる方が楽ですよね。ただこれがSPFレコードを自社DNSに登録する側からするとやっかいで、Look Upは10回までという制限があります。雑に言うと、「include～」とドメインを指定できるのが10個までとなります。
include 10個まで問題への対応
環境にもよると思いますが、私の環境では簡単に10を超えちゃいました。なので、対応をしないといけないです。いくつかやり方は考えられて、まずはincludeで設定をしているサービスに連絡し、送信サーバーのIPアドレスを聞き、IPアドレスでの直接指定に切り替える方法。答えてくれるかわからないし、できたとしても、結構手間ですよね。
また、SPFレコードを検索できる、こういうサイトを利用して、自分でたどっていってSPFを設定していくことも可能です。ただしこの場合、やはり、その時点でのIPアドレスを指定していく対応となるため、送信側でサーバー変更などがあったときに対応できません。
そこで、次に考えるのは上記記事のように、動的にSPFレコードをフラット化し、DNSサーバーに設定する自動化です。ただ、情シスのメンバーのスキルによってはそもそも実装が難しい、運用が難しいなど課題を抱える可能性があります。その分、実装できた場合、費用的には低く収めることができます。この辺は判断のしどころですね。
またさらに、上記のような、SPFフラット化を自動化するサービスも複数あります。使ったことがないので、詳細はわかりません。が、SPFのinclude先ドメインを設定しておくと、定期的にその先のIPアドレスを取ってきてくれる感じでしょう。
私の環境では、DMARC対応するため契約したProofpoint EFD (Email Fraud Defense)にHosted SPFというサービスが付帯していたので、それを利用することにしました。
v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com ~all
Hosted SPFの設定は簡単で、SPFレコードに上記のレコードを登録するだけ。変数っぽくなっているところは、SPFマクロです。以下URLに参考情報を載せておきます。
%{s}: 「s」マクロは送信者のメールアドレスを表します。 例:Mark@domain.com。
%{l}: 送信者のローカル部分を表します。 例:Mark。
%{o}: 送信者のドメインを強調します。 例:domain.com。
%{d}: 「o」と同様に、このマクロは権限のある送信ドメインを表します。ほとんどの場合、送信者のドメインと同じですが、異なる場合もあります。
%{i}: メッセージの送信者の IP アドレスを抽出するために使用します。例えば、192.168.1.100
%{h}: メッセージが送信される際に、SMTP接続中に使用されるHELOまたはEHLOコマンドで指定されたホスト名は、%{h}マクロで参照されます。
Hosted SPFの問い合わせの流れは画像を参照してください。一度自社DNSサーバーに問い合わせがくるのですが、それをSPFマクロがIPアドレスなどの情報をもとに書き換えて、Proofpoint側のDNSサーバーに問い合わせがいくようになります。アプリケーション側で各種設定をしておくことで、認証情報を正しく返すことができます。
SPFの追加／削除はProofpoint側の管理画面で行います。
Saas利用のメリット／デメリット
こういったSaaSを利用すると、簡単にLook Upの制限をクリアすることができます。が、コストがかかります。連絡手段としてのメールが仕組みとして残り続ける限り、基本的にはずっと契約し続ける必要があります。先に紹介した自力で実装する方法もありますので、ここは各社判断が分かれるところかと。
私は自社のメール環境を監視する必要性を感じて、#Proofpoint EFD (Email Fraud Defense)を当面は契約し続けようと思っていたところだったので、Hosted SPFを利用するという判断はそんなに迷いませんでした。ちなみに、Hosted SPFだけではなく、Hosted DKIM、Hosted DMARCもあります。DNSサーバーをあまりさわることなく、細かな設定はPoofpoint側で行うことができるようになったので便利です。
また、Hosted SPFにして便利になったことは、一度Proofpoint側に問い合わせがくることになるので、SPFへの問い合わせ回数がわかるわけです。つまり、使われているかわからないSPFが残り続けるというよくある管理面の課題もクリアすることができました。たすかるぅ！
まとめと感想
最終的に対応したサブドメインの数は約50。正規だと判断している送信元は２０弱ぐらいとなりました。逆に、正規ではないと判断した送信元は現時点で200を超えます。それだけ、メールは謎のサーバーから送られているってことです。それも、日々増えていきます。DMARCへの取組をする前はわからないことでした。すべてが悪意のあるメールではないと思うんです。ただ悪意のあるものも含まれているはずです。DMARCへの対応は、社の確実なメール配送環境を担保するためにはじめましたが、社のドメインを利用した不正なメールも少なからず防げるようになったため、CSR（企業の社会的責任）としても取り組む価値があったと思っています。DMARCに取り組む人や組織が増えれば、それだけメールを起点とした侵害や詐欺などを減らせます。
BIMI (Brand Indicators for Message Identification) への対応
次は、BIMIにも対応しようと考えています。BIMIについては以下URLをご覧ください。
メールクライアント側で自社のロゴを表示することで、メールの正当性をわかりやすく伝えられるようになります。前提としてDMARCのポリシーをp=quarantine以上にする必要があるため、正規な送信元からでているということが保証されます。
現状はロゴに使用する画像の商標登録が必要とのこと。商標登録は1年近くかかるものなので、DMARCに取り組み始める際には事前に商標登録の申請をやっておくのがよいですね。また、まだ比較的新しいメール認証技術のため、Microsoftは非対応 です😇
ただ、Microsoftのドキュメントにも以下のような記述があるため、Microsoftが受信側として対応するのも時間の問題かなと考えています。
- ブランド認知度の向上: BIMIは、組織が受信トレイのメールメッセージの横に自社のロゴを表示することを可能にします。これにより、ブランドの認知度が高まり、受信者は送信者からの正当なメッセージを簡単に識別できます
- メール配信の改善: BIMIでは、送信者のメールドメインがSPF、DKIM、DMARCなどのメール認証プロトコルを使用して適切に認証されることが義務付けられています。これらのプロトコルを正しく設定することで、メールの配信能力を向上させ、メールメッセージが受信者の受信トレイに届く可能性を高めます
- エンゲージメントの向上: メッセージの横に認識可能なロゴを表示することで、送信者は受信者がメールに関与する可能性を高めることができます。これにより、開封率、クリックスルー率、および全体的なエンゲージメントが向上します
- セキュリティの強化: BIMIは、電子メールメッセージを認証し、電子メール詐欺を防止する方法を提供するDMARCの採用を促進することにより、電子メールエコシステムのセキュリティ向上に貢献しています
- 将来性: BIMIは比較的新しい技術ですが、時間の経過とともに広く採用されることが予想されます。今すぐBIMIを導入することで、メール送信者はメールマーケティングキャンペーンの将来性を確保し、進化するメール環境に対応できます
DMARCやBIMIへの対応は、見えるところにゴールがある作業です。ツールを導入して継続的に取り組めば、実務が可視化され、楽しく取り組むことができます。そして、やれば終わる作業です。一度p=rejectにしてしまえば、その後の運用作業はかなり減ります。
ぜひみなさんも、DMARCポリシーをp=rejectへもっていき、自社メール送信環境を正しく保ち、かつ、世の中のフィッシングメールを少しでも減らせるようにしていきましょう。
以上、読んでいただきありがとうございました！