RFC 7817: メール向けTLSサーバー識別確認の更新

Current Standard Transport Security Published March 2026

ELI5: HTTPS経由でウェブサイトに接続する場合、ブラウザはサーティフィケートがドメイン名と一致することを確認します。メールサーバーも、TLS経由で互いに接続する場合は同じことを行う必要があります。ただし、MXレコードを通じたメールルーティングはこれをより複雑にします。このRFCは、送信サーバーがサーティフィケートをチェックすべき正確な名前を定義します。

これが存在する理由

SMTPクライアントがリモートメールサーバーへのTLS接続を開始するとき（RFC 3207のSTARTTLSまたはRFC 8314の暗黙的TLS経由）、証明書を受け取ります。しかし、その証明書にはどのホスト名が表示される必要があるのでしょうか？

電子メールでは、受信者のドメインに直接接続しません。example.comのMXレコードを検索します。これはmail.hosting-provider.netを指している可能性があります。証明書にexample.comとmail.hosting-provider.netのどちらが表示されるべきでしょうか？答えは重要です。以下の理由により：

間違った名前をチェックすると、正当な証明書が拒否される
すべてチェックしないと、TLSは暗号化を提供しますが、認証は提供されません—中間者が任意の証明書を提示できる
電子メールホスティングプロバイダーは同じサーバーから数千のドメインを提供し、すべての顧客ドメイン用の証明書を取得することはできません

動作方法

RFC 7817は、サーバーがどのように検出されたかに応じて、クライアントがサーバーの証明書に対してチェックすべき参照識別子の明確な階層を定義しています：

識別チェック順序

MXホスト名—サーバーがMX検索経由で見つかった場合、受信者ドメインではなくMXホスト名（例：mail.hosting-provider.net）に対して証明書をチェックします。
受信者ドメイン—MXレコードがなく、クライアントがドメイン自体のA/AAAAレコードにフォールバックする場合、受信者ドメインに対してチェックします。
明示的な構成—サーバーが手動で構成された場合（例：送信サーバー）、構成されたホスト名に対してチェックします。

TLS接続フロー

; ステップ1：受信者ドメインのMXを解決
dig example.com MX
example.com.  IN  MX  10 mail.provider.net.

; ステップ2：MXホストに接続、SMTPを開始
220 mail.provider.net ESMTP ready
EHLO sender.example.org
250-mail.provider.net
250-STARTTLS
STARTTLS
220 Go ahead

; ステップ3：TLSハンドシェイク—「mail.provider.net」に対して証明書をチェック
; 証明書SAN: DNS:mail.provider.net, DNS:*.provider.net
; マッチが見つかった→識別が確認された

重要な技術詳細

証明書マッチングルール

フィールド	チェック	注釈
Subject Alternative Name (SAN)	優先	最初にSAN拡張内のDNS-IDエントリをチェック
Common Name (CN)	フォールバック	SAN DNS-IDエントリがない場合のみ（非推奨の実践）
ワイルドカード	左端のラベルのみ	`*.provider.net`は`mail.provider.net`にマッチしますが`a.b.provider.net`にはマッチしません

検出方法別の参照識別子

検出方法	証明書を照合	例
MX検索	MXホスト名	証明書は`mail.provider.net`にマッチする必要があります
A/AAAAフォールバック（MXなし）	受信者ドメイン	証明書は`example.com`にマッチする必要があります
SRVレコード（RFC 6186）	SRVターゲットホスト名	証明書はSRVターゲットにマッチする必要があります
手動構成	構成されたホスト名	証明書は管理者が設定したものにマッチする必要があります
MTA-STSポリシー（RFC 8461）	ポリシー内のMXホスト名	ポリシーはどのMX名が受け入れられるかを制限します

DANEとの相互作用

DANE（RFC 7672）がデプロイされている場合、DNS内のTLSAレコードはMXホスト名の証明書または公開鍵をピン留めします。DANEは従来のCA検証よりも強い識別保証を提供します。これは認証局を信頼することに依存しないためです—ドメイン所有者はDNSSEC署名されたDNSで直接期待される証明書データを公開します。

一般的な誤り

受信者ドメインに対して証明書をチェックする。 example.comのMXがmail.google.comを指す場合、証明書はexample.comではなくmail.google.comと表示されます。間違った名前をチェックするとTLSエラーが発生するか、検証をスキップすることを強制します。
無認証TLSに静かにフォールバックする。 多くのMTAは「日和見的TLS」を使用します—可能であれば暗号化しますが、証明書を検証しません。これはパッシブな盗聴から保護しますが、アクティブな攻撃からは保護しません。MTA-STSまたはDANEを使用して認証接続を必須にしてください。
MXホスト上の証明書を誤って構成する。 MXレコードがmx.yourdomain.comを指しますが、証明書がyourdomain.comのみをカバーする場合、証明書を検証する送信者は失敗します。証明書のSANにMXホスト名を含めることを確認してください。
証明書チェーン検証を無視する。 ホスト名検証は必要ですが十分ではありません。完全な証明書チェーンは信頼されたルートCAに検証する必要があります。期限切れまたは自己署名証明書は、名前が一致しても失敗します。
証明書を有効期限前に更新しない。 MXサーバー上の期限切れ証明書はTLSハンドシェイク障害を引き起こします。MTA-STSを実装する送信者は、期限切れ証明書のサーバーへのメール配信を拒否します。

配信性への影響

MTA-STS実装はこれに依存します。 受信ドメインがMTA-STSポリシーを公開する場合、送信サーバーはRFC 7817に従ってMX証明書を検証する必要があります。MX証明書が誤って構成されている場合、MTA-STS実装を強制する送信者（Gmailを含む）はメール配信を拒否します。
GoogleおよびMicrosoftは証明書を検証します。 主要なプロバイダーはアウトバウンドメール用の証明書検証をますます実行します。受信インフラストラクチャ上の誤って構成された証明書はこれらの送信者からの配信障害を引き起こします。
DANE/TLSAは最強の保証を提供します。 DANEはDNSSECに証明書を結びつけ、CA信頼依存性を完全に削除します。RFC 7817識別チェックと組み合わせると、認証され、暗号化されたメール転送を提供します。
TLSレポートは問題を明らかにします。 SMTP TLSレポート（RFC 8460）は、送信者がサーバーへのTLS接続経験で失敗した場合、証明書検証失敗を含むレポートを送信します。TLSRPTレコードを公開し、これらのレポートを監視してください。