MXレコードの確認方法とメール配送のテスト

MX検索では、ドメインが受信メール用にどのメール交換サーバーを公開しているかを確認します。実行するには、ドメインのMXレコードを問い合わせ、返されたホスト名と優先度の値をそれぞれ確認します。そのうえで、指されたホスト名がアドレスに解決されること、そしてメールプロバイダーの現在の設定と一致することを確かめます。これは、移行後にレコードが欠けていたり、プロバイダーのターゲットが古いままだったりするのを素早く見つける方法です。ただし、MXの答えが見えても、受信側のシステムがオンラインであること、特定のメールボックスを受け付けること、メッセージが受信トレイに届くことまでは保証されません。DNSはメール配送の重要な層の1つであって、配送システム全体ではありません。

優先度の値を正しく読む

各MXレコードには、数値の優先度とメール交換サーバーのホスト名が含まれます。値が小さいほうが、大きいほうより優先されます。つまり、最も大きい数字が勝つ優先順位のランキングではありません。複数の交換サーバーが、バックアップを提供したり、責任を分散したりできます。メール転送エージェントにはリトライの挙動があり、優先されるホストが利用できないときは、別の交換サーバーを試し続けることができます。プロバイダーの設計を確認せずに、重要でなさそうに見えるという理由だけで、番号の大きいレコードを削除してはいけません。単一の交換サーバーだけを公開するサービスもあれば、慎重に順序付けされた、地域別やバックアップ用のシステム群に頼るサービスもあります。

どのドメインを問い合わせるのかを、正確に特定してください。企業がアドレスには example.com を使い、サブドメインが別のメールストリームを扱うこともあれば、製品が委任された送信用サブドメインを使うこともあります。受信者が @example.com を使っているのに mail.example.com を問い合わせると、メールボックスの経路とは無関係な答えが返ることがあります。MXレコードが公開されていない場合、メールシステムはドメインのアドレスレコードを使うフォールバックの動作をとることがありますが、それは意図したプロバイダー設定を確認することの代わりにはなりません。メールホストのドキュメントに従い、受信者のアドレスに関連付けられた、正確なドメインを使ってください。

MX検索でよくある問題

MXレコードがない場合は、メール配送が一度も設定されていない、間違ったホスト名を問い合わせた、DNSの移行でレコードが漏れた、といった可能性があります。名前解決できないターゲットは、MXレコード自体が文法的に存在していても、配送を妨げることがあります。古いプロバイダーのMX値が、キャッシュされた応答が失効するまで、再帰的な検索に表示され続けることがあります。ターゲットのホスト名のタイプミスや、誤った優先度によって、メールが間違ったサービスに送られることもあります。権威ゾーンとプロバイダーの管理画面を併せて確認し、そのうえで、キャッシュされたパネルのプレビューを見ているだけではないリゾルバーを通して、公開されている答えを比較してください。

• 受信者のドメインそのものについて、MXを確認する。
• すべての優先度とターゲットを、プロバイダーの指示と照合する。
• 各交換サーバーのホスト名を名前解決し、値が最新であることを確認する。
• 再帰的な答えが古く見える場合は、権威の答えを調べる。
• 送信認証については、SPF、DKIM、DMARCを別途確認する。

変更後に配送経路を検証する

MXを変更する前に、現在の設定を記録し、どのメールボックスと送信者がそれに依存しているかを把握してください。置き換える値は、DNSホストが必要とする場合は末尾のドットの慣例も含めて、指示されたとおりに公開し、権威ゾーンが変更を受け付けることを確認します。公開後は、MXクエリを実行し、すべてのターゲットを名前解決します。外部のプロバイダーから、メールを受信すべきアドレスに管理されたテストメールを送り、配送に失敗する場合は、メールログやプロバイダーの診断を確認します。TTLとリトライの挙動も考慮してください。変更が、遠隔の送信システムで一貫して使われるようになるには、時間がかかることがあります。

メール全体の像については、メール用DNSレコードとMXレコードの役割をお読みください。DNSチェッカーは、公開されているMXの答えを調べるのに役立ちますが、特定のメールボックスについて、エンドツーエンドの経路を検証できるのは、実際のメッセージテストだけです。これらの確認は別々に行い、結果を記録してください。そうすれば、失敗の原因が、DNSレコード、交換サーバー、受信者のポリシー、送信者の認証設定のどれにあるのかを見分けやすくなります。

MXだけで配送を診断しない

MXクエリが確認するのは、公開されている経路の指示です。しかし配送には、その後にいくつかの段階があります。送信サーバーが交換サーバーのホスト名を名前解決し、接続を開き、設定されている場合はトランスポートセキュリティをネゴシエートし、受信側がメールボックス、評価、ポリシーのルールを適用します。有効なMXの集合が、一時的に利用できないサービスを指していることもあれば、SMTP接続が成功しても、受信者が拒否されたり、メッセージが迷惑メールに分類されたりすることもあります。DNSが正しく見える場合は、送信プロバイダーの配送ステータス、受信側の拒否メッセージ、サーバーのログを集めてください。これらの詳細から、次の問題が、アドレス解決、ネットワークの到達性、SMTPポリシー、メールボックスの存在、スパムフィルタリングのどれなのかが分かります。