DMARCの技術的概要を簡単にまとめました。
このビデオは、DMARCに関するより大きなビデオシリーズの一部です。
トランスクリプトは次のとおりです。
この短いビデオは、DMARC（Domain-based Message Authentication, Reporting, and Conformance）の技術的概要です。
DMARCは、SPFまたはDKIMを使用して、電子メールのコンテンツとドメインの間のリンクを作成しようとします。 SPFとDKIMについては、別のビデオで解説しています。
DMARCが対象とするメールコンテンツは、From:ヘッダーにあるドメインである。 From:ヘッダーは、メールの送信元を示す唯一の情報で「あり、整形式メール 」であることが要求される。 このため、DMARCはFrom:ヘッダーにあるドメインをキーにしている。
DMARCは、Sender: ヘッダーを含め、他のヘッダーをキーにしない。 そのため、DMARCはFrom:ヘッダーにあるドメインのみをキーとする。
SPFとDKIMはどちらも、安定したドメインレベルの識別子を生成する技術です。 SPFとDKIMは自由に利用できる技術仕様であり、多くの異なるメールベンダーで広く実装されている。 DMARCは、SPFとDKIMが生成する結果と、その結果がFrom:ヘッダーに含まれるドメインと関係があるかどうかだけを気にしている。 SPFとDKIMによって生成される結果は、DMARCの世界では「Authenticated Identifiers」と呼ばれる。
DMARCの重要な概念は「識別子の整合性」である。 これは、SPFとDKIMの結果がDMARCのドメインに関連していなければ意味がない、ということを言い表したものである。 この主な理由は、SPFとDKIMの結果がDMARCのキーとなるドメインに関連しているかどうかを受信者が理解する簡単な方法が必要だからです。
このビデオの次のスライドでは、メール受信者の観点から識別子のアライメントが重要である理由を説明することを目的として、認証識別子のさまざまな組み合わせについて説明します。
この最初の例では、メール受信者がDMARCドメイン（From: ヘッダーにあるドメイン）が「bank.com」であるメールを受け取った。 さらに、SPFチェックの結果、ドメインは「bank.com」であった。 このメールにはDKIM署名がなかったため、この行には「なし」と表示されています。 メール受信者は、そのメールが 「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の世界では、セカンド・レベル・ドメインは組織ドメインと呼ばれる。 インターネット上のリソース、特にMozilla Foundationが管理している公開サフィックスリストを参照することで、メール受信者はbank.comが組織ドメインであり、mail.bank.comがbank.comと同じ組織ドメインを共有するサブドメインであることを知ることができます。 この場合、メールはDMARCに準拠しています。
この3番目の例は、興味深いことを示している。 SPFはbank.comまたはbank.comのサブドメインのAuthenticated Identifierを生成するのではなく、Authenticated Identifierはbanknewsletter.comである。 我々の知る限り、banknewsletter.comはbank.comを所有する同じエンティティによって所有・運営されている実在のドメインである。 あるいは… banknewsletter.comは、人々を騙して合法だと思わせようとする犯罪者によって所有・運営されている。 このようなドメイン間の関連付けを確実に維持し、伝達する方法は、送信者自身が関連付けのデータベースを作成するか、受信者が独自に維持するかのどちらかしかありません。 したがって、このメールはDMARCに準拠しておらず、公開されたDMARCポリシーの影響を受けることになる。
4番目の例を続けると、DKIMシグネチャを初めて見る以外は同じメールです。 この例では、DKIMによってbank.comというAuthenticated Identifierが得られ、DMARCに準拠しています。 つまり、メール受信者はSPFから来たAuthenticated Identifierを見て、banknewsletter.comがbank.comと何の関係もないことを知り、単に無視します。 受信者は、メッセージが本当にbank.comから来たというポジティブなシグナルを探しており、DKIMはそのようなシグナルを提供するので、メールはDMARCチェックを通過します。
この5番目の例は、すべてDMARCのメールである。 SPFとDKIMの両方がbank.comの認証済み識別子をもたらした。 受信者が気にするのはポジティブなシグナルを見つけることだけなので、ポジティブなシグナルが2つあることは二重に良いことですが、「ポジティブなシグナル」以上の意味はありません。 SPFとDKIMの両方が正しい結果をもたらすメールを送信する理由は、両方の技術が利用可能であることで、どちらか一方が（何らかの理由で）利用できなかったり失敗したりしても、メールがDMARCに準拠し続けることが可能になるからです。
この6番目の例は、「news.bank.com」がSPFとDKIMの両方の認証済み識別子であるという違いはあるが、同じことを示している。 大きな組織では、サブドメインを電子メールサービスプロバイダに委任して、サービスプロバイダが組織に代わって電子メールを送信できるようにするのが一般的です。 この例では、bank.comの所有者は、マーケティングベンダーがbank.comを使用してDMARC準拠のメールを送信できるように、「news 」のサブドメインを委任している可能性があります。
この作為的な例は、誰でもドメインを登録し、SPFとDKIMを設置できることを示している。 悪者がこのような明白なドメインを使っていたら、それは素晴らしいことではないだろうか？ それでも、SPFとDKIMがパスしてAuthenticated Identifierが得られたからといって、そのメールが良いものであったり、求められているものであったりするわけではない。
最後の例では、SPFによって「bark.com」という認証識別子が得られている。 これは、一部の詐欺師がメールの正当性を判断するために手作業で検査する人間を騙すために使うよく知られた攻撃である。 ぱっと見ただけで、「bark.com」が本当に銀行だと思わせてしまうのだ。 さらに悪いことに、文字エンコーディングのトリックを使って、レンダリングされたグリフが意図したドメインとまったく同じに見えるようにすることも可能だ。 機械はこのようなおふざけには騙されない。だからこそ、識別子の整合性チェックは人間ではなく機械が行うべきなのだ。
DMARCレコードがどのように見え、何ができるかを説明する前に、DMARCレコードがどのように発見されるかについて簡単に触れておこう。
電子メール受信者がDMARCの文脈で電子メールを処理するとき、受信者はFrom:ヘッダーにあるドメインを抽出する。 このドメインは、受信者が対応するDMARCレコードを探す際の基礎となる。 受信者はドメインにunderbar-dmarcプレフィックスを付け、DNSにTXTレコードを問い合わせる。
この例では、抽出されたドメインはEUROPE.ENG.EXAMPLE.ORGである。受信者はこのドメインにunderbar-dmarcを追加し、DNSに問い合わせ、TXTレコードを見つけようとするだろう。しかし、クエリの結果が何もないか、DMARCとは関係のない内容のTXTレコードだったらどうだろう。この場合、受信者は、ドメインから組織ドメインを抽出し…この場合EXAMPLE.ORGを抽出し、ドメインの前にunder-dmarcを追加してTXTレコードをクエリし、DMARCレコードを見つけようとする。
こうすることで、DMARCレコードの発見はわずか2回のDNSルックアップに制限される。また、この方法にはいくつかの便利な効果がある。 組織ドメインレベルで1つのDMARCレコードを公開し、すべてのサブドメインをカバーすることができます。 スパマーが独自のサブドメインを作成しても問題にはなりません。考えられるすべてのサブドメインに対して明示的なDMARCレコードを発行しなくても、それらをカバーするDMARCレコードを発行することができます。 もう一つの優れた点は、実在するすべてのサブドメインに対してDMARCレコードを発行することができ、それらのDMARCレコードは組織ドメインレベルで発行されたものを上書きするということです。
さて、次はDMARCレコードがどのようなもので、何ができるかを説明しよう。
DMARCレコードはタグと値のペアの単純なリストである。 この例では、このDMARCレコードを公開したドメインは… “v=DMARC1; “で始まるので、DMARCレコードであることがわかります… “none “ポリシーを公開しており、すべてのXMLベースの集計レポートを処理のためにreports@example.org。 DMARCは、ドメインが電子メールに影響を与えることなく情報を収集できるように設計されています。
DMARCレコードで何ができるかという点では、オプションはかなり単純である。 すべてのDMARCレコードはプロトコルバージョンのタグで始まる必要がある。 その後、ポリシーを設定することができ、サブドメインに適用されるポリシーを設定することができます……たとえば、ドメインがサブドメインを使用しないことがわかっている場合、p=noneを使用して組織ドメインのデータのみを収集しながら、sp=rejectポリシーを直ちに公開することができます。 pctタグは、0から100までのスライダーのようなもので、公開されたポリシーを徐々に展開することができます…pct=1とすると、DMARCポリシーの影響を受けるメールは、100通のうち1通だけになります。
SPFおよびDKIMによって生成される認証識別子が、DMARCドメインと正確に一致する必要があるかどうかも設定できる。 デフォルトの 「relaxed 」は、ほとんどすべての場合に好ましいが、「strict mode 」では、サブドメインに基づくIdentifier Alignmentを許可しないことができる。
次の2つのタグ、ruaとrufは、そのドメインに関するレポートの送信先を世界に知らせるために使用される。 レポートはそれぞれ異なるため、収集と分析のために、人々はレポートを異なるメールアドレスに送る。
最後のタグは、レポート形式、間隔、およびDMARCに失敗した個々の電子メールの冗長化されたコピーをいつ送信するかの設定に関するものです。 最初の2つのタグには1つの値しかないので、少し役に立ちません。また、最後のオプションは、ソフトウェアのバグにより、一部のレポートプロバイダーによるレポートの生成を無効にしているようです。
さて、DMARCが許可するさまざまなポリシーと、DMARCが提供する2種類のフィードバック・レポートを簡単に見て、この概要を終えよう。
DMARCのポリシーオプションは非常にシンプルです。 単に「DMARCチェックに失敗したメールには対処せずにレポートを送ってください」という意味の「なし」ポリシーを公開することができます。 DMARCチェックに不合格となったメールをスパムフォルダに振り分ける「隔離」ポリシーを公開することもできます。 スパムフォルダが存在しない場合、受信者は、スパム対策スキャンの攻撃性を上げるなど、より高度な疑いの目でメッセージを扱うためにできることは何でもするかもしれません。
最後のポリシーは 「reject 」ポリシーで、DMARCチェックで不合格になったメールを受信者にブロック、または拒否するように指示します。 この画面では、pctタグについてもう少し詳しく説明し、拒否ポリシーが適用されている状態でこのタグを使用すると、パーセンテージタグによって拒否されなかったメールのパーセンテージが、代わりに隔離されることを説明します。
最後に、DMARCが提供できる2種類のフィードバック・レポートは大きく異なります。 XMLベースのアグリゲートレポートは24時間周期で生成され、DMARCを完全にパスしたすべてのメールを含む、メール受信者があなたのドメインがどのように使用されているかについての包括的な統計情報を含んでいます。 2つ目のフィードバックは、SPF、DKIM、またはその両方に不合格となった個々のメールを再編集したものです。 これらのレポートは、プライバシーの懸念、量の懸念、またはDMARCを正確に導入するために必要ないという見解のため、常に利用できるわけではありません。
dmarcianは、DMARCの導入を容易にするために、両方のタイプのフィードバックを処理します。 DMARCやdmarcianサービスに関する質問にも喜んでお答えします。
DMARCを始めるには、dmarcian.comをご覧ください。
私たちがお手伝いします
Brandkeeperでは、メールセキュリティの専門家チームによるDMARCの導入から運用サポート及びコンサルテーション行っています。一旦はDMARCの導入をやってみたが運用を断念したお客様、または、導入時点でいくつものハードルであきらめた企業様のサポートも行っています。
お気軽にご連絡ください
