バックアップMX・セカンダリMXは本当に必要か
目次
この記事でわかること
- バックアップ MX(セカンダリ MX)が何のための仕組みなのか
- Google Workspace / Microsoft 365 を使う多くの会社で「不要」とされる理由
- 放置したセカンダリ MX がスパムの踏み台や迂回路になるリスク
- 自社にとって「本当に必要か」を見極める判断軸
「念のため予備の MX を足しておこう」は正解か
サーバー会社や昔の手引きで「メールが止まらないようにバックアップ MX(予備のメール受け口)を設定しましょう」と案内され、よく分からないまま 2 つ目・3 つ目の MX を登録している会社は少なくありません。
しかし、いまの中小企業のメール環境では 「予備の MX を足すと、むしろトラブルの種になる」 ケースが増えています。理由を理解しないまま設定したセカンダリ MX が、何年も放置されてスパムの踏み台にされていた、という事故も実際にあります。
この記事では、バックアップ MX の本来の目的を整理したうえで、「自社には要るのか・要らないのか」を判断できるようにします。MX レコードそのものの基本はMXレコードとは｜設定方法と優先度で解説しているので、あわせて読むと理解が深まります。
バックアップMXとは何か ─ 優先度のおさらい
MX レコードには 優先度(preference・プリファレンス) という数字がついています。ルールはシンプルで、数字が小さいほど優先 されます(第 1 希望 = 10、第 2 希望 = 20、というイメージです)。
example.co.jp. IN MX 10 mx1.example-mail.com.
example.co.jp. IN MX 20 mx2.example-mail.com.
メールを送る側のサーバーは、次のように動きます。
- 優先度の数字が一番小さい MX(上の例なら
10)へまず配送を試みる - つながらなければ、次に小さい数字の MX(
20)へ - すべて失敗したら、その場で諦めず、時間を置いて再送を繰り返す
この 2 番目以降の、優先度の数字が大きい MX が、いわゆる「バックアップ MX」「セカンダリ MX」です。本体(プライマリ)が落ちているあいだ、メールを一時的に受け取ってキュー(処理待ちの列)に溜めておき、本体が復旧したら転送する ── これが本来の役割です。
この仕組みは、SMTP(メール送受信の通信規約)の標準である RFC 5321 に基づいています。RFC 5321 では、複数の MX があるとき送信側は優先度の小さいものから順に試すこと、そして配送に一度失敗しても すぐにメールを破棄せず、一定間隔で再送を続ける ことが定められています。再送の間隔はおおむね最低 30 分以上、配送を諦めるまでの時間は最低でも 4〜5 日とされており、送信側で粘り強くリトライする前提になっています。
クラウドメールではバックアップMXが「不要」とされる理由
ここが本題です。Google Workspace や Microsoft 365 のような クラウド型のメールサービス を使っている場合、自前でバックアップ MX を用意する必要は基本的にありません。理由は 2 つあります。
1. 事業者側がすでに冗長化している
クラウドメールの提供元は、世界中のデータセンターに分散した冗長構成でメールを受け付けています。Microsoft は公式ドキュメントで、Microsoft 365 の MX レコードは 優先度 0 で 1 件だけにすること を案内しており、サービス内部に地理的な冗長性が組み込まれているため追加のバックアップ MX は不要だとしています。Google Workspace も同様に、不要な MX は削除して 1 件に集約することを推奨しています。
2. 万一届かなくても送信側が再送してくれる
前述のとおり、RFC 5321 によって送信側は配送に失敗してもメールを最低 4〜5 日は保持し、再送を繰り返します。つまり、受信側で一瞬の不具合があっても、メールがその場で消える設計にはなっていません。クラウド事業者の冗長化と、送信側の再送の二重の仕組みがあるため、自前のバックアップ MX が埋める「すき間」がほとんど残っていない のです。
実際、Microsoft 365 では「ホストしていないサーバーを指す余計な MX を残すと、そこへ届いたメールが配送不能(NDR)になる」など、バックアップ MX がかえって配送事故を招く ことが知られています。良かれと思って足した予備が、逆効果になりかねないわけです。
放置したセカンダリMXが招くリスク
「不要なら消せばいいだけ」と思うかもしれませんが、問題は 設定したことを忘れて放置されたセカンダリ MX です。これは単に無駄なだけでなく、実害につながります。
スパムの踏み台・迂回路にされる
迷惑メール送信者は、メインのメールサーバーよりも 管理が手薄な予備サーバーを狙います。優先度の大きいセカンダリ MX が、本体と同じ迷惑メール対策(フィルタや認証チェック)を備えていないと、そこを 迂回路 にしてスパムやなりすましメールを送り込まれることがあります。送信者から見れば「守りの薄い裏口」というわけです。
フィルタ不整合で配送が遅れる・失われる
セカンダリ MX が本体と違う設定になっていると、本体なら正しく受け取れるメールがセカンダリ側で弾かれたり、逆に本来止めるべきメールが通ってしまったりします。本体経由とセカンダリ経由でメールの扱いが食い違うと、配送遅延や取りこぼし の原因になります。
放置されたバックアップ MX は、SPF / DKIM / DMARC といったメール認証の設定が古いまま取り残されていることも多く、なりすまし対策の穴になりがちです。MX を含む DNS レコード全体の役割はDNSレコードの種類とはで整理しているので、あわせて点検しておくと安心です。
自社に「本当に必要か」を見極める判断軸
中小企業の視点で、シンプルな判断軸に整理します。
バックアップ MX が不要なケース(大多数)
- Google Workspace、Microsoft 365 などの クラウドメールを使っている
- 事業者の MX を案内どおり 1 件設定している
- → 追加のバックアップ MX は不要。むしろ余計な MX は削除する
中小企業や制作会社の多くはこちらに当てはまります。「予備があったほうが安心」という直感とは逆で、MX は必要最小限に保つほうが事故が起きにくい と考えてください。
検討の余地があるケース
- 自社内やデータセンターで メールサーバーを自前運用 している
- そのサーバーが単一拠点で、長時間の障害が業務に直結する
このような構成なら、バックアップ MX に一定の意味があります。ただし導入する場合は、本体と同じ迷惑メール対策・メール認証を備えた予備 を、自分たちで維持し続けられることが前提です。守れない予備なら、置かないほうが安全です。
よくある質問
バックアップ MX を設定すれば、メールが絶対に止まらなくなりますか
いいえ。クラウドメールでは事業者側がすでに冗長化しており、送信側も RFC 5321 に基づいて数日間は再送を続けます。自前のバックアップ MX を足しても、得られる安心は限定的で、放置による事故リスクのほうが上回ることが多いです。
いま設定されているセカンダリ MX が必要かどうか分かりません
まず「自社がクラウドメールか自前サーバーか」を確認してください。クラウドメール利用なら、事業者が案内する MX 以外は基本的に不要です。判断に迷う場合は、現在の MX 設定を一度棚卸ししたうえで削除を検討するのが安全です。
MX を 1 件に減らすとメールが届かなくなりませんか
クラウドメールでは MX 1 件が公式の推奨構成です。事業者が指定した正しい MX が 1 件あれば、受信は問題なく機能します。削除するのは事業者の指定にない余計な MX だけにし、変更前後で受信テストを行うと安心です。
まとめ
- バックアップ MX(セカンダリ MX)は、本体障害時にメールを一時的に受け止める仕組み
- Google Workspace / Microsoft 365 などクラウドメールでは、事業者の冗長化と送信側の再送(RFC 5321)があるため基本的に不要
- 放置したセカンダリ MX はスパムの踏み台・迂回路や配送遅延の原因になり得る
- 中小企業の大多数は「MX は必要最小限に」が安全。検討すべきは自前サーバーを単一拠点で運用しているケースに限られる
まずは自社のMX状態を確認しましょう
「いま自社にどんな MX が設定されているか分からない」「使っていない予備の MX が残っていないか不安」という場合は、まず無料のドメイン診断で MX を含む主要レコードの状態を一括で確認できます。設定の見直しや削除を任せたい場合も、専門家がわかりやすくサポートしますので、お気軽にご相談ください。