DMARCはフィッシングフィルターではない：実際に保護するもの

DMARCは、設計時に想定されていなかった多くの役割を求められている。チームはこれをスパムフィルター、フィッシングフィルター、一般的な信頼シグナルとして使おうとする。だが、どれでもない。現在のDMARCプロトコル（RFC 9989で定義）は、意図的に狭い問いに答える。表示されているFromアドレスのドメインの所有者がこのメッセージを許可したか、そしてその許可が整合したSPFまたはDKIMの結果によって確立できるか、である。

その問いに答える価値はある。しかし、それはDMARCが得ている評判よりもはるかに狭い。境界線を正しく理解することは重要だ。なぜなら、p=rejectに到達すればフィッシング対策は完了だと思い込んだチームは、DMARCがカバーしない部分を補うコントロールをスキップしてしまうからだ。

メールが誰から送られたかを証明する仕組み

ここでは3つの用語が頻出するので、平易な言葉で説明する。SPFは、ドメインがメール送信を許可したサーバーの公開リストであり、受信者はメッセージが実際にそのうちの1つから来たかどうかを確認する。DKIMは、メッセージに追加される暗号署名で、受信者は署名ドメインから本当に送信され、転送中に改ざんされていないことを確認できる。DMARCはこれらを1つのものに結び付ける：表示されているFromアドレスだ。

この最後の用語は、聞こえる以上に重要だ。すべてのメールには2つの「from」アドレスがある。1つは表示されているFromで、メールアプリが表示する名前とアドレス（例：「Your Bank <alerts@your-bank.com>」）であり、人間が実際に読んで信頼する部分だ。もう1つは、配信のために舞台裏で使われる隠れたエンベロープアドレスで、ユーザーには見えない。攻撃者はこれら2つを異なる値に設定できる。これがまさに、メッセージが銀行からのように見えながら、別の場所に代わって配信される仕組みだ。DMARCの役割は、認証が隠れたアドレスではなく、見えるアドレスと一致することを確認することだ。

実際の見た目

3つすべては、ウェブサイトのアドレスが設定されるのと同じ場所、ドメインのDNS内のテキストレコードとして存在する。構文を覚える必要はないが、形を認識できると役立つ。

SPFレコードは、送信を許可された相手をリストする。これはGoogle Workspaceとマーケティングツールを許可し、それ以外は疑わしいとして扱うよう指示する：

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

include:エントリは各プロバイダーのサーバーリストを取り込み、-allは「これらのリストにない場合は、私たちではない」という意味だ。

DKIMレコードは署名鍵の公開部分を公開し、受信者がメールの署名を確認できるようにする。長い文字列が鍵そのものだ：

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ...AB"

最後にDMARCレコードがそれをまとめ、失敗したメッセージをどう処理するかを受信者に指示する。これは失敗を拒否し、レポートを送信するよう求めている：

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:reports@example.com"

ここでのp=rejectは、この記事の残りの部分で言及しているポリシーと同じであり、rua=は集約レポートの送信先アドレスだ。

合格が実際にどう決定されるか

DMARCはSPFとDKIMの上に位置し、それらを独立して評価する。メッセージが合格する方法は2つある：SPFが隠れたエンベロープドメインで合格し、そのドメインが表示されているFromドメインと整合するか、DKIM署名が検証され、その署名ドメインが表示されているFromドメインと整合するか。どちらかの整合した経路が成功すれば、DMARCは合格する。どちらも失敗すれば、不合格だ。「整合」とは、2つのドメインが同じ組織として数えるのに十分に一致することを意味する。

整合性は、ほとんどの説明が省略する部分であり、有用で検証可能な詳細がここにある。DMARCは2つの整合モードを定義している。緩和モード（デフォルト）では、2つのドメインは同じ組織ドメインを共有するだけでよい。したがって、mail.example.comからのDKIM署名は、example.comのFromと整合する。厳格モードでは、それらは同一でなければならず、同じ署名は失敗する。「SPF合格、DMARC不合格」を見て、両方が同時に真である理由を疑問に思ったことがあるなら、通常それはSPFが隠れたエンベロープドメインを確認したが、そのドメインが表示されているFromアドレスと十分に一致しなかったことを意味する。厳格対緩和モードは、密接に関連するドメインが同じと見なされるかどうかを決定する。

テストが決して検査しないものに注意：本文、リンク、添付ファイル、送信者の意図。これはコンテンツではなく、来歴のチェックだ。

DMARCが役立つ場面

DMARCが作られたケースは、正確なドメインのなりすましだ。誰かがyour-bank.comをFromアドレスに配置し、整合したSPFまたはDKIM結果を生成しない場合、p=rejectポリシーは参加受信者にメッセージを拒否するよう求める。ただし、受信者は最終的な処理の制御を保持し、ローカルポリシーや例外を適用できる。これは実際の保護であり、この特定の攻撃に対しては強力だ。また、以前はなかったものも提供する：集約レポート（RFC 9990で定義）は、参加受信者がドメインとして送信するのを観察した多くのシステムを明らかにし、攻撃者が見つける前に忘れられたマーケティングツールや誤設定されたリレーを発見する方法だ。

不足している点

似たドメイン。攻撃者はyour-bank-support.comを登録し、有効なSPFとDKIMを設定し、自分のドメインでDMARCに合格する。あなたのポリシーは、所有していないドメインには及ばない。すべての受信者にとって、そのメールは完全に認証されている。

表示名のなりすまし。表示名が「Your Bank Security」と読める一方、実際のアドレスはalerts@some-unrelated-domain.comだ。DMARCはドメインを検証し、ほとんどの人が実際に読むフレンドリ名は検証しない。メッセージは合格しても、なりすましであり得る。

乗っ取られたメールボックス。攻撃者がフィッシングされた資格情報で実際のアカウントにログインし、正当なプロバイダーを通じて送信する場合、メッセージは通常SPF、DKIM、DMARCに合格する。プロトコルの用語では、認証されたインフラを通じて送信されたからだ。認証は、実際のユーザーとそのユーザーのアカウントを制御する攻撃者を区別できない。

認証されているが悪意のあるドメイン。誰でもドメインを登録し、完璧な認証を設定できる。迷惑メールの送信者はこれを日常的に行う。totally-legit-invoices.comでの合格は、所有者がメールを許可したことを確認する。所有者が正直かどうかについては何も言わない。

スパムと受信トレイ配置。DMARCはスパムフィルターではなく、メールが受信トレイに届くかどうかを決定しない。フィルターはこれを1つの入力として考慮するかもしれないが、認証されたスパムは依然としてスパムであり、配置は独自のロジックを持つ別のシステムだ。

転送とメーリングリスト。正当な中間者は認証を壊す可能性がある。転送は、転送サーバーが元の送信者ドメインによって許可されていないため、SPFを壊すことが一般的だ。一方、メーリングリストは件名や本文を変更し、DKIMを無効にする可能性がある。したがって、正当なメッセージでも、誰も送信者をなりすましていないのにDMARCに失敗することがある。これは、執行が盲目的なp=rejectへの切り替えではなく、慎重な監視と是正に従うべき理由の1つだ。

認証は信頼ではない

合格は1つの事実を確立する：Fromアドレスのドメインが、SPFまたはDKIMを介して整合性を持ってこのメッセージを許可した。その事実は正確なドメインのなりすましを阻止し、誰があなたとして送信しているかの可視性を与える。確立しないのは、メッセージが真実であるか、行動しても安全かどうかだ。これらはコンテンツと意図の特性であり、認証チェックはそこに到達しない。これは率直に言う価値がある。なぜなら、DMARCが「フィッシングを阻止する」と示唆するベンダーは、顧客を上記のすべてのカテゴリーにさらすからだ。

SenderLedgerの立場は意図的に狭い：正当なメールを壊さずに執行に到達し、どの送信者があなたのものかを証明し、正確なドメインのなりすましを封じる手助けをする。それ以降のすべて（似たドメインの監視、メールボックス侵害の検出、人間の判断）は別の仕事であり、そうでないふりをすると、ドメインはp=rejectで誤った安心感を得ることになる。