MailData

MTA-STSとは？MTA-STSの適切なポリシーを設定する

MTA-STSとは？MTA-STSの適切なポリシーを設定する

PPAPを廃止してSMTPの暗号化経路を確保する

2025年1月21日
著者: Maitham Al Lawati
翻訳: 竹洞 陽一郎

この記事はPowerDMARCのブログ記事 What is MTA-STS? Setup the Right MTA STS Policy の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

SMTP（Simple Mail Transfer Protocol）サーバ間の接続セキュリティを向上させるために広く知られているインターネット標準は、SMTP Mail Transfer Agent-Strict Transport Security（MTA-STS）です。
MTA-STSは、メールの受信時にTLS暗号化を強制することで、SMTPメールセキュリティの既存の問題を解決します。

重要なポイント

  1. SMTPは当初安全ではありませんでしたが、1999年にSTARTTLSによる暗号化機能が追加されました。しかし、ダウングレード攻撃や中間者攻撃（MITM攻撃）には依然として脆弱でした。
  2. MTA-STSは、メール転送中にTLS暗号化を強制し、サーバ間の通信を安全に保ち、攻撃を軽減します。
  3. MTA-STSは、ポリシーファイルとDNSレコードを使用して、サーバ間の安全なメール送信を強制します。
  4. MTA-STSは、「None」、「Testing」、「Enforce」の3つのモードをサポートしており、各モードは暗号化強制の厳密さを定義します。
  5. MTA-STSはTLS-RPTと連携し、暗号化の問題を監視して、メール配信の改善を確保します。
  6. PowerDMARCのようなホスティングソリューションは、組織におけるMTA-STSの導入を簡素化し、円滑なメールセキュリティを保証します。

MTA-STSの歴史と起源

1982年、SMTPが初めて規定されましたが、メール転送エージェント間の通信を保護するための輸送レベルのセキュリティ機構は含まれていませんでした。
しかし、1999年にSMTPにSTARTTLSコマンドが追加され、サーバ間でのメールの暗号化をサポートするようになりました。
これにより、非安全な接続をTLSプロトコルを使用して暗号化された安全な接続に変換する能力が提供されました。

では、SMTPがサーバ間接続を保護するためにSTARTTLSを採用した場合、なぜMTA-STSへの移行が必要だったのか、そしてそれが何を行ったのかについて疑問に思うかもしれません。
次のセクションでそれを詳しく見ていきましょう！

MTA-STSとは何か？（Mail Transfer Agent Strict Transport Security – 解説）

MTA-STSは「Mail Transfer Agent – Strict Transport Security」の略です。
これは、暗号化されたSMTP接続を介してメールを安全に送信することを保証するセキュリティ標準です。
「MTA」とは「Message Transfer Agent」の略で、コンピュータ間で電子メールを転送するプログラムを指します。
「STS」とは「Strict Transport Security」の略で、この標準を実装するために使用されるプロトコルを指します。

MTA-STSに対応したメール転送エージェント（MTA）またはセキュアメッセージ転送エージェント（SMTA）は、この仕様に従って動作し、暗号化されていないネットワーク上でメールを送信するための安全なエンドツーエンドチャネルを提供します。

MTA-STSプロトコルは、SMTPクライアントがサーバのアイデンティティを検証し、サーバが偽者でないことを確認できるようにします。
これは、サーバがTLSハンドシェイク中に証明書のフィンガープリントを提供することを要求することで実現されます。
クライアントはその後、既知のサーバの証明書を含む信頼ストアに対して証明書を検証します。

MTA-STSメールセキュリティの導入

MTA-STSは、SMTP通信中のセキュリティのギャップを埋めるために導入されました。
セキュリティ標準として、MTA-STSは暗号化されたSMTP接続を介してメールを安全に送信することを保証します。

「MTA」とは「Message Transfer Agent」の略で、コンピュータ間で電子メールを転送するプログラムを指します。
「STS」とは「Strict Transport Security」の略で、この標準を実装するために使用されるプロトコルを指します。

MTA-STSに対応したメール転送エージェント（MTA）またはセキュアメッセージ転送エージェント（SMTA）は、この仕様に従って動作し、暗号化されていないネットワーク上でメールを送信するための安全なエンドツーエンドチャネルを提供します。

MTA-STSプロトコルは、SMTPクライアントがサーバのアイデンティティを検証し、偽者に接続しないようにすることを可能にします。
これは、サーバがTLSハンドシェイク中に証明書のフィンガープリントを提供することを要求することで実現されます。
クライアントは、その後、既知のサーバの証明書を含む信頼ストアに対して証明書を検証します。

強制TLS暗号化への移行の必要性

STARTTLSは完全ではなく、2つの主要な問題を解決できませんでした。
1つ目の問題は、STARTTLSが任意の措置であるため、中間者攻撃（MITM攻撃）を防ぐことができない点です。
これは、MITM攻撃者が接続を簡単に改竄し、暗号化の更新を阻止できるためです。

2つ目の問題は、STARTTLSが実装されている場合でも、SMTPメールサーバが証明書を検証しないため、送信元サーバのアイデンティティを認証する方法がないことです。

今日では、ほとんどの送信メールがTLS（Transport Layer Security）暗号化で保護されています。
これは消費者向けのメールでも採用されている業界標準ですが、暗号化される前に攻撃者がメールを妨害したり改竄したりする可能性は依然としてあります。
もし、メールを安全な接続で送信しようとしても、データがサイバー攻撃者によって漏洩したり改竄されたりするリスクがあります。

ここでMTA-STSが登場し、この問題を修正します。
MTA-STSは、メールの安全な転送を保証するとともに、MITM攻撃を効果的に軽減します。
さらに、MTAはMTA-STSポリシーファイルを保存するため、攻撃者がDNSスプーフィング攻撃を仕掛けるのを困難にします。

MTA-STSはどのように機能するのか

MTA-STSプロトコルは、メールサーバが特定のサブドメインからポリシーファイルを取得できることを指定するDNSレコードを配置することで展開されます。
このポリシーファイルはHTTPSを介して取得され、証明書で認証されます。また、受信者のメールサーバの名前リストも含まれます。
MTA-STSの実装は、送信側よりも受信側のほうが容易です。受信側ではメールサーバソフトウェアの対応が必要ですが、PostFixなど一部のメールサーバがMTA-STSをサポートしていますが、すべてのサーバが対応しているわけではありません。

Microsoft、Oath、Googleなどの主要なメールサービスプロバイダはMTA-STSをサポートしています。
GoogleのGmailは最近、MTA-STSポリシーを採用しました。
MTA-STSは、対応するメールサーバにとって接続の保護を簡単かつアクセス可能にすることで、メール接続セキュリティの欠点を取り除きました。

ユーザからメールサーバへの接続は通常TLSプロトコルで保護され暗号化されていますが、MTA-STSが実装される以前はメールサーバ間の接続にセキュリティ上の欠陥がありました。
最近のメールセキュリティに対する意識の高まりや、世界中の主要なメールプロバイダのサポートにより、今後ほとんどのサーバ接続が暗号化されると予想されています。
さらに、MTA-STSはネットワーク上のサイバー犯罪者がメールの内容を読み取ることができないように効果的に保証します。

MTA-STSポリシーファイル

MTA-STSポリシーファイルは、プレーンテキスト形式のMTA-STS構成ファイルであり、ドメインのウェブサーバにHTTPS URLでホストされます。
このファイルは、メールサーバ間の安全な接続を確立するためのルール、TLS暗号化の強制、および安全な接続を確立できない場合の対応を定義します。 


https://mta-sts.<domain>/.well-known/mta-sts.txt
MTA-STSポリシーファイルの構造
フィールド説明例
versionMTA-STSポリシーフォーマットのバージョンSTS1
modeポリシーの適用レベル（以下の3つから選択: none、testing、enforce）testing
mxドメインの有効なメール交換（MX）サーバのリストmail.domain.com
max-age外部メールサーバがポリシーをキャッシュする期間（秒単位）86400

MTA-STSポリシーの例

version
STSv1
mode
enforce
mx
mail.example.com
backupmail.example.com
max_age
86400

MTA-STS導入の前提条件

MTA-STSのセットアップを開始する前に、以下が必要です。

  1. 登録済みのドメイン名
  2. 有効なTLS証明書
    • 信頼できる認証局（CA）から発行されたTLS証明書
    • 証明書が有効期限切れでないこと
    • 少なくともTLSバージョン1.2以上であること
  3. MTA-STS用のDNS TXTレコード
  4. HTTPSで通信するWebサーバ
  5. TLSを使用するように構成されたメールサーバ
  6. ポリシーファイルのmxフィールドに記載されたエントリと一致するメールサーバのホスト名
  7. テスト環境またはホスティングされたMTA-STSサービス
    • ログを監視し、必要に応じて調整を行うための環境

ドメインでのMTA-STS設定手順

以下の手順に従って、ドメインにMTA-STSを設定できます。

  1. ドメインに既存のMTA-STS設定があるか確認します。
    Google Workspaceを使用している場合、このガイドを利用すると簡単に確認できます。
  2. 各ドメインに対して個別に構成されたMTA-STSポリシーを作成します。
    MTA-STSポリシーファイルには、そのドメインで使用されるMTA-STS対応メールサーバを定義します。
  3. 作成したポリシーファイルをリモートサーバが簡単にアクセスできる公開ウェブサーバにアップロードします。
  4. 受信サーバに「メールはTLSで暗号化されている必要があり、これが守られている場合のみ受信者の受信トレイに許可される」という指示を与えるために、「_mta-sts」TXTレコードを作成し公開します。
  5. アクティブなポリシーファイルが有効になると、安全な接続がない限り、外部メールサーバはメールのアクセスを許可しません。

MTA-STSの3つのポリシーモード: None、Testing、Enforce

MTA-STSポリシーモードには以下の3つの値があります。

None
このポリシーはMTA-STS設定を無効化します。
外部サーバはプロトコルがそのドメインに対して非アクティブであるとみなします。
Testing
このポリシーでは、暗号化されていない接続で転送されたメールは拒否されません。
代わりに、TLS-RPT（TLSレポート）を有効にすると、配送経路やメール動作に関するTLSレポートを受信し続けます。
Enforce
Enforceポリシーが有効な場合、暗号化されていないSMTP接続で転送されたメールはサーバによって拒否されます。

MTA-STSの保護対象

MTA-STSは以下に対する保護を提供します。

TLSレポート: MTA-STS設定後のメール配信ギャップの監視

TLS-RPT（Transport Layer Security Reporting）は、ドメイン所有者がメール通信におけるTLS暗号化の失敗について詳細なレポートを受け取ることを可能にするプロトコルです。
TLS-RPTはMTA-STSと連携して動作します。

主な特徴

エラーレポート
TLS関連の問題（例: 証明書の有効期限切れ、古いTLSバージョン、TLS暗号化の失敗）による配信問題や失敗について詳細なレポートを提供します。
可視性
MTA-STSの実装やメール配信の問題を監視するのに役立ちます。
強化されたメールセキュリティ
TLS暗号化交渉の失敗によるエラーをトラブルシューティングすることで、MTA-STS設定の全体的な有効性を向上させます。
これにより、サイバー攻撃をより効果的に防止することが可能です。

PowerDMARCを使用した簡単なMTA-STS導入

MTA-STSの導入には、有効な証明書を持つHTTPS対応のWebサーバ、DNSレコード、および継続的な管理が必要です。
しかし、PowerDMARCのDMARCアナライザー・ツールを使用することで、これらをすべてバックグラウンドで処理し、負担を軽減できます。
一度セットアップすれば、その後は気にする必要がありません。

PowerDMARCを利用することで、組織でホスト型MTA-STSを手間なく導入することができます。
公開証明書の管理をせずに以下のサポートを提供します。

今すぐサインアップして、メールがTLSで暗号化された接続を介してドメインに送信されるように迅速に強制し、中間者攻撃（MITM）やその他のサイバー攻撃から接続を保護しましょう。