こんにちは。日々是発見が楽しみな西山です。
「不正メールの処理方法をドメイン管理側で指定する」DMARCレコード。
最近までいまいち知名度足りなかった代物ですが、Gmailのポリシー変更で一躍有名になりましたね（対応に追われたエンジニアの皆さま、お疲れさまです……）。
そんなDMARCレコードですが、「取りあえず」この設定を入れている場合が大半だと思います。
v=DMARC1; p=none;
「p」の値はDMARCポリシーのレベルを指定しますが、「none」は何もしない、つまり「DMARC判定が失敗しても特に何もしないでね」という意味になります。
じゃあDMARC判定してもしなくても同じじゃん、と思ったあなたはとても正しいです。
では実際、一番過激な「p=reject」設定にすると何が起こるでしょうか？
私が個人で利用しているドメインでやってみました。
DMARCをどう設定するべきかというガイドラインをGoogleが出しているので、まずその内容を確かめてみましょう。
DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、段階的にロールアウトするように設計されています。まずはメールフローのみをモニタリングする none ポリシーから始めて、最終的にはすべての未認証メールを拒否するポリシーに変更します。
～～～
DMARC レポートのモニタリングを 1 週間以上続けて不都合な結果が見受けられない場合は、ポリシーを quarantine に更新し、pct タグを追加して、ごく一部のメールだけにポリシーが適用されるようにします。
～～～
DMARC レコードが想定どおりに機能している場合は、組織から送信されるすべてのメールについてポリシーを reject に更新します。
https://support.google.com/a/answer/10032473?sjid=18348535229210777215-AP
ざっくり言って「様子を観察しながら厳しくしていきましょう」という流れですね。そして「p=reject」にするのがゴールだと書いてあります。
そして今回テストしてみたドメインですが、2007年に個人利用のため取得しました。外部公開サーバーをいくつかと、私個人の連絡先メールアドレスのドメインとして利用しています。
使い続けて14年目ですので、メールアドレスは某クラウドサービスの不正アクセスで流出したり、悪い企業に転売されてリストに載りまくり。
さらに最近は、商用に限らず個人利用でも「長年アクティブに利用され続けているドメイン」がフィッシングメールのネタにちょいちょい悪用されるようです。
↑こういう「メールボックスがいっぱいです」系。
悪い奴に利用されるのは避けがたいと言えど悔しいので、セキュリティ設定をがちっと締めて少しでも邪魔してやろうというのが動機です（笑）。
DMARCレコードの設定内容
私のドメインでは、人間が送受信するメールはGoogle Workspace、システム系の自動送信メールはSendGridのメールAPIを通すようまとめています。
つまり、これ以外の経路で送信されるメールは全部詐称系だから葬り去っていいと確信できます。
なのでDMARCレコードをこう設定しました。
"v=DMARC1; p=reject; sp=reject adkim=s; aspf=s; rua=mailto:dmarc_agg@vali.email"
| p=reject | DMARC判定が失敗のメールは拒否（バウンスなり削除なり）してください。 |
| sp=reject | 主ドメイン以外のサブドメインも拒否してください。 |
| adkim=s | DKIM判定をstrict modeで厳しくしてください。DKIMドメインとFromヘッダのずれを認めません。 |
| aspf=s | SPF判定をstrict modeで厳しくしてください。SPFドメインとFromヘッダのずれを認めません。 |
上記を受信側のメールサーバーに指示しています。記事タイトルの通り、全てのパラメーターを一番厳しい方に振った内容です。
ruaレポートをダッシュボードで確認
このDMARCレコードにはもう一つ、
rua=mailto:dmarc_agg@vali.email;
という内容が入っています。
先ほどのGoogle Workspaceのヘルプに「DMARC レポートのモニタリング」という説明がありましたが、レポートの送信先メールアドレスをここで指定します。
相手のメール受信サーバーがDMARC対応に加えてレポート送信も対応している場合に、判定レポートが定期的にmailto:のアドレスへ送られてきます。
ただこのレポートはXML形式なので、人間が直接読むのはつらいです。
ですので、メール受信・XMLの読み取り・DBに格納してダッシュボード生成まで全自動でやってくれる外部サービスを利用するのが便利です。
今回は、無料で利用開始できる「Valimail」を利用しました。
アカウントを作成し、対象ドメインを登録して、最後にDMARCレコードに「rua=mailto:dmarc_agg@vali.email」を追記すれば、レポートが蓄積されていきます。
私のドメインのダッシュボードは今こんな感じになっています。
直近30日間で、私自身が送ってDMARCをパスしたメールが8通に対し、SPFもしくはDKIM不正でrejectされたメールが54通です（200通以上弾かれていた時期もありました）。
不正メールの送信元地域はこんな感じの判定……。
上記の通り、これはDMARC判定を行っており、かつruaレポートを送信してくれるメール受信サーバーのみの情報です。
世の中にはDMARCノーチェックのメール受信サーバーがたくさんありますから、たぶん実際にはなりすましメールが1か月で何百通と送信され、相当数が相手先に届いてしまっていることでしょう。
DMARCポリシー見直しのススメ
上でネガティブな書き方をしましたが、裏を返せば「メール受信サーバーがDMARC判定していれば、そのサービスのユーザーになりすましメールを届かなくできる」ということです。
そしてGoogle・Outlook・iCloudなど、世界的にユーザーの多いメールサービスが軒並みDMARC判定に対応しました。今後も増えていくことでしょう。
なりすましメールを送信されたり、そのメールのフィッシングリンクから詐欺被害者が出てしまうと、なりすまされたドメインや紐づく企業ブランドのイメージも悪化して価値が損なわれます。
「なりすましメールの送信は止められなくても、受信を妨げられる」のがDMARCの最大のメリットです。この機会に対応を検討されてみてはいかがでしょうか？
