DNSの設定ミスが招く「Hop count exceeded」：メールループを未然に防ぐには

本日もメール配信システム「ワイメール」に関するコラムをご覧いただきありがとうございます。

メールの運用を行っていると、「送ったはずのメールがいつまでも届かない」「バウンスが大量に返ってきた」といった問題に直面することがあります。

その原因がよく調べてみると、メールが複数のサーバー間をぐるぐると転送し続け、最終的に「Hop count exceeded」や「Hop count limit」というエラーで送信に失敗していた、というケースがあります。

このエラーは、設定の不備によって引き起こされることがあります。特に、DNSの設定を誤るとメールが意図しないループに陥りやすくなります。

今回のコラムでは、このエラーの仕組みと、DNS設定の誤りによってなぜ発生するのか、そして企業でもよく利用されている、Google WorkspaceやMicrosoft 365での確認方法について整理したいと思います。

Hop countとは何か

メールは送信元から受信先に届くまで、複数のサーバーを経由することがあります。この経由する回数のことを「ホップ数（Hop count）」と呼びます。

通常のメール配信では、数ホップ以内に目的のサーバーに届きます。しかしメールが誤った転送ルートに迷い込み、サーバー間をループしてしまうと、ホップ数が際限なく増えていきます。

RFC 5321では、メールサーバーはメッセージのホップ数が規定の上限（多くの実装では25回前後）を超えた場合、そのメールを破棄することが定められています。

このときメール送信者に返されるエラーが「Hop count exceeded」や「Hop count limit」です。

エラーメッセージとしては次のような形で現れることがあります。

このエラーが出たときは、メールが正常に届いていないことはもちろん、メールがループする間に、サーバーのリソースが消費され続けているという問題もあります。

なぜDNSの設定ミスがループを引き起こすのか

「Hop count exceeded」の原因として代表的なものの一つが、MXレコードの誤設定です。

MXレコードとは、「このドメイン宛てのメールをどのサーバーで受信するか」を示すDNSの設定項目です。ここに誤りがあると、メールが意図しないサーバーに転送され、そのサーバーがさらに別のサーバーに転送する、という連鎖が起きます。

特に起きやすいのが、次のようなケースです。

MXレコードが自分自身や別の中継サーバーを指している場合

たとえば、本来は外部のメールサービス（Google WorkspaceやMicrosoft 365）に向けるべきMXレコードが、誰かの操作ミスで自社の旧サーバーや中継サーバーを指したままになっているケースです。

このとき、外部サービスに届いたメールが「このドメインは自分が受け取るべきではない」と判断して転送を試み、転送先がまた別のサーバーに回す、という流れでループが生じます。

転送設定が循環している場合

メールボックスの転送設定において、AがBに転送し、BがAに転送する、という相互転送の設定が残っていると、同様のループが発生します。

これはDNSではなくメールサービス側の設定ですが、MXレコードの向き先と組み合わさると、より複雑なループになります。

複数のサービス間でMXレコードが重複している場合

Google WorkspaceとMicrosoft 365を並行して試験運用している場合など、MXレコードに両方のサービスのサーバーが混在していると、送信先の判断が分散して、予期しない転送が生じることがあります。

いずれのケースも、「DNSの設定を変えたとき」や「メールサービスを移行したとき」に起きやすい問題です。設定変更後はメールの動作確認を丁寧に行うことが重要です。

Google Workspaceで確認する方法

Google Workspaceを利用している場合、まずはMXレコードの設定状況を管理コンソールから確認できます。

管理コンソールでの確認手順

Google Workspaceの管理コンソールにログインします。

「アプリ」→「Google Workspace」→「Gmail」→「ドメインの確認」の順に進むと、現在のMXレコードの設定状況とGoogleが推奨する設定値を比較できます。

ここで「設定が確認されていません」と表示されている場合は、MXレコードが正しく向いていない可能性があります。

Googleが推奨するMXレコードの値は次の通りです。

以前のMXレコードの推奨値

2023年より前に Google Workspace の使用を開始した場合、MX レコード値が「aspmx」で始まる値になっていることがあります。

メールが正常に機能している場合は、変更する必要はありません。以前の MX レコード値も引き続きサポートされます。

優先度	メールサーバー
1	aspmx.l.google.com
5	alt1.aspmx.l.google.com
5	alt2.aspmx.l.google.com
10	alt3.aspmx.l.google.com
10	alt4.aspmx.l.google.com

これら以外のサーバーが優先度1に設定されている場合は、メールが意図しないサーバーに転送されている可能性があります。

転送設定の確認

個々のメールボックスに転送設定が残っていないかどうかは、管理コンソールの「ユーザー」から対象アカウントを開き、「メール設定」で確認できます。不要な転送先が設定されていた場合は削除します。

Microsoft 365で確認する方法

Microsoft 365を利用している場合は、Microsoft 365管理センターとDNSの両面から確認します。

Microsoft 365管理センターでの確認手順

Microsoft 365の管理センターにログインし、「設定」→「ドメイン」から対象ドメインを選択すると、必要なDNSレコードの一覧と現在の設定状況が確認できます。

MXレコードが「必要な値と一致していません」と表示されている場合は、修正が必要です。

Microsoftが推奨するMXレコードの値は、テナントごとに異なりますが、一般的には次のような形式になります。

この値がMXレコードに設定されているかを確認します。古いサービスのMXレコードが残っている場合は削除が必要です。

コネクタとトランスポートルールの確認

Microsoft 365では「コネクタ」や「トランスポートルール（メールフロールール）」の設定によって、メールの転送先を細かく制御できます。

管理センターの「Exchange管理センター」→「メールフロー」→「コネクタ」「ルール」から確認し、意図しない転送ループを生じさせる設定がないかを確認します。

特に「すべてのメールを別のサーバーに転送する」というコネクタ設定は、MXレコードの向き先と組み合わさると容易にループが発生するため注意が必要です。

設定変更後に確認したいこと

DNSの設定は、DNSキャッシュの影響により、変更してもすぐに反映されないことがあります。TTL（Time To Live）の値によっては、変更が世界中に伝播するまでに数時間かかる場合もあります。

設定変更後の動作確認には、MXチェックツール（MXToolbox など）を利用すると、現在のMXレコードの向き先をリアルタイムで確認できます。

また、テスト用のアドレスに実際にメールを送信し、メールヘッダーの「Received」行でホップ数と経路を確認することも有効です。

最後に

「Hop count exceeded」は、一見すると難解なエラーに見えます。しかし多くの場合、その背後にあるのはMXレコードの誤設定や転送設定の矛盾といった、確認すれば発見できる問題です。

メールサービスの移行時や、DNS設定を変更したとき、あるいはメールがなぜか届かないという問題が発生したときは、まずMXレコードの向き先が正しいかを疑ってみてください。

Google WorkspaceもMicrosoft 365も、管理コンソールからMXレコードの期待値と現在の設定を比較できる機能を持っています。設定に疑問を感じたら、まずコンソールを開いて確認する習慣をつけることが、トラブルを未然に防ぐ第一歩になります。

免責事項

当コラムの内容は、コラム執筆時点での内容です。今後のバージョンアップ等により、当サービスや紹介したサービスの仕様やインターフェイスが変更になる場合がございます