動画：DMARC – 技術概要
DMARCに関する簡単な技術概要をまとめました：
この動画は、DMARCに関するあらゆる情報を網羅した動画シリーズの一部です。
以下が議事録です：
この短い動画は、DMARC（Domain-based Message Authentication, Reporting, and Conformance）の技術概要です。
DMARCは、SPFまたはDKIMのいずれかを使用して、メールの内容とドメインとの関連性を確立しようとします。詳細を知りたい方は、SPFとDKIMについては別の動画で解説しています。
DMARCが対象とするメールの内容は、「From:」ヘッダーに記載されているドメインです。「From:」ヘッダーは、メールの送信元や送信元を特定する情報として、「正しく構成されたメール」に必須とされるほぼ唯一の要素です。このため、DMARCは「From:」ヘッダーに記載されているドメインを基準として動作します。
DMARCは、「Sender:」ヘッダーを含め、他のいかなるヘッダーも参照しません。複数のポリシーキーを許可すると、多くの混乱を招き、DMARC自体の有用性を損なう恐れさえあることが判明したため、DMARCは「From:」ヘッダーに記載されているドメインのみを参照します。
SPFとDKIMは、いずれも安定したドメインレベルの識別子を生成する技術です。SPFとDKIMは、多くの異なるメールベンダーで広く実装されている、自由に利用可能な技術仕様です。 その仕組みは異なるものの、DMARCが重視するのは、SPFとDKIMが生み出す結果のみであり、その結果がFrom:ヘッダーに記載されたドメインと関連しているかどうかです。SPFとDKIMによって生成される結果は、DMARCの世界では「認証済み識別子」と呼ばれます。
DMARCの重要な概念の一つが「識別子の整合性（Identifier Alignment）」です。これは、SPFとDKIMの結果が有用であるためには、DMARCの対象ドメインと関連付けられている必要がある、ということをやや大げさに表現したものに過ぎません。その主な理由は、受信側が、SPFとDKIMの結果が、DMARCの対象となっているドメインに関連しているかどうかを簡単に判断できる方法が必要だからです。
この動画の次の数枚のスライドでは、認証済み識別子のさまざまな組み合わせについて解説し、メールの受信者の視点から見て、識別子の整合性がなぜ重要なのかを説明します。
この最初の例では、メールの受信者が、DMARCドメイン（From:ヘッダーに記載されているドメイン）が「bank.com」であるメールを受信しました。さらに、SPFチェックの結果も「bank.com」というドメインでした。このメールにはDKIM署名が含まれていなかったため、この行には「none」とマークされています。 メール受信者は、そのメールが「bank.com」ドメインに遡れることを示す肯定的なシグナルを何らかの形で求めており、そのシグナルがSPFからかDKIMからかは問いません。重要なのは、シグナルが存在することだけです。この例では、SPFから得られた認証識別子（Authenticated Identifier）は「bank.com」であり、これはDMARCドメインと完全に一致しているため、このメールはDMARCに準拠していると判断されます。
次の例では、SPFが返した認証済み識別子がbank.comのサブドメインである点（mail.bank.com）を除けば、すべてほぼ同じです。人間から見れば、この2つのドメインが明らかに関連していることは明白です。 しかし、インターネット上には、bank.comが.comや.orgのようなトップレベルドメインなのか、それともセカンドレベルドメインなのかを判別する標準的な方法が存在しません。これを判別する標準的な方法はないのです。別の例としてbank.co.ukがあります。「co.uk」がトップレベルドメインであることを機械に伝える標準的な方法はないのです。 DMARCの世界では、セカンドレベルドメインに相当するものを「組織ドメイン（Organizational Domain）」と呼びます。インターネット上のリソース（具体的にはMozilla Foundationが管理するパブリックサフィックスリスト）を参照することで、メール受信側はbank.comが組織ドメインであり、mail.bank.comがbank.comと同じ組織ドメインを共有するサブドメインであることを判別できます。 この場合、そのメールはDMARCに準拠しています。
この3つ目の例は興味深いことを示しています。 SPFがbank.comやbank.comのサブドメインを認証済み識別子として返すのではなく、認証済み識別子はbanknewsletter.comとなっています。現時点では、banknewsletter.comはbank.comを所有する同一の組織が所有・運営している実在のドメインである可能性があります。あるいは……banknewsletter.comは、自分たちが正当な組織であるかのように人々を騙そうとする犯罪者によって所有・運営されている可能性があります。 ドメイン間のこのような関連性を確実に維持・伝達する方法は、そもそも存在しません。送信者自身が関連付けのデータベースを作成するにせよ、受信者が独自のデータベースを維持するにせよ、どちらの作業も不正確さが付きまとい、基本的にDMARCの有用性を損なうものとなるでしょう。したがって、このメールはDMARCに準拠しておらず、公開されたDMARCポリシーの影響を受けることになります。
4番目の例を続けると、メールの内容は同じですが、今回初めてDKIM署名が表示されています。この例では、DKIMによって「bank.com」という認証済み識別子が生成されたため、このメールはDMARCに準拠しています。つまり、メールの受信者はSPFから得られた認証済み識別子を確認し、banknewsletter.comがbank.comとは無関係であることを認識して、そのメールを単に無視します。 受信側は、メッセージが実際に bank.com から送信されたことを示す肯定的なシグナルを探しており、DKIM がそのようなシグナルを提供するため、このメールは DMARC チェックに合格します。
この5番目の例は、DMARCの要件を完全に満たしているメールを示しています。SPFとDKIMの両方で、bank.comという認証済み識別子が得られました。受信側は肯定的なシグナルが見つかることだけを重視するため、2つの肯定的なシグナルがあることは二重に良いことですが、それは単に「肯定的なシグナル」であるということ以上の意味を持ちません。 SPFとDKIMの両方が正しい結果を返すメールを送信する理由は、両方の技術が利用可能であれば、たとえどちらか一方（理由を問わず）が利用できない、あるいは失敗した場合でも、メールが引き続きDMARCに準拠し続けることができるためです。
この6番目の例では、SPFとDKIMの両方で「news.bank.com」が認証識別子となっている点が異なります。大規模な組織が、メールサービスプロバイダーにサブドメインを委任し、そのプロバイダーが組織に代わってメールを送信できるようにすることは、かなり一般的な慣行です。 この例では、bank.comの所有者が「news」というサブドメインをマーケティングベンダーに委任し、ベンダーがbank.comを使用してDMARC準拠のメールを送信できるようにしている可能性があります。
この作り話のような例が示すように、誰でもドメインを登録し、SPFやDKIMを設定することは可能です。悪意のある者がこれほど露骨なドメインを使えば、どれほど便利でしょうか。とはいえ、SPFやDKIMの検証に合格し、「認証済み識別子」が発行されたからといって、そのメールが正当なものや望ましいものであるとは限りません。
ここでの最後の例は、SPFが「bark.com」という認証済み識別子を返したことを示しています……そう、犬が鳴く音と同じ「バーク」です。これは、メールの正当性を確認するために手動で内容を確認している人間を騙すために、一部の詐欺師が利用するよく知られた攻撃手法です。一瞥しただけでは目が錯覚し、barkが実はbankだと誤解してしまう可能性があります。 さらに悪いことに、文字エンコーディングのトリックを駆使することで、表示される文字が意図したドメインと全く同じに見えるようにすることも可能です。機械はこのような小細工には騙されません。だからこそ、識別子の照合チェックは人間ではなく、機械が行うべきなのです。
DMARCレコードの構造や機能について詳しく説明する前に、まずDMARCレコードがどのように検出されるかについて簡単に触れておきます。
メール受信者がDMARCの文脈でメールを処理する際、受信者は「From:」ヘッダーに記載されているドメインを抽出します。このドメインは、受信者が対応するDMARCレコードを検索する際の基準となります。受信者は、そのドメインに「_dmarc」というプレフィックスを付加し、DNSに対してTXTレコードの照会を行います。
ここで示した例では、抽出されたドメインは EUROPE.ENG.EXAMPLE.ORG です。受信側は、このドメインに「_dmarc」を追加し、DNS を照会して TXT レコードを探そうとします。 しかし、クエリの結果が何も返ってこない場合や、DMARCとは無関係な内容のTXTレコードが返ってきた場合はどうなるでしょうか。その場合、受信側はドメインから組織ドメイン（この例では EXAMPLE.ORG）を抽出し、ドメインの前に「_dmarc」を付けてTXTレコードをクエリすることで、再度DMARCレコードの検索を試みます。
このようにして、DMARCレコードの検出はわずか2回のDNSルックアップに抑えられます。これにはいくつかの便利な利点もあります。組織ドメインレベルで単一のDMARCレコードを公開するだけで、すべてのサブドメインを網羅することができます。 スパマーが独自のサブドメインを作成したとしても、考えられるすべてのサブドメインに対して個別のDMARCレコードを公開する必要はなく、それらをカバーするDMARCレコードを1つ公開するだけで済みます。もう1つの便利な点は、実際のすべてのサブドメインに対してDMARCレコードを公開すれば、それらのDMARCレコードが組織ドメインレベルで公開された設定を上書きすることです。
それでは、DMARCレコードがどのようなものか、そしてどのような機能を持つのかを見ていきましょう。
DMARCレコードは、タグと値のペアからなる単純なリストです。この例では、このDMARCレコードを公開しているドメイン……「v=DMARC1;」で始まっていることからDMARCレコードであることがわかります……は、「none」ポリシーを公開しており、すべてのXML形式の集計レポートを [email protected] へ送信するよう求めています。DMARCは、メールに影響を与えることなくドメインが情報を収集できるように設計されており、これがその実現方法です。つまり、「p=none 公開することで実現されるのです。
DMARCレコードの機能に関しては、設定オプションはかなりシンプルです。すべてのDMARCレコードは、プロトコルバージョンのタグで始まる必要があります。その後、ポリシーを設定できます。サブドメインにも適用されるポリシーを設定することも可能です……。例えば、自分のドメインがサブドメインを一切使用しないことが分かっている場合は、p=none組織ドメインに関するデータのみを収集しつつ、sp=rejectのポリシーを直ちに公開することができます。 pctタグは0から100までのスライダーのようなもので、公開されたポリシーを段階的に適用することができます。pct=1と設定すれば、本来ならDMARCポリシーの影響を受けるはずだったメールのうち、実際に影響を受けるのは100通に1通だけとなります。
また、SPFおよびDKIMによって生成される認証済み識別子が、DMARCドメインと完全に一致する必要があるかどうかを設定することもできます。ほとんどの場合、デフォルトの「relaxed」が推奨されますが、「strict mode」では、サブドメインに基づく識別子の整合を無効にすることができます。これは、委任されたサブドメインを使用して送信されるメールを管理できない環境にある場合などに有用です。
次の2つのタグ「rua」と「ruf」は、そのドメインに関するレポートをどこに送信すべきかを指定するために使用されます。レポートの内容が異なるため、収集と分析のために、それぞれ異なるメールアドレスにレポートが送信されます。
最後のタグは、レポートの形式や送信間隔の設定、およびDMARC検証に失敗した個々のメールの編集済みコピーを送信するタイミングに関するものです。最初の2つのタグは値が1つしかなく、あまり役に立ちません。また、最後のオプションは、ソフトウェアのバグにより一部のレポートプロバイダーでレポートの生成が無効になってしまうようです。そのため、これらのレポートを収集したい場合は、これらのタグを省略した方がよいかもしれません。
それでは、この概要の締めくくりとして、DMARCで利用可能なさまざまなポリシーについて説明し、DMARCが提供する2種類のフィードバックレポートについても簡単に見ていきましょう。
DMARCのポリシー設定は非常にシンプルです。「none」ポリシーを公開することができます。これは単に、「DMARCチェックに失敗したメールに対しては何も処理を行わず、レポートを送信してください」という意味です。 また、「quarantine」ポリシーを公開することもできます。これは、DMARCチェックに失敗したメールをすべてスパムフォルダに振り分けるよう受信側に指示するものです。スパムフォルダが存在しない場合、受信側はスパム対策スキャンの厳格度を高めるなど、そのメッセージをより厳重に扱うためのあらゆる手段を講じる可能性があります。
適用できる最後のポリシーは「reject」ポリシーです。これは、DMARCチェックに失敗したメールを、受信者がブロック（または受信拒否）するように指示するものです。画面上では、pctタグについてさらに詳しい説明が表示されます。rejectポリシーが設定されている状態でこのタグを使用すると、pctタグによって拒否されなかったメールの割合分が、代わりに隔離されることになります。
最後に、DMARCが提供する2種類のフィードバックレポートは、その性質が大きく異なります。 XMLベースの集計レポートは24時間ごとに生成され、メール受信者があなたのドメインをどのように認識しているかに関する包括的な統計情報が含まれています。これには、DMARCを完全に通過したすべてのメールも含まれます。2つ目の種類のフィードバックは、SPF、DKIM、またはその両方に失敗した個々のメールの編集済みコピーで構成されています。これらのレポートは、プライバシー上の懸念、データ量の多さ、あるいはDMARCを正確に導入するために必ずしも必要ではないという見解から、常に利用可能とは限りません。
dmarcianは、DMARCの導入を容易にするため、これら2種類のフィードバックを処理します。DMARCやdmarcianサービスに関するご質問には、喜んでお答えいたします。
DMARCの利用を開始するには、dmarcian.com にアクセスしてください。
ご質問は [email protected] までご連絡ください。ご視聴ありがとうございました！
