デジタルプラットフォームは、サービスが安全で、説明責任があり、悪用に耐性があることを証明するために、これまで以上に大きな圧力にさらされています。

欧州連合のデジタルサービス法(DSA)は、デジタルエコシステム全体でプラットフォームガバナンス、ユーザー保護、透明性、リスク管理、説明責任に関する期待を高めることで、この変化を加速させています。欧州委員会は、DSAをオンライン環境をより安全で信頼できるものにするために設計されたフレームワークと説明しています。(デジタル戦略)

DSAに関する議論のほとんどは、コンテンツモデレーション、違法コンテンツ、取引業者の追跡可能性、広告の透明性、システミックリスク、プラットフォームの説明責任に焦点を当てています。

しかし、あまり注目されない別のレイヤーがあります:

プラットフォームがユーザー、顧客、取引業者、パートナー、内部チームとどのようにコミュニケーションを取るか。

メールは、デジタル経済において最も重要な信頼チャネルの1つです。プラットフォームはメールを使用して、アカウントの確認、パスワードのリセット、ユーザーへの通知、販売者のサポート、ポリシー決定の伝達、セキュリティアラートの送信、業務ワークフローの管理を行います。

これらのメールが偽装、なりすまし、または悪用される可能性がある場合、プラットフォームの信頼性は弱まります。

ここでメール認証が戦略的に重要になります。

DMARC、SPF、DKIM、MTA-STS、TLS-RPTは、それ自体で組織を「DSA準拠」にするものではありません。DSAは、これらのプロトコルを名指しで義務付けていません。

しかし、欧州で運営されているプラットフォームにとって、メール認証は、現代のデジタル規制が組織に管理を期待する、より広範な信頼、安全、悪用防止、ガバナンスの目標をサポートします。

問題はもはや配信可能性だけではありません。

組織が、通信レイヤーが制御され、監視され、ドメイン悪用から保護されていることを示すことができるかどうかです。

I. DSAはデジタル信頼の基準を引き上げる

ドメインの棚卸しからMTA-STSの適用までを網羅した、メール認証導入のための6段階プロセス。

DSAは、欧州におけるより広範な規制運動の一部です:デジタルサービスは、より強い説明責任を持って運営されることが期待されています。

その説明責任は、プラットフォームのインターフェースで止まるものではありません。

ユーザーやステークホルダーとコミュニケーションを取るためにプラットフォームが使用するシステムにまで及びます。

プラットフォームには、強力なモデレーションポリシー、明確な利用規約、文書化されたエスカレーション手順があるかもしれません。しかし、攻撃者がプラットフォームのドメインを使用して、偽のアカウントアラート、偽の執行通知、偽の販売者通信、または偽のサポートメールを送信できる場合、信頼モデルは不完全です。

ユーザーにとって、メールはしばしばプラットフォーム自体のように感じられます。

パスワードリセットメール、販売者確認リクエスト、ポリシー違反通知、またはセキュリティアラートは、即座のアクションを引き起こす可能性があります。そのメッセージが詐欺的である場合、ユーザーはプラットフォームの悪用とプラットフォームの障害を区別できない可能性があります。

これが、メール認証がDSA時代の信頼に関する会話に属する理由です。

狭い法的チェックボックスとしてではありません。

プラットフォーム通信の信頼性を保護するための実用的な制御として。

II. メール認証が実際に保護するもの

SPFからTLS-RPTまでのメール認証プロトコルを示す5段階のフロー。

メール認証は、受信メールサーバーが、ドメインから来たと主張するメッセージが承認されているかどうかを判断するのに役立ちます。

コアプロトコルは連携して機能します:

  • SPFは、ドメインのメールを送信する権限があるサーバーを識別します。
  • DKIMは、メッセージが署名ドメインによって承認され、転送中に変更されなかったことを検証するための暗号署名を追加します。
  • DMARCは、ユーザーが見る可視的なFromドメインに認証を接続します。
  • MTA-STSは、サポートするメールサーバー間の暗号化されたメール転送を強制するのに役立ちます。
  • TLS-RPTは、TLS配信の問題に関するレポートを提供します。

プラットフォームオペレーターにとって、最も重要な制御はDMARCアライメントです。

メッセージは、次のうち少なくとも1つが真である場合にのみDMARCをパスします:

  • SPFがパスし、SPF認証ドメインが可視的なFromドメインと一致する。
  • DKIMがパスし、DKIM署名ドメインが可視的なFromドメインと一致する。

これが重要な理由は、ユーザーが認証ヘッダーを見ないためです。彼らは可視的なFromドメインを見ます。

DMARCは、その可視的なアイデンティティを保護するのに役立ちます。

DMARCがquarantineまたはrejectで強制される場合、ドメインの所有者は、認証とアライメントに失敗したメッセージをどのように処理するかを受信システムに伝えます。これは、攻撃者がプラットフォームの実際のドメインから直接来たように見えるメールを送信しようとする、完全一致ドメインスプーフィングを減らすのに役立ちます。

III. メール認証が解決しないこと

メール認証は強力ですが、完全な悪用防止プログラムではありません。

DMARCは、すべてのフィッシング攻撃を阻止するものではありません。類似ドメインの登録を防止しません。表示名なりすましを阻止しません。受信トレイへの配置を保証しません。不正検出、ユーザー教育、コンテンツモデレーション、アクセス制御、インシデント対応を置き換えるものではありません。

この区別は重要です。

メール認証は、プラットフォーム自身のドメインアイデンティティを保護します。

あらゆる形態のなりすましを排除するものではありません。

成熟した信頼プログラムには、両方が必要です:

  • 実際のドメインを保護するためのDMARC、SPF、DKIM。
  • 類似ドメインとなりすましインフラストラクチャに対処するためのブランド監視、悪用検出、削除ワークフロー。

DSA関連のプラットフォームにとって、この区別はプログラムをより信頼性の高いものにします。メール認証が、より広範な信頼と安全のアーキテクチャの一部として理解されていることを示します。

IV. プラットフォームが注意すべき理由

プラットフォームがユーザーやステークホルダーに送信する、8種類の重要なメールのチェックリスト。

プラットフォームは、ユーザーが依存するメールを送信します。

例には以下が含まれます:

  • アカウント確認メール
  • パスワードリセットメール
  • ログインアラート
  • 販売者または取引業者のオンボーディングメッセージ
  • ポリシー違反通知
  • セキュリティアラート
  • サポートケースの更新
  • 支払いと請求の通知
  • マーケットプレイス運営メール
  • 規制または法的通知

攻撃者がこれらの通信をなりすますことができる場合、影響は深刻になる可能性があります。

偽のポリシー通知は、販売者を騙して認証情報を提出させる可能性があります。偽のセキュリティアラートは、ユーザーをフィッシングポータルに押し込む可能性があります。偽のサポートメッセージは、顧客を詐欺にリダイレクトする可能性があります。偽の支払い通知は、プラットフォームへの信頼を損なう可能性があります。

信頼の観点から、プラットフォームは自身のドメインがこの方法で悪用される可能性を減らす責任があります。

DMARCは、プラットフォームが重要な質問に答えるのを支援することで、その責任をサポートします:

  • 当社のドメインのメールを送信する権限があるシステムはどれか?
  • 当社に代わって送信するサードパーティプラットフォームはどれか?
  • ユーザー向けメールは適切に認証されているか?
  • セキュリティとサポートメッセージは整合しているか?
  • 未知のソースが当社のドメインを使用しようとしているか?
  • 地域、キャンペーン、またはレガシードメインが露出しているか?
  • 認証失敗を時間経過とともに監視しているか?

これらは運用上の質問ですが、ガバナンス上の価値があります。

組織が通信レイヤーの整合性を積極的に管理しているかどうかを示します。

V. 隠れたリスク:部分的な保護

多くの組織は、まず主要ドメインを保護します。

これは良いスタートですが、十分ではありません。

プラットフォームは、多くのドメインとサブドメインを運用していることがよくあります:

  • メイン企業ドメイン
  • 製品ドメイン
  • サポートドメイン
  • マーケットプレイスドメイン
  • 販売者オンボーディングドメイン
  • 地域ドメイン
  • キャンペーンドメイン
  • 開発者またはAPIドメイン
  • レガシードメイン

攻撃者は、最も保護されたドメインを偽装する必要はありません。最も弱い信頼できるドメインを探します。

プラットフォームは、メインドメインでDMARCを強制しても、地域またはキャンペーンドメインを監視モードのままにしておく可能性があります。そのドメインは、ユーザーにとって信頼できるように見えるフィッシングキャンペーンで依然として悪用される可能性があります。

これはガバナンス上の問題を生み出します。

組織がドメインなりすましをリスクとして特定している場合、部分的な実装は時間の経過とともに防御が難しくなります。

成熟したプログラムは、最も目立つドメインだけでなく、完全なドメインポートフォリオをカバーする必要があります。

VI. サードパーティ送信者が最も複雑さを生み出す

現代のプラットフォームは、1つの場所からすべてのメールを送信することはほとんどありません。

複数のサービスに依存しています:

  • CRMプラットフォーム
  • マーケティングオートメーションシステム
  • カスタマーサポートツール
  • アイデンティティプロバイダー
  • 請求プラットフォーム
  • マーケットプレイス通知システム
  • トランザクションメールプロバイダー
  • 人事および内部コミュニケーションツール

各送信者は、承認、認証、整合される必要があります。

ここで多くのメール認証プログラムが破綻します。

ベンダーはSPFに含まれている可能性がありますが、DMARCアライメントに失敗します。別のプラットフォームはDKIMで署名しますが、プラットフォームのドメインの代わりに独自のドメインで署名します。ビジネスチームは、未承認の送信者からキャンペーンを開始する可能性があります。レガシーシステムは、適切な認証なしでメールを送信し続ける可能性があります。

これらのギャップは、セキュリティとガバナンスの両方の問題を生み出します。

より強い規制の期待のもとで運営されているプラットフォームにとって、サードパーティ送信者管理は非公式であってはなりません。ベンダーのオンボーディング、変更管理、セキュリティレビューの一部である必要があります。

VII. 実用的なDSA対応メール認証プログラム

正しいアプローチは、DMARCを簡単なDNSプロジェクトとして扱うことではありません。

正しいアプローチは、メール認証を制御された信頼プログラムとして扱うことです。

VIII. 1. 完全なドメインインベントリを構築する

プラットフォーム通信に使用されるすべてのドメインとサブドメインを特定することから始めます。

以下を含めます:

  • ユーザー向けドメイン
  • サポートドメイン
  • マーケットプレイスまたは取引業者ドメイン
  • 地域ドメイン
  • キャンペーンドメイン
  • トランザクションメールドメイン
  • レガシードメイン
  • 内部コミュニケーションドメイン

各ドメインについて、メールを送信するかどうか、誰が所有しているか、どのシステムが使用しているか、現在どのような認証ポリシーが実施されているかを文書化します。

IX. 2. すべての正当な送信者を特定する

送信者インベントリを作成します。

各送信ソースについて、以下を文書化します:

  • プラットフォームまたはベンダー名
  • ビジネスオーナー
  • メッセージタイプ
  • 送信ドメイン
  • SPF承認
  • DKIM署名ステータス
  • DMARCアライメントステータス
  • ボリューム
  • 重要性
  • 承認ステータス
  • レビュー日

このインベントリは、セキュリティ運用、ベンダー管理、コンプライアンス証拠の基盤となります。

X. 3. SPFとDKIMを整合させる

DMARCはSPFとDKIMに依存しています。

強制の前に、正当な送信者は整合したSPFまたは整合したDKIMをパスする必要があります。

SPFレコードには、承認された送信者のみを含め、DNS検索制限内に収める必要があります。DKIMは、すべての主要なユーザー向けおよびセキュリティに敏感な通信で有効にする必要があります。

可能な場合、サードパーティ送信者は、プラットフォームのドメインに整合したDKIMで署名する必要があります。これは、複雑なルーティングと転送シナリオにおいてSPFよりも信頼性が高いことがよくあります。

XI. 4. DMARC監視を開始する

強制に移行する前に、プラットフォームには可視性が必要です。

その可視性はDMARC監視から始まります。

推奨されるパスは、Skysnagを通じて無料のDMARC監視レコードを生成することです。これにより、組織は管理されたレポート送信先を取得し、セキュリティチームが、レビューされない可能性のある静的レコードを手動で構築することなく、認証データの収集を開始できます。

ここから始めます:

“`text id=”skysnag-signup”
https://app.skysnag.com/en/register/

ドメインが追加されると、SkysnagはDNSに公開するDMARCレコードを提供します。

従来の静的DMARC監視レコードは、次のようになります:

dns id=”dmarc-static-example”
v=DMARC1; p=none; rua=mailto:[email protected]

このアプローチは機能する可能性がありますが、誰かがレポートを積極的に受信、解析、分析、対応している場合のみです。

監視のない静的レコードは、誤った進捗感を生み出します。

この段階では、目標は強制ではありません。目標は可視性です。

監視するもの:

- DMARCをパスする正当な送信者

- DMARCに失敗する正当な送信者

- 未知のソース

- 大量メールストリーム

- サブドメインの動作

- 地域差

- スプーフィング試行

- サードパーティのアライメント問題

デフォルトでフォレンジック失敗レポートを有効にしないでください。機密情報が含まれる可能性があり、プライバシー、法務、セキュリティレビューの後にのみ使用する必要があります。

## 5. 強制に向けて移行する

正当な送信者が整合したら、強制に向けて移行します。

実用的なパスは:

1. 発見のために監視モードを使用する。

2. 選択したドメインまたはサブドメインをquarantineに移行する。

3. 正当な送信者の失敗を修正する。

4. 成熟したドメインをrejectに移行する。

5. 強制後も監視を続ける。

rejectに移行する前に、以下を確認します:

- 重要な送信者がDMARCをパスする。

- サードパーティプラットフォームが整合している。

- ビジネスオーナーが影響をレビューした。

- サポートチームが準備されている。

- ロールバック手順が存在する。

- 例外が文書化されている。

DMARC強制は、仮定ではなく証拠に基づいている必要があります。

## 6. 必要に応じてMTA-STSとTLS-RPTを追加する

DMARCは送信者認証を保護します。メールサーバー間の暗号化転送を強制するものではありません。

MTA-STSとTLS-RPTは転送レイヤーをサポートします。

MTA-STSは、ドメインがそのドメインへのメール配信時にサポートするメールサーバーがTLSを使用することを要求するポリシーを公開することを可能にします。TLS-RPTは、TLS配信の問題に関するレポートを提供します。

アカウント、サポート、マーケットプレイス、またはセキュリティ通信を送信するプラットフォームにとって、これらの制御は全体的なメール信頼チェーンを強化できます。

MTA-STSポリシーの例:

text id=”mta-sts-example”
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 86400

TLS-RPTレコードの例:

dns id=”tls-rpt-example”
_smtp._tls.example.com. IN TXT “v=TLSRPTv1; rua=mailto:[email protected]”
“`

XII. ガバナンスはDNSレコードよりも重要

強力なメール認証プログラムには所有権が必要です。

ガバナンスがなければ、認証態勢は漂流します。

新しいベンダーが追加されます。キャンペーンが開始されます。地域チームがドメインを作成します。DNSレコードが変更されます。DKIMキーがローテーションされます。レガシーシステムがアクティブなままです。

推奨されるガバナンス要素には以下が含まれます:

  • エグゼクティブスポンサー
  • セキュリティオーナー
  • DNSオーナー
  • コンプライアンスステークホルダー
  • 各送信者のビジネスオーナー
  • ベンダーオンボーディングプロセス
  • 変更管理ワークフロー
  • 例外プロセス
  • 定期的なレビューケーデンス
  • インシデント対応手順

ここでプログラムが防御可能になります。

DMARCレコードが存在するからではなく、組織がメール認証が所有され、監視され、維持されていることを示すことができるからです。

XIII. プラットフォームが維持すべき証拠

DSA関連組織にとって、証拠は重要です。

以下のドキュメントを維持します:

  • ドメインインベントリ
  • 送信者インベントリ
  • SPF、DKIM、DMARC、MTA-STS、TLS-RPTレコード
  • DMARCポリシー履歴
  • 認証レポート分析
  • 送信者修正
  • サードパーティ承認
  • 例外決定
  • ロールバック手順
  • 監視ケーデンス
  • インシデント対応アクション
  • 転送セキュリティ制御

この証拠は、プラットフォーム通信が組織のより広範な信頼と悪用防止プログラムの一部として積極的に管理されていることを示すのに役立ちます。

XIV. 実装チェックリスト

このチェックリストを実用的な出発点として使用してください。

  • [ ] プラットフォーム通信に使用されるすべてのドメインとサブドメインをインベントリ化する。
  • [ ] すべての内部およびサードパーティ送信ソースを特定する。
  • [ ] 各送信者をビジネスオーナーにマッピングする。
  • [ ] SPFレコードが承認された送信者のみを含むことを確認する。
  • [ ] SPF検索制限をレビューする。
  • [ ] 重要な送信プラットフォームでDKIMを有効にする。
  • [ ] SPFまたはDKIMアライメントが可視的なFromドメインと一致することを確認する。
  • [ ] Skysnagを通じてDMARC監視を開始し、生成された監視レコードを公開する。
  • [ ] 従来の静的DMARCレコードを使用している場合、レポートが積極的に収集およびレビューされていることを確認する。
  • [ ] 強制前にDMARCレポートを分析する。
  • [ ] 認証に失敗する正当な送信者を修正する。
  • [ ] 成熟したドメインをquarantineまたはrejectに移行する。
  • [ ] プライバシーおよび法務チームが承認しない限り、デフォルトのフォレンジックレポートを避ける。
  • [ ] サポート、マーケットプレイス、販売者、セキュリティ、ユーザー通知ドメインをレビューする。
  • [ ] サードパーティ送信者オンボーディング要件を確立する。
  • [ ] 必要に応じてMTA-STSとTLS-RPTを実装する。
  • [ ] 所有権とエスカレーションパスを定義する。
  • [ ] ガバナンスと監査準備のためのドキュメントを維持する。
  • [ ] 認証態勢を定期的にレビューする。

XV. Skysnag Complyがどのように支援するか

Skysnag Complyは、組織がメール認証の背後にある証拠と監視レイヤーを管理するのを支援します。

EU向けプラットフォームのために、Skysnag Complyは以下をサポートします:

  • ドメインインベントリの可視性
  • DMARC監視
  • SPFおよびDKIMアライメントの可視性
  • 未承認送信者の検出
  • サードパーティ送信者のレビュー
  • 強制準備追跡
  • コンプライアンス向けレポート
  • ガバナンスレビューのための証拠収集
  • 認証失敗への継続的な可視性

Skysnag ComplyはDSAをDMARC義務に変えるものではありません。

組織がメール認証が監視され、ガバナンスされ、より広範な信頼と悪用防止プログラムの一部として維持されていることを示すのを支援します。

XVI. 重要なポイント

デジタルサービス法は、DMARC、SPF、DKIM、MTA-STS、またはTLS-RPTを名指しで義務付けてはいません。

しかし、欧州で事業を展開するプラットフォームは、ユーザーの安全、プラットフォームの完全性、マーケットプレイスの運営、サポートワークフロー、およびインシデント対応における信頼できるメール通信の役割を無視すべきではありません。

DMARCは、完全一致ドメインのなりすましを削減するのに役立ちます。SPFとDKIMは認証シグナルを提供します。MTA-STSとTLS-RPTは、トランスポートセキュリティの可視性をサポートします。

これらの対策を組み合わせることで、組織はより防御可能なメール信頼態勢を維持することができます。

DSA関連プラットフォームにとって、問題は次のことだけではありません:

「DSAは明示的にDMARCを要求しているか?」

より重要な問いは次のとおりです:

「プラットフォーム通信が認証され、監視され、管理され、ドメイン悪用から保護されていることを実証できるか?」

これが、メール認証が戦略的に重要になる理由です。

SkysnagでDMARC監視を開始し、無料のDMARCレコードを取得してください: