メールセキュリティは、根本的に異なる脅威に対処する複数の保護レイヤーに依存しています。STARTTLSはメールサーバー間の送信中にメッセージを暗号化し、一方DMARCは送信者のアイデンティティを認証しドメインなりすましを防止します。組織はしばしば一方が他方を置き換えると想定しますが、各プロトコルは異なる問題を解決します。そして両方を実装しないことは、メールインフラストラクチャに悪用可能なギャップを生み出します。

STARTTLSとDMARCの技術的および運用上の違いを理解することが、メールセキュリティプログラムが実際に直面する脅威から保護できるかどうかを決定します。認証なしの転送暗号化により、攻撃者は暗号化されたチャネルを通じて説得力のあるフィッシングメッセージを送信できます。暗号化なしの認証は、転送中のメッセージコンテンツを傍受にさらします。この比較では、各プロトコルがどのように機能するか、各プロトコルがどこで失敗する可能性があるか、包括的なメール保護のために両方を一緒にデプロイする方法を説明します。

I. STARTTLSが実際に行うこと(そして失敗する場所)

STARTTLSは、SMTPハンドシェイク中に平文のメール接続を暗号化されたTLS接続にアップグレードするSMTP拡張です。送信メールサーバーが受信メールサーバーに接続すると、STARTTLSはメッセージコンテンツが送信される前に暗号化をネゴシエートし、転送中のメールデータをネットワークレベルの傍受から保護します。

STARTTLSの仕組み:

1. 送信サーバーがポート587(送信)またはポート25(リレー)経由で受信サーバーに接続
2. 受信サーバーがSTARTTLS機能をアドバタイズ
3. 送信サーバーがSTARTTLSコマンドを発行
4. 両サーバーがTLSバージョンと暗号スイートをネゴシエート
5. メッセージ送信のための暗号化接続を確立

STARTTLSが失敗する可能性がある場所:

STARTTLSはデフォルトで日和見的です。つまり、送信サーバーは暗号化を試みますが、受信サーバーがSTARTTLSをサポートしていない場合、TLSハンドシェイクが失敗した場合、またはネゴシエーション中に攻撃者がダウングレード攻撃を実行した場合、平文にフォールバックします。一般的な失敗条件には以下が含まれます:

1. STARTTLSストリッピング攻撃: 攻撃者がSMTPセッションを傍受し、STARTTLS機能アナウンスを削除し、平文送信を強制します。送信サーバーは暗号化がブロックされたことに気付かずに配信を完了します。
2. 証明書検証の失敗: 受信サーバーが無効、期限切れ、または自己署名の証明書を提示した場合、多くの送信サーバーはメッセージを拒否するのではなく、平文で配信を完了します。
3. TLSバージョンと暗号ネゴシエーションの失敗: 誤って構成されたサーバーは、サポートされているTLSバージョン(例:一方がTLS 1.3を要求し、他方がTLS 1.0のみをサポート)または暗号スイートについて合意できず、接続が暗号化されていない送信にフォールバックする可能性があります。
4. サイレントフォールバック動作: 明示的に構成されていない限り、ほとんどのメールサーバーはSTARTTLSが失敗し、メッセージが平文で送信されたときに管理者に警告しません。

STARTTLSが保護しないもの:

• STARTTLSは送信者のアイデンティティを認証しません。攻撃者は暗号化された接続を介してなりすましメッセージを送信できます。
• STARTTLSはフィッシングやビジネスメール侵害を防止しません。暗号化は送信中のコンテンツを保護しますが、送信者の正当性は保護しません。
• STARTTLSは保存時の暗号化を強制しません。メッセージはサーバー間のネットワークホップ中のみ暗号化され、メールボックスやログには暗号化されません。

II. DMARCが実際に行うこと(そして失敗する場所)

DMARCは、SPFとDKIM認証結果を検証し、ドメインのアライメントをチェックすることで、メールメッセージが認可されたソースから発信されたことを認証します。DMARCが合格すると、受信メールサーバーは、メッセージがドメイン所有者によって認可された正当な送信者から送信されたという暗号化およびDNSベースの証拠を持ちます。DMARCが失敗すると、ドメイン所有者は受信サーバーにメッセージを隔離または拒否するよう指示します。

DMARCの仕組み:

1. 送信サーバーがSPF認証(送信IPを検証)とDKIM署名(メッセージ整合性を検証)を含むメッセージを配信
2. 受信サーバーがSPFとDKIMチェックを実行
3. 受信サーバーがドメインのDNS(_dmarc.example.com)からDMARCポリシーを取得
4. 受信サーバーがアライメントをチェック:SPF認証されたドメインまたはDKIM d=ドメインが表示されるFrom:ドメインと一致する必要がある
5. アライメントが合格すればDMARCが合格。そうでなければ、DMARCポリシー(p=none、p=quarantine、p=reject)が処理を決定

DMARCが失敗する可能性がある場所:

DMARCの合格は受信箱への配置を保証しません。DMARCの失敗は必ずしも即座の拒否を意味しません。強制は受信サーバーがポリシーを尊重するかどうかに依存し、多くの正当なシナリオが運用上の調整を必要とするDMARC失敗を引き起こします:

1. 転送シナリオ: メッセージがメーリングリストまたは自動転送を通じて転送されると、SPFは通常壊れ(転送サーバーのIPは元のドメインに対して認可されていない)、転送者がメッセージ本文や件名を変更した場合、DKIMも壊れる可能性があります。DKIMも失敗すると、正当なメッセージでもDMARCが失敗します。
2. SPFルックアップの失敗: DNSルックアップがタイムアウトした場合(temperror)、レコードが10回のDNSルックアップを超えた場合(permerror)、またはエンベロープ送信者がヘッダーFromアドレスと異なる場合(SPFは合格するがDMARCアライメントを提供しない)、SPFはサイレントに失敗する可能性があります。
3. DKIM署名の失敗: キーがDNSを更新せずにローテーションされた場合、メッセージコンテンツが転送中に変更された場合(免責事項追加者、アンチウイルススキャナー、またはトランスポートエージェントによる)、または署名ヘッダーが不正な形式の場合、DKIM署名は失敗します。
4. 認証が合格してもアライメントの失敗: メッセージはSPFとDKIMに合格できますが、SPF認証されたドメインもDKIM d=ドメインも表示されるFrom:ドメインとアライメントしていない場合、DMARCは依然として失敗します。これは、顧客のドメインではなく自分のドメインで署名するサードパーティ送信者でよく発生します。
5. ポリシー強制の変動性: DMARC p=rejectは受信サーバーにSMTP配信中にメッセージを拒否するよう指示します。受信サーバーによって尊重される場合、メッセージはSMTP配信中に拒否され、受信箱やスパムフォルダに到達しないはずです。ただし、強制は受信サーバーがポリシーを尊重するかどうかに依存します。一部の転送者、メーリングリスト、および誤って構成された受信者は、指定されたようにDMARCを強制しません。

DMARCが保護しないもの:

• DMARCはメッセージコンテンツを暗号化しません。認証されたメッセージは、STARTTLSが使用されていない場合、転送中に傍受される可能性があります。
• DMARCはメッセージコンテンツの正確性を検証せず、送信者のアイデンティティのみを検証します。
• DMARCはアカウント侵害を防止しません。攻撃者が正当なメールアカウントへのアクセスを得た場合、そのアカウントから送信されたメッセージはDMARCに合格します。

III. 技術的比較:STARTTLS vs DMARC

IV. なぜ両方が必要なのか(どちらか一方ではない)

STARTTLSとDMARCは代替的なセキュリティオプションではありません。異なる攻撃ベクトルに対処する補完的なプロトコルです:

1. 認証なしのトランスポート暗号化により、なりすましフィッシングメッセージが暗号化されたチャネル経由で配信されます。 攻撃者はあなたの会社からのものと主張するなりすましメッセージを送信でき、攻撃者のメールサーバーがSTARTTLSをサポートしていれば、メッセージは被害者の受信箱に安全に配信されますが、被害者は送信者の真正性を確認する方法がありません。
2. トランスポート暗号化なしの認証は、転送中のメッセージコンテンツを傍受にさらします。 メッセージがDMARCに合格し、送信者が正当であることを証明しても、STARTTLSが強制されていない場合、メッセージコンテンツはネットワークレベルの攻撃者によって傍受される可能性があります。
3. ビジネスメール侵害攻撃は両方のギャップを同時に悪用します。 攻撃者は、DMARC強制のないドメインから、暗号化されていないまたはダウングレードされたSMTP接続を介してなりすましメッセージを送信し、配信の成功を最大化し、フォレンジック証拠を最小化します。

PCI DSS、HIPAA、GDPR、NIS2などのコンプライアンスフレームワークの対象となる組織は、一般的にメールセキュリティプログラムの一部としてSTARTTLSとDMARCの両方を実装します。STARTTLSは送信中のデータ保護をサポートし、DMARCはアンチフィッシング、アンチなりすまし、および送信者の説明責任の目的をサポートします。

V. STARTTLSだけでは不十分な場合

メールインフラストラクチャ全体にSTARTTLSをデプロイすると、送信中のメールコンテンツが暗号化されますが、送信者の認証やドメインなりすましには対処しません。STARTTLSだけでは不完全な保護を提供するシナリオ:

1. あなたのドメインを使用したフィッシング攻撃: 攻撃者があなたのドメインをなりすまし、顧客にフィッシングメッセージを送信します。攻撃者のメールサーバーがSTARTTLSをサポートしている場合、メッセージは暗号化された接続を介して配信され、受信者はメッセージが詐欺であるという技術的シグナルを持ちません。
2. 認証が弱いサードパーティ送信者: あなたの会社がマーケティングプラットフォーム、サポートチケットシステム、またはHRプラットフォームを使用して、あなたに代わってメールを送信しています。これらの送信者があなたのSPFレコードに含まれておらず、あなたのドメインを使用してDKIMで署名せず、あなたのドメインがDMARCポリシーを公開していない場合、受信者はこれらのメッセージが正当であることを確認できません。
3. 配信後の攻撃: STARTTLSは送信中のメッセージを保護しますが、メッセージが受信者のメールボックスに配信されると、トランスポート暗号化によって保護されなくなります。攻撃者が受信者のメールボックスまたはWebメールセッションを侵害した場合、STARTTLSは保護を提供しません。

VI. DMARCだけでは不十分な場合

DMARCをp=rejectでデプロイすると、攻撃者があなたのドメインをなりすますことを防止しますが、転送中のメッセージコンテンツを傍受から保護しません。DMARCだけでは不完全な保護を提供するシナリオ:

1. 転送中の機密データの露出: あなたの会社が財務諸表、医療記録、法的文書、または給与情報をメールで送信します。STARTTLSが強制されていない場合、これらのメッセージは平文で送信され、ネットワークレベルの攻撃者によって傍受される可能性があります。
2. 暗号化されていないチャネル経由の認証情報の収集: あなたの会社がパスワードリセットリンク、アカウント確認トークン、または認証コードを送信します。STARTTLSが強制されていない場合、攻撃者はこれらのメッセージを傍受し、メッセージがDMARCに合格してもアカウントアクセスを得ることができます。
3. コンプライアンスのギャップ: 多くのコンプライアンスフレームワークは転送中のデータの保護を強調しています。DMARCは送信者のアイデンティティを認証しますが、コンテンツを暗号化しません。DMARCのみに依存する組織は、送信中の適切なデータ保護を示すことができない可能性があります。

VII. STARTTLSとDMARCを一緒にデプロイする方法

包括的なメールセキュリティアーキテクチャは、STARTTLSとDMARCの両方を使用し、トランスポートダウングレード攻撃とドメインなりすましのリスクを減らす強制ポリシーを使用します。

STARTTLSデプロイメントチェックリスト

以下のチェックリストを、メールインフラストラクチャ全体でSTARTTLSをデプロイおよび強制するための実用的な出発点として使用してください。正確な要件は、メールサーバープラットフォーム、アウトバウンドリレー構成、およびコンプライアンス目標によって異なります。

• アウトバウンドメールサーバーがポート587(送信)およびポート25(リレー)でSTARTTLSをサポートし、すべてのアウトバウンドSMTPセッションで暗号化を試みるように構成されていることを確認します。
• インバウンドメールサーバーがSTARTTLS機能をアドバタイズし、最新のTLSバージョン(TLS 1.2以上)と強力な暗号スイート(RC4、3DES、およびエクスポート暗号を避ける)をサポートしていることを確認します。
• メールサーバーホスト名の有効なTLS証明書をデプロイし、証明書が信頼できる証明機関によって発行され、期限切れでなく、すべてのメールサーバーホスト名の正しいSubject Alternative Names(SAN)を含むことを確認します。
• 可能な場合、送信メールサーバーがSTARTTLS接続の証明書検証を要求するように構成し、証明書検証が失敗した場合は接続を拒否します。
• MTA-STSポリシー(MTA-STSのHTTPS経由)を公開して、インバウンドメールのSTARTTLSを強制し、送信サーバーに暗号化を要求し、STARTTLSが失敗した場合は配信を拒否するよう指示します。
• DNSにTLS-RPTレコード(例:_smtp._tls.example.com)を公開して、送信サーバーがSTARTTLS経由で配信に失敗したときにレポートを受信し、接続失敗、証明書エラー、ダウングレード試行を可視化します。
• TLS-RPT集計レポートを監視して、STARTTLS経由での接続に失敗した送信ドメインを特定し、失敗がインフラストラクチャの問題またはダウングレード攻撃を示すかどうかを調査します。
• Checktls などのツールを使用するか、SMTPセッションを手動でテストして(openssl s_client -starttls smtp -connect mail.example.com:25)、STARTTLS構成をテストします。

DMARCデプロイメントチェックリスト

以下のチェックリストを、ドメイン全体でDMARC認証をデプロイおよび強制するための実用的な出発点として使用してください。正確な要件は、認可された送信者のエコシステム、サードパーティ統合、および強制準備状況によって異なります。

• すべての認可された送信者を監査します:マーケティングプラットフォーム、サポートツール、給与システム、HRプラットフォーム、CRMシステム、およびあなたのドメインを使用してメールを送信するトランザクションメールサービス。
• 各送信ドメインのSPFレコードを公開し、すべての認可された送信IPとサードパーティ送信者のSPF includeメカニズム(例:Google Workspaceの場合はinclude:_spf.google.com)を含めます。SPFレコードが10-DNS-lookup制限内に収まることを確認します。
• すべての認可された送信者のDKIM署名を構成し、表示されるFrom:ドメインとのアライメントを確保するために、DKIM d=タグであなたのドメイン(サードパーティ送信者のドメインではない)を使用します。
• Skysnagを通じてDMARC監視を開始し、ドメイン用の管理されたDMARCレコードを生成します。Skysnagはアカウントの正しいレポート先を含むDMARCレコードを生成し、集計レポートを自動的に監視します。
• DMARC集計レポートをレビューして、認証失敗、認証されていない送信者、なりすまし試行、およびSPFまたはDKIM構成の更新が必要な正当な送信者を特定します。
• SPFレコードの更新、DKIM署名構成の修正、サードパーティ送信者設定の調整、またはあなたのドメインで署名するためのベンダーとの調整によって、認証失敗を解決します。
• SPFとDKIMの合格率が一貫して高い(認可された送信者全体で95%以上の合格率)場合、DMARCポリシーをp=quarantineに移行し、受信サーバーに認証されていないメッセージをフィルタリングするよう指示します。
• 運用上の信頼性が高い場合、DMARCポリシーをp=rejectに移行し、認証されていないメッセージを完全にブロックし、ドメインなりすまし攻撃を防止します。

主要な戦略としてパーセンテージベースのロールアウトに依存しないでください。現在のDMARC対応プログラムは、ドメイン、サブドメイン、送信者グループ、およびビジネス機能ごとに強制をステージングする必要があります。

VIII. STARTTLS + DMARC + MTA-STS:完全なスタック

MTA-STS(Mail Transfer Agent Strict Transport Security)は、インバウンドメールのSTARTTLSを強制し、ダウングレード攻撃を防止し、送信メールサーバーがあなたのドメインに配信する際に暗号化を要求することを確保します。STARTTLSが日和見的である場合、攻撃者はSTARTTLS機能アナウンスを削除し、平文配信を強制できます。MTA-STSは、送信サーバーに暗号化を要求し、STARTTLSが失敗した場合は配信を拒否するよう指示するHTTPSポリシーを公開することで、このリスクを排除します。

MTA-STSデプロイメント:

1. https://mta-sts.example.com/.well-known/mta-sts.txtでMTA-STSポリシーを公開し、以下の構造にします:version: STSv1 mode: enforce mx: mail.example.com max_age: 86400
2. MTA-STS DNSレコードを公開します:_mta-sts.example.com. IN TXT "v=STSv1; id=20260115T120000"
3. ポリシーが変更されるたびにid=値を更新して、送信サーバーにポリシーを再取得させます。

MTA-STSが保護しないもの:

• MTA-STSはインバウンドメール(あなたのドメインに送信されたメッセージ)のSTARTTLSのみを強制します。アウトバウンドメール(あなたが他のドメインに送信するメッセージ)のSTARTTLSを強制しません。
• MTA-STSはなりすましを防止しません—暗号化のみを確保します。認証にはまだDMARCが必要です。

完全なスタックを一緒にデプロイする:

• STARTTLSが送信中のメールコンテンツを暗号化
• DMARCが送信者のアイデンティティを認証し、なりすましを防止
• MTA-STSがSTARTTLSを強制し、ダウングレード攻撃を防止
• TLS-RPTがSTARTTLS接続失敗を可視化

この組み合わせにより、メッセージが認証され暗号化され、強制ポリシーがなりすましと傍受の両方を防止することが保証されます。

IX. 運用上の考慮事項:どのプロトコルを最初に優先するか

リソースが限られている組織は、STARTTLS強制の前にDMARCデプロイメントを優先する必要があります。理由は2つあります:

1. DMARCはより広範な脅威カバレッジを提供します: フィッシング、ビジネスメール侵害、およびドメインなりすまし攻撃は、メール転送中のネットワークレベルの傍受よりも一般的です。DMARCは、攻撃者があなたのドメインをなりすますことを直接防止します。
2. DMARCはメールエコシステムの可視性を提供します: DMARC集計レポートは、シャドウIT、認可されていないサードパーティサービス、および存在を知らない可能性のあるレガシーシステムを含む、あなたのドメインを使用するすべての送信者を明らかにします。この可視性は、認証または暗号化ポリシーを強制する前に必要です。

ただし、機密データを扱う組織(金融サービス、医療、法律、政府、防衛請負業者)は、両方のプロトコルを並行してデプロイする必要があります。HIPAA、PCI DSS、GDPRなどの規制フレームワークは転送中のデータの保護を強調しており、MTA-STSを通じたSTARTTLS強制は、送信中にメールコンテンツが暗号化されていることを示します。

X. SkysnagがSTARTTLSとDMARCデプロイメントをサポートする方法

Skysnag Protectは、DMARC監視、ポリシー強制、および送信者発見を自動化し、組織がビジネスクリティカルなメールフローを中断することなく、p=noneからp=rejectに移行しながら運用上の可視性を維持するのを支援します。

Skysnag Protect機能:

• 自動化されたDMARC集計レポートの解析と分析
• 認証失敗、なりすまし試行、および構成エラーのリアルタイムアラート
• 送信者の発見と分類(認可済み、未認可、サードパーティ)
• p=quarantineまたはp=rejectに移行する前に強制の影響をテストするポリシーシミュレーション
• 認証失敗を解決するためのSPFとDKIMのトラブルシューティング

TLS-RPT監視の場合:
SkysnagはTLS-RPT集計レポートもサポートし、MTA-STSがデプロイされたときにSTARTTLS接続失敗、証明書エラー、およびダウングレード試行を可視化します。

SkysnagでDMARC監視を開始し、無料のDMARCレコードを取得してください。MTA-STS強制のためのTLS-RPT監視が必要な場合は、TLS-RPT解析とアラートを有効にするためにチームにお問い合わせください。

XI. 重要なポイント

• STARTTLSはメールサーバー間の送信中にメールコンテンツを暗号化し、ネットワークレベルの傍受から保護します。DMARCは送信者のアイデンティティを認証し、ドメインなりすましを防止します。包括的なメール保護には両方のプロトコルが必要です。
• STARTTLSはデフォルトで日和見的です。つまり、暗号化が失敗した場合、送信サーバーは平文にフォールバックします。MTA-STSはインバウンドメールのSTARTTLSを強制し、ダウングレード攻撃を防止し、メッセージが暗号化された接続を介して配信されることを確保します。
• DMARCの合格は暗号化を保証しません。STARTTLSの強制は送信者の真正性を保証しません。1つのプロトコルのみをデプロイする組織は、メールセキュリティアーキテクチャに悪用可能なギャップを残します。
• ほとんどの組織では、フィッシングとドメインなりすまし攻撃がネットワークレベルの傍受よりも一般的であるため、DMARCを最初に優先する必要があります。ただし、機密データを扱う組織は、DMARCとMTA-STSの両方を並行してデプロイする必要があります。
• 証明書検証が無効になっている場合、TLSネゴシエーションが失敗した場合、またはダウングレード攻撃が発生した場合、STARTTLSはサイレントに失敗する可能性があります。転送、メッセージ変更、またはサードパーティ送信者の誤った構成によりSPFまたはDKIM認証が壊れた場合、DMARCは失敗する可能性があります。
• Skysnag Protectを使用して、DMARC監視、ポリシー強制、および送信者発見を自動化します。SkysnagでDMARC監視を開始し、無料のDMARCレコードを取得してください。