← RFC Reference

RFC 6186: メールサービス自動検出のためのSRVレコード

この仕組みが存在する理由

メールクライアントを設定するには、複数のサーバーホスト名、ポート、セキュリティ設定を知る必要があります。メール読み取り用のIMAP または POP3 サーバーと、送信用のサブミッションサーバーです。ほとんどのユーザーはこの情報を提供できません。SRVレコード以前は、メールクライアントは以下に依存していました：

• mail.example.comやimap.example.comのような一般的なホスト名を推測すること
• 専有の自動検出プロトコル（Microsoft Autodiscover、Mozilla ISPDB）
• 手動設定ガイド

RFC 6186は、任意のドメインで機能する標準的なDNSベースのメカニズムを提供します。ドメイン管理者がSRVレコードを公開すると、準拠したメールクライアントは正しいサーバーを自動的に検出できます。

仕組み

メールクライアントはユーザーのメールアドレスからドメインを抽出し、特定のサービス名の下のDNSでSRVレコードをクエリします。

SRVレコード形式

名前：     _service._proto.domain
タイプ：     SRV
内容：  priority weight port target

必須DNSレコード

example.comドメイン、メール：mail.provider.netでホストされている場合：

; メール受信（TLS上のIMAP）
_imaps._tcp.example.com.    IN SRV  0 1 993 mail.provider.net.

; メール受信（STARTTLSでのIMAP）
_imap._tcp.example.com.     IN SRV  0 1 143 mail.provider.net.

; メール受信（TLS上のPOP3）
_pop3s._tcp.example.com.    IN SRV  0 1 995 mail.provider.net.

; メール送信（TLS上のサブミッション）
_submissions._tcp.example.com. IN SRV  0 1 465 mail.provider.net.

; メール送信（STARTTLSでのサブミッション）
_submission._tcp.example.com.  IN SRV  0 1 587 mail.provider.net.

サービスの無効化

サービスが利用不可であることを示すには、ターゲットが.（単一のドット）のSRVレコードを公開します：

; POP3は提供していません
_pop3._tcp.example.com.     IN SRV  0 0 0 .
_pop3s._tcp.example.com.    IN SRV  0 0 0 .

重要な技術詳細

RFC 6186で定義されたサービス名

クライアント検出優先順位

1. _imaps._tcpを最初にクエリします（RFC 8314では暗黙的TLSはSTARTTLSより推奨）。
2. _imapsレコードがない場合、必須のSTARTTLSで_imap._tcpにフォールバック。
3. サブミッションでは、_submissions._tcp（ポート465）を_submission._tcp（ポート587）より優先。
4. SRVの優先度と重みフィールドを使用して、複数のサーバー間でロードバランシングとフェイルオーバーを実施。

TLS証明書検証

RFC 7817では、クライアントはサーバーのTLS証明書をユーザーのメールドメインではなく、SRVターゲットホスト名（例：mail.provider.net）に対して検証する必要があります。これにより、ホスティングプロバイダーは1つの証明書で多くのドメインを提供できます。

一般的な誤り

• SRVレコードをまったく公開しない。多くのドメインは専有の自動検出に依存するか、ユーザーが手動で設定することを想定しています。SRVレコードの公開は数分で完了し、標準に準拠したすべてのメールクライアントに役立ちます。
• STARTTLSバリアントのみを公開する。RFC 8314は暗黙的TLSを推奨しています。_imapsおよび_submissionsレコード（暗黙的TLS）を主要オプションとして公開し、STARTTLSバリアントをフォールバックとして公開します。
• SRVターゲットがCNAMEを指している。SRVターゲットはCNAMEではなくAまたはAAAAレコードである必要があります。これはDNSプロトコル要件（RFC 2782）です。SRVをCNAMEに指すと、解決失敗が発生する可能性があります。
• 使用されていないサービスを無効化し忘れている。POP3をサポートしていない場合、「ドット」SRVレコードを公開してクライアントに明示的に通知します。そうしないと、応答することのないポートをプローブする時間を費やす可能性があります。
• SRVターゲットとの証明書不一致。SRVレコードがmail.provider.netをターゲットにしている場合、そのサーバーのTLS証明書のSANにmail.provider.netが含まれている必要があります。不一致は証明書を検証するクライアントで接続失敗を引き起こします。

配信性への影響

• ユーザーの誤設定を削減します。自動検出により、より少ないユーザーが間違った設定を入力します。つまり、より少ない「送信できません」サポートチケットと、アウトボックスに留まるメッセージが少なくなります。
• 最初からTLSを強制します。SRV経由でTLS対応サービスのみをアドバタイズすることで、クライアントが暗号化されていない状態で接続を開始するのではなく、デフォルトで安全に接続することを保証します。
• スムーズなホスティング移行を実現します。メールを新しいプロバイダーに移動するときにSRVレコードを更新すると、クライアントは手動再設定なしで自動的に新しいサーバーを見つけます。
• サブミッションベストプラクティスを補完します。_submissionsのSRVレコードはクライアントを正しい認証されたサブミッションポート（RFC 6409）に向け、サブミッショントラフィックをMXリレートラフィックから適切に分離します。

Related RFCs