← RFC Reference

DNSとメールルーティング

DNSがメール配信パス全体をどのように駆動するか — MXレコード、優先度とフェイルオーバー、A/AAAAフォールバック、Null MX、PTRレコード、および送信ドメインが必要なDNSレコード。

メールルーティングアルゴリズム

送信サーバーがuser@example.comへメッセージを配信する必要がある場合、RFC 5321セクション5で定義されている次のアルゴリズムに従います：

1. example.comのMXレコードをクエリ
2. MXレコードが存在する場合、優先度でソート（最小数=最高優先度）
3. 各MXホスト名について、そのAおよび/またはAAAAレコードを解決してIPアドレスを取得
4. 最高優先度のMXへの接続を試みます。失敗した場合は次を試します。
5. MXレコードが存在しない場合（NODATA応答）、ドメインのA/AAAAレコードにフォールバックして配信を試みます
6. MXレコードがNull MX（0 .）の場合、ドメインはメールを受け付けません — 永続的なエラーを生成します
7. ドメインがまったく存在しない場合（NXDOMAIN）、永続的なエラーを生成します

MXレコード

MX（メール交換器）レコードは、メールルーティングの主要なDNSレコードタイプです。ドメインを1つ以上のメールサーバーに優先度でマップします：

各レコードには2つの部分があります：

• 優先度（設定値） — 数値が小さいほど最初に試されます。送信サーバーは常に最小優先度のMXを最初に試みます。
• エクスチェンジ（ホスト名） — 接続するメールサーバー。IPアドレスではなくホスト名である必要があります。ホスト名はAまたはAAAAレコードを持つ必要があります。

優先度とフェイルオーバー

上の例では、送信者は最初にmx1.example.com（優先度10）を試します。そのサーバーに到達不可、4xxの一時エラーを返す、または接続がタイムアウトする場合、送信者はmx2.example.com（優先度20）、その後mx-backup.example.com（優先度30）を試します。

複数のMXレコードが同じ優先度を共有する場合、送信者はそれらの間でランダム化する必要があります。これはロードバランシングを提供します：

ここでは、3つのサーバーすべてが同じ優先度を持っています。送信サーバーは配信試行ごとにそのうちの1つをランダムに選択し、3つすべてにロードを分散します。

MXはホスト名を指す必要があり、IPではない

MXレコードのエクスチェンジフィールドはホスト名である必要があります。IPアドレスにすることはできません（RFC 5321はこの点について明確です）。ホスト名自体はAおよび/またはAAAAレコードに解決される必要があります。CNAMEであってはいけません — 一部のリゾルバーはCNAMEであるMXターゲットを許容しますが、これは技術的に禁止されており、相互運用性の問題を引き起こします。

MXはCNAMEを指してはいけない

これは一般的な設定ミスです。mx1.example.comがmail.provider.comを指すCNAMEの場合、一部の送信サーバーは配信に失敗します。MXターゲットの場合は常にA/AAAAレコードを使用します。

A/AAAAフォールバック

ドメインにMXレコードがまったくない場合（Null MXがない場合）、送信サーバーはドメインのAまたはAAAAレコードにフォールバックして、そこでSMTP配信を試みます。これは「暗黙のMX」ルールと呼ばれます。

送信サーバーはポート25の198.51.100.50への配信を試みます。これは機能しますが、アクティブにメールを送受信するドメインでは悪い慣行と見なされます。常に明示的なMXレコードを公開してください。

フォールバックはMXレコードがゼロの場合にのみ適用されます。MXレコードが存在するがすべてのMXホストに到達不可の場合、送信者はAレコードにフォールバックしません — メッセージを再試行のためにキューします。

Null MX：「このドメインはメールを受け付けない」

RFC 7505はNull MXを定義しています — ドメインがメールを受け付けないことを明示的に宣言する方法です：

エクスチェンジとしての単一ドット（.）と優先度0は、「配信を試みない」を意味します。送信サーバーは接続に時間を無駄にするのではなく、すぐに永続的なエラー（5.1.2 — 不正な宛先システム）を生成する必要があります。

Null MXを使用するケース：

• メールを送信するのみで受信しないドメイン
• 駐車ドメイン
• ウェブサイトホスティング専用に使用されるドメイン

Null MXがない場合、送信者はAレコードにフォールバックして、成功しないはずの接続試行に時間を無駄にします。

PTRレコード：逆引きDNS

PTRレコードはIPアドレスをホスト名に再マップします。これはAレコードの逆です：

PTRレコードはMXルーティングアルゴリズムの一部ではありませんが、配信性にとって重要です。ほとんどの大手メールボックスプロバイダーは接続サーバーのIPアドレスのPTRレコードを確認します：

• IPはPTRレコードを持つ必要があります（PTRなし=スパムの可能性が高い）
• PTRホスト名は同じIPに逆引きされる必要があります（フォワード確認済み逆引きDNS、またはFCrDNS）
• PTRホスト名は「ジェネリック」に見えるべきではありません（例：198-51-100-42.dynamic.isp.comは住宅用接続を示唆しています）

PTRレコードはIPアドレスブロックの所有者（通常はホスティングプロバイダーまたはISP）によって管理され、ドメインのDNSを通じて管理されません。PTRレコードを設定または変更するためにプロバイダーに連絡する必要がある場合があります。

送信ドメインが必要なDNSレコード

Mailer To Goのようなサービスを通じてメールを送信するドメインのDNSレコードの完全なセットは次のとおりです：

メールを送信するが受信しないドメイン（例：トランザクション型メール用のサブドメイン）の場合：

TTLに関する考慮事項

DNSレコードには、リゾルバーがそれらをキャッシュする期間を制御するTTL（生存時間）があります。メール関連レコードの場合：

• MXレコード： 1時間（3600）が一般的です。低いTTLはより高速なフェイルオーバーを可能にしますが、DNSクエリ負荷を増やします。
• SPF/DKIM/DMARCレコード： 1時間が一般的です。初期セットアップまたは変更時には短いTTL（300秒）を使用し、その後増やします。
• MXホストのA/AAAAレコード： 5分から1時間。IPの迅速な変更が必要な場合は短くします。

DNS変更を行うときは、変更前にTTLを削減し（古いTTLの有効期限が切れるまで待機）、変更を行い、確認してから、TTLを操作値に戻します。

DNSSECとメール

DNSSEC（DNS Security Extensions）は暗号署名をDNSレコードに追加し、スプーフィングとキャッシュポイズニングを防止します。メール用に、DNSSECは特に重要です、なぜなら：

• MXレコードを認証します — 攻撃者はDNSポイズニングによってメールを不正サーバーにリダイレクトすることはできません
• DANE（DNS-Based Authentication of Named Entities）に必要です。これはTLS証明書をDNSにバインドします
• SPF、DKIM公開鍵、およびDMARCレコードを認証します

DNSSECなしでは、ネットワーク攻撃者はDNS応答を偽造してメールをリダイレクトまたはインターセプトできます。メールドメイン用のDNSSEC採用は増加していますが、まだ普遍的ではありません。

メール送信用のSRVレコード

RFC 6186はメールクライアントが送信とIMAP/POPサーバーを自動検出するために使用できるSRVレコードを定義しています：

これらはメールクライアント自動構成に使用されます — ユーザーがメールアドレスを入力すると、クライアントはSRVレコードをクエリして正しいサーバー、ポート、プロトコルを見つけます。これはMXベースのサーバー間ルーティングとは別です。

問題が生じる可能性があるもの

MXレコードがない

MXレコードなしでは、送信者はAレコードにフォールバックします。ウェブサーバーがポート25でSMTPサーバーを実行していない場合、タイムアウト後にメール配信は失敗します。常に明示的なMXレコード、またはメールを受け付けない場合はNull MXを公開してください。

MXがCNAMEを指す

上述のように、これは技術的に無効です。一部の送信者はCNAMEをフォローします。他の送信者は失敗します。すべてのMXターゲットホスト名にはA/AAAAレコードを使用してください。

循環MX参照

example.comにmail.example.comを指すMXがあり、mail.example.comにexample.comに戻るMXがある場合、メールはループできます。MXターゲットはA/AAAAレコードのみを持つリーフホスト名である必要があります。

PTRレコードがない

送信IPに逆引きDNSがない、またはジェネリックISPホスト名に解決します。主要なメールボックスプロバイダー（Gmail、Microsoft、Yahoo）はメールを延期または拒否します。送信IPにPTRレコードがあり、同じIPに正引きされることを確認してください。

配信中のDNSタイムアウト

受信側ドメインのDNSサーバーが遅い、または到達不可の場合、送信サーバーはMXレコードを解決できません。メッセージは再試行のためにキューされます。永続的なDNS障害は最終的にバウンス（通常4～5日後）になります。送信者としてできることはありません — これは受信側のインフラストラクチャの問題です。

SPFレコードがDNS UDPリミットを超える

UDP経由のDNS応答は512バイト（またはEDNS0で4096）に制限されています。多くのinclude:ディレクティブを持つ非常に長いSPFレコードは切り詰められる可能性があります。リゾルバーはTCPにフォールバックし、遅延を追加し、DNSサーバーがTCPをサポートしていない場合は失敗する可能性があります。SPFレコードを簡潔に保ってください。

メール用のDNSのデバッグ

メールルーティングの問題を診断するための必須コマンド：

主な要点

• MXレコードはメールルーティングの主要なメカニズムです。低い優先度番号が最初に試されます。
• MXレコードが存在しない場合、送信者はA/AAAAレコードにフォールバックします。曖昧さを避けるために、明示的なMXレコード（またはNull MX）を公開してください。
• MXターゲットはA/AAAAレコード付きのホスト名である必要があります — IPではなく、CNAMEではなく。
• PTRレコード（逆引きDNS）はルーティングの一部ではありませんが、配信性に必須です。すべての送信IPには正引きAレコードに一致するPTRが必要です。
• 完全な送信ドメインには、最低限、MX（またはNull MX）、SPF、DKIM、およびDMARCレコードが必要です。
• 変更前後にdigを使用してすべてのDNSレコードを確認してください。

参考資料

Related RFCs