見出し画像

DMARC導入のメリットを2つに分けて説明してみる

前回のおさらい(DMARCの違い)

こんにちは、株式会社WOW WORLDの藤田です。前回はDMARCの認証がSPFやDKIMと何が違うかを書いてみました。では、ドメインを持ち、そのドメインでメールを送る組織(会社など法人、あるいは個人)がDMARCに対応したときに、どのようなメリットがあるのでしょうか。今回は、DMARC導入の送信者のメリットについて書いています。

以下では、
- ドメインを持ちそのドメインでメールを送る組織を「送信者」
- その「送信者」からメールを受け取る人を「受信者」
と記載します(ですので、通常、メールをやり取りする組織・人は「送信者」であり「受信者」です)。

送信者と受信者

送信者のDMARC導入には2つの形がある

送信者のDNSのレコードから、以下2つの形があります。

①p=none の場合

DNSのレコード例(none):
_dmarc.example.net IN TXT
"v=DMARC1; p=none; rua=mailto:dmarc@example.net; ruf=mailto:dmarc@example.net"
意味するところ:@example.net がヘッダFromのメールについて、インターネットの各メールサーバーはDMARCポリシーを使用した受信判定をしないでください。DMARCの認証結果が失敗でも通常通り受け取ってください。けれど、インターネットの各メールサーバーから dmarc@example.net へ、@example.net がヘッダFromのメールの送信状況をメールでレポートしてください。

p=none での動作

②p=quarantine, reject の場合

DNSのレコード例(quarantine):
_dmarc.example.net IN TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.net; ruf=mailto:dmarc@example.net"
DNSのレコード例(reject):
_dmarc.example.net IN TXT
"v=DMARC1; p=reject; rua=mailto:dmarc@example.net; ruf=mailto:dmarc@example.net"
意味するところ:@example.net がヘッダFromのメールについて、インターネットの各メールサーバーはDMARCポリシーを使用した受信判定をしてください。quarantine なら迷惑メールに分類し、reject なら受信者に渡さないでください。あわせて、インターネットの各メールサーバーから dmarc@example.net へ、@example.net がヘッダFromのメールの送信状況をメールでレポートしてください。

p=reject での動作

このようにDMARCレコードの p(ポリシー) で2つに分かれます。「メールの送信状況をレポートしてください」はいずれのポリシーでも共通です。「ポリシーが none ならDMARCの判定結果を使用しないでください」「quarantine, reject ならDMARCの判定結果を使用してください」と送信者から受信者へDNSを通じて呼びかけています。
※送る側のポリシーによらず、受信側のメールサーバーがおこなう様々な判定(IPレピュテーションなどを元にした)は実行されます。

通常①→②の順番で導入します。この導入時の進め方は次回書く予定です。後述する、「メリットその1.フィッシングメールを宛先に届かないようにできる」は②の段階まで進めて得られるメリットです。一方「メリットその2.フィッシングメールの送信状況がわかる」は①の段階でも得られるメリットです。

メリットその1.フィッシングメールを宛先に届かないようにできる


「送信者」のDMARC導入メリット1つ目は、「送信者」を騙ったメール≒フィッシングメールが「受信者」に届かなくなることです。ただし、この表現だと誇大表現で、届かなくなるには3つの条件をクリアする必要があります。

条件①DMARCのポリシーが quarantine または reject であること。quarantine ならフィッシングメールは迷惑メールボックス行きで、reject なら届きません。
条件②フィッシングメールのヘッダFromが自組織のドメインであること。自組織のドメインと関係ないメールアドレスがヘッダFromだったときには効果がありません。
条件③「受信者」の使用するメールの仕組みがDMARCを元にした判定に対応していること。Gmail+Google Workspace・Yahooメール・outlook.com+Microsoft365 はDMARCを元にした判定に対応しています。日本国内で大きなシェアを持つ携帯キャリアのメールアドレスは未対応でしたが、NTT docomo は2022年8月23日からDMARCに対応しました。
ドコモメールに送信ドメイン認証技術「DMARC」「DKIM」を導入

DMARCによって届かなくなるフィッシングメールとその条件

メリットその2.フィッシングメールの送信状況がわかる


「送信者」のDMARC導入メリット2つ目は、フィッシングメールの送信状況がわかることです。この表現だとこちらも誇大表現で、把握対象である条件は
条件①フィッシングメールのヘッダFromが自組織のドメインであること。自組織のドメインと関係ないメールアドレスがヘッダFromであるものは範囲外です。
条件②「受信者」の宛先がDMARCを元にした判定に対応し、かつ、レポートを rua で指定したメールアドレスに返すこと。(DMARCを元にした判定に対応しているがレポートをruaのメールアドレスに返さないメールサーバーも存在します)
です。

DMARCレコードの rua で指定したメールアドレスに届くレポートメールは
・IPアドレスごとに
・SPF・DKIMの送信ドメイン認証の結果(OKとNGの数)
が記載されています。

"自組織と関係ないIPアドレスから、ヘッダFromが自組織のドメインであるメールが送られている"≒フィッシングメールの送信とみなし、これがあるかどうか、あった場合の増減を把握することができることは、SPFやDKIMといった送信ドメイン認証にないDMARCの特徴です。

フィッシングメールの送信状況を検知する

終わりと次回予告


今回はDMARCのメリット
・メリット1.自組織以外からのメール≒フィッシングメールを相手に届かないようにできる(相手が対応していれば)
・メリット2.自組織以外からのメール≒フィッシングメールの送信状況がわかる
を説明しました。

DMARCの性質上、導入時にはシステムごとの対応で済んだSPFやDKIMと比べて、組織全体の対応が必要となります。このような導入時の注意点や望ましい方法を次回は説明します。


この記事が気に入ったらサポートをしてみませんか?