DMARCが保護するもの、そして保護しないもの

← すべての記事 インサイト DMARCが実際に保護するもの、そして保護しないもの 2026年8月3日 · 7分読む DMARCは、本来設計されていない多くの役割を求められています。 チームはそれをスパムフィルター、フィッシングフィルター、そして一般的な信頼信号として利用しようとします。 しかし、それらのどれでもありません。 現在のDMARCプロトコル（RFC 9989で定義）は、意図的に狭い質問に答えます。 「表示されているFromアドレスのドメインの所有者は、このメッセージを承認しましたか？そして、その承認は、アラインされたSPFまたはDKIMの結果を通じて確立できますか？」 その質問は答える価値があり、DMARCが獲得した評判よりもはるかに狭いものです。 p=reject（拒否）に設定したチームは、DMARCが未対応のすべてをカバーする制御をスキップしてしまう可能性があります。 メールが誰によって送信されたかをどのように証明するか 3つの用語が全体を通して出てきますので、それらを平易な英語で説明します。 SPFは、ドメインがメール送信を許可しているサーバーの公開リストです。受信者は、メッセージが実際にそれらのサーバーのいずれかから送信されたかどうかを確認します。 DKIMは、メッセージに追加される暗号署名です。受信者は、メッセージが署名ドメインから正当に送信され、転送中に改ざんされていないことを確認できます。 DMARCは、これら両方を1つのものに結び付けます。それは、表示されているFromアドレスです。 すべてのメールは2つの段階で処理され、各段階には独自の「from」アドレスがあります。 配信段階では、小包に貼られる住所のようなエンベロープアドレスが使用されます。メールサーバーはメッセージをルーティングするためにそれを読み取り、受信者はそれを見ることはありません。 その後、メッセージ自体は、メールアプリが表示する名前とアドレス（例：「あなたの銀行 <alerts@your-bank.com>」）である、表示されているFromアドレスを運びます。 これは人間が読み、信頼するものです。 2つは独立して設定されるため、攻撃者は表示されているFromアドレスにあなたの銀行を設定し、エンベロープアドレスを全く別の場所に指すことができます。 SPFはエンベロープアドレスをチェックします。DKIMの署名は独自のドメインを運びます。DMARCは、認証されたいずれかのものを表示されているFromアドレスに結び付けるために存在します。 これにより、認証が表示されているアドレスと一致するようになります。 これらが実際にどのように見えるか これら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つのドメインが同じ組織としてカウントされるのに十分に近いことを意味します。 フローチャート TD A[受信メール] --> S{SPFは認証され、Fromドメインとアラインしていますか？} S -->|はい| P([DMARCパス]) S -->|いいえ| D{DKIMは検証され、Fromドメインとアラインしていますか？} D -->|はい| P D -->|いいえ| F([DMARC失敗]) DMARCは、SPFまたはDKIMのいずれかが認証され、表示されているFromドメインとアラインした場合にパスします。どちらもそうでない場合にのみ失敗します。 アラインメントは、ほとんどの説明でスキップされる部分です。 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をパスします。 あなたのポリシーは、あなたが所有していないドメインには影響しません。 すべての受信者にとって、そのメールは完全に認証されています。 表示名詐称。 表示名は「あなたの銀行セキュリティ」と読み取られますが、実際のアドレスは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の立場は意図的に狭いです。 私たちは、あなたが到達するのを助けます