RFC 1035 – ドメイン名: 実装および仕様
このRFCが存在する理由
1987年にRFC 1034と一緒に公開されたRFC 1035は、ドメインネームシステムの実装詳細を定義しています。DNSは汎用インフラですが、電子メールにとって絶対に重要です。すべてのメール配信はDNSルックアップで始まります—送信サーバーは受信者のドメインのメールを受け入れるサーバーを発見する必要があります。
RFC 1035は、レコードタイプ、クエリ形式、およびレスポンス構造を定義しており、これらがこれを可能にします。メールの場合、4つのレコードタイプが最も重要です：MX（メール交換ルーティング）、A（IPv4アドレス）、AAAA（IPv6アドレス、後にRFC 3596で定義）、およびTXT（SPF、DKIMキー、DMARCポリシーなどに使用されるテキストレコード）。
RFC 1035がなければ、ドメイン名をそのメールを処理するサーバーにマップする標準的な方法がありません。現代的なメールのすべての認証とルーティングメカニズムはそれに依存しています。
動作方法
送信MTAがuser@example.comへのメッセージを配信する必要がある場合、特定のDNSルックアップシーケンスに従います：
-
example.comのMXレコードをクエリしてください。レスポンスには1つ以上のメール交換器が含まれ、それぞれに優先度値があります（低い方が優先）。 - 優先度でソートしてください。複数のMXレコードが同じ優先度を共有する場合、送信者は負荷分散のためにそれらの間をランダム化します。
- MXホスト名をIPアドレスに解決してください。A（IPv4）またはAAAA（IPv6）クエリを使用します。
- ポート25の解決されたIPアドレスでメールサーバーに接続し、SMTPセッションを開始してください。
- 推奨MXに到達できない場合は、次に低い優先度を試してください。
- MXレコードが存在しない場合は、ドメイン自体のA/AAAAレコードにフォールバックしてください（RFC 5321に従って）。
主要な技術詳細
MXレコード—メールルーティング
MXレコードはメールルーティングの基盤です。ドメインをそのメールサーバーのホスト名にマップし、試行される順序を決定する優先度値を持ちます：
MXターゲットはホスト名である必要があります。決してIPアドレスではありません。送信MTAはA/AAAAクエリを使用してそのホスト名をIPに解決します。CNAMEを指すMXレコードは仕様では技術的に禁止されていますが、一部のリゾルバーはそれを許容します。
AレコードとAAAAレコード—IP解決
MXホスト名がわかったら、AレコードはIPv4アドレスを提供し、AAAAレコードはIPv6アドレスを提供します：
MXホスト名がAとAAAAの両方のレコードに解決される場合、送信MTAは独自の構成と接続に基づいて選択します。ほとんどの最新MTAはIPv6が利用可能な場合はそれを優先し、IPv4にフォールバックします。
TXTレコード—メール認証
TXTレコードは元々、ドメイン名にテキストデータを付加するための汎用メカニズムでした。メール認証はそれを広く採用しています：
TXTレコードは文字列ごとに255バイトに制限されていますが、単一のレコードは連結される複数の文字列を含むことができます。255バイトを超えるSPFレコードはこのように分割する必要があります。
Null MX — RFC 7505
メールを受け入れないドメインはNull MXレコード—優先度が0で"."（ルート）を指すMX—を公開できます。これは送信サーバーに配信を試みないよう指示し、遅延とバウンスを回避します：
TTLとキャッシング
すべてのDNSレコードには、リゾルバーがどのくらい長く結果をキャッシュするかを制御するTTL（有効期限）があります。MXレコードの場合、典型的なTTLは300から3600秒の範囲です。低いTTLはより高速なフェイルオーバーを可能にしますが、DNSクエリの量を増加させます。移行中に、キャッシュされたレコードが変更前に期限切れになるように、事前にTTLを削減してください。
DNSルックアップの例
user@example.comへの配信のための完全なDNSルックアップシーケンス：
よくある間違い
-
MXレコードをIPアドレスで指す。MXレコードはホスト名を指す必要があり、IPではありません。
MX 10 198.51.100.25は無効で、配信エラーを引き起こします。 - MXレコードをCNAMEで指す。MXターゲットはA/AAAAレコードに直接解決する必要があります。CNAMEを指すMXは仕様で禁止されており、異なるリゾルバー間で予測不可能な動作を引き起こします。
- メールサーバーIPの逆DNS（PTR）がない。RFC 1035では定義されていませんが、ほとんどの受信サーバーは、メールサーバーのIPアドレスが同じIPに戻す解決するPTRレコードを持つことを確認します。PTRレコードが欠落しているか一致していないと、スパムフィルターがトリガーされます。
- メールプロバイダー移行後にDNSを更新するのを忘れた。メールサービスを切り替えても古いMXレコードをそのままにしておくと、メールは古いプロバイダーに送られます。移行後に常にMXレコードを確認してください。
- 移行前にTTLを高く設定した。MXレコードのTTLが24時間で、プロバイダーを変更する場合、一部のサーバーは最大24時間、古い宛先への配信を続けます。少なくともスイッチの48時間前にTTLを300秒に低下させてください。
-
SPFの10ルックアップ制限を超える。SPF評価は
include:とredirect=ディレクティブに従い、それぞれが追加のDNSクエリを生成します。10を超えるルックアップは永続的なSPFエラーを引き起こします。SPFレコードをフラットに保ってください。 - MXレコードもAレコードもない。ドメインがMXレコードもA/AAAAフォールバックも持たない場合、そのドメインへのメールは配信不可能です。明示的なMXレコードを公開するか、少なくともAレコードを公開してください。
配信性への影響
- MXレコードが最初にチェックされます。MXレコードが欠落、設定が間違っている、または到達不可能なサーバーを指す場合、メールは到達しません。これは最も基本的な配信性の要件です。
- SPF、DKIM、およびDMARCはすべてDNSにあります。すべてのメール認証チェックはTXTレコードルックアップで始まります。DNSが遅い、信頼できない、または設定が間違っている場合、認証は失敗し、メッセージはフラグが付けられるか拒否されます。
- 逆DNSは送信者の評判に影響します。フォワードおよび逆DNSが適切に設定されたメールサーバーは、受信サーバーによってより信頼されます。PTRレコードが一致していないか、欠落していると、スパムの強い信号となります。
- DNS伝播遅延は移行に影響します。メールプロバイダーを変更する場合、DNSキャッシングは移行が決してインスタントではないことを意味します。古いシステムと新しいシステムの両方がメールを受け入れる必要があるある期間を計画してください。
- IPv6には一致するAAAAとPTRレコードが必要です。IPv6アドレスから送信する場合、送信ホスト名のAAAAレコードとIPv6アドレスのPTRレコードが必要です。IPv6 DNSの不完全なセットアップは、IPv6を優先するプロバイダーへの配信エラーを引き起こします。