DNSのMXレコードとは?
著者: Ahona Rudra
翻訳: 東條 百々朱
この記事はPowerDMARCのブログ記事 DNS MX Records Explained: How to Configure, Check, and Troubleshoot Them の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
主なポイント
- DNS MXレコードは、ドメイン宛てのメールの配送先となるメールサーバを指定します。
MXレコードが存在しない場合、メール配信は失敗するか、Aレコードで指定されたIPアドレスへ配送されますが、この方法は推奨されていません。 - MXレコードは優先度(Priority)によって、どのメールサーバへ最初に接続するかを決定します。
優先度の値が小さいほど、そのメールサーバが優先的に利用されます。 - 複数のMXレコードを設定することで、冗長化や負荷分散を実現できます。
- MXレコードはCNAMEレコードではなく、AレコードまたはAAAAレコードを持つホスト名を指定する必要があります。
設定ミスは、メール配信エラーやセキュリティリスクにつながる可能性があります。 - MXレコードを定期的に確認することで、メール環境を安定して運用できます。
SPF、DKIM、DMARCなどの認証技術とあわせて、MXレコードもメールセキュリティの重要な要素です。
送受信されるすべてのメールは、DNSレコードによって支えられています。
なかでもDNS MXレコードは、メール配送を支える重要な仕組みです。
インターネット上で、どのメールサーバが自社ドメイン宛てのメールを受信するのかを指定する役割を担っています。
MXレコードが正しく設定されていれば、メールは問題なく配信されます。
しかし設定を誤ると、メールがエラーで返送されたり、受信できなかったりする可能性があります。
MXレコードはメールインフラの中でも特に重要な設定項目ですが、設定ミスや古い設定の放置によるトラブルも少なくありません。
本記事では、DNS MXレコードの仕組みや役割、設定方法、問題発生時の対処方法、そして信頼性の高いメール運用とドメイン保護のためにMXレコード管理が重要な理由を解説します。
DNSのMXレコードとは?
DNS MXレコード(Mail Exchanger Record)は、ドメイン宛てのメールの配送先となるメールサーバを指定するDNSレコードです。
誰かがあなたのドメイン宛てにメールを送信すると、MXレコードは送信元メールサーバに対して、そのメールをどのサーバへ配送すべきかを伝えます。
MXレコードが設定されていない場合、送信元メールサーバは適切な配送先を判断できません。
その結果、メール配信に失敗したり、迷惑メールとして扱われたりする可能性があります。
MXレコードの構造
各MXレコードには、DNSサーバがメール配送処理を行うために必要な重要な情報が含まれています。
- Type
- レコード種別を示します。
MXレコードの場合は「MX」が設定されます。 - Host Name
- レコードを適用するドメイン名を指定します。
例:example.com - Mail Server
- (「Points To」や「Value」と表記される場合もあります)
そのドメイン宛てのメールを受信するメールサーバを指定します。 - Priority
- どのメールサーバを優先して利用するかを示す値です。
- TTL(Time To Live)
- DNSサーバがレコード情報をキャッシュする時間(秒)を指定します。
この時間が経過すると、新たなDNS問い合わせが行われます。
例えば、基本的なMXレコードは以下のようになります。
| タイプ | ホスト | メールサーバ | 優先度 | TTL |
|---|---|---|---|---|
| MX | example.com | mail.example.com | 10 | 3600 |
このレコードは、example.com宛てのメールを送信するサーバに対して、メールの配送先はmail.example.com、優先度は10、キャッシュ時間は1時間であることを示しています。
MXレコードの仕組み
MXレコードがどのようにメールの配送先を決定するのかを理解することで、メール配信の問題を特定・解決しやすくなり、メール環境の最適化にも役立ちます。
基本的な流れは以下の通りです。
- メール送信
- ユーザがuser@example.com宛てにメールを送信します。
送信元メールサーバは、そのメールをどのサーバへ配送すべきかを確認する必要があります。 - DNS問い合わせ
- 送信元メールサーバは、example.comのMXレコードをDNSへ問い合わせます。
- 優先順位の確認
- DNSサーバは、そのドメインに設定されているMXレコードと優先度情報を返します。
送信元サーバは、もっとも数値が小さいMXレコードを優先して選択します。 - 接続
- 送信元メールサーバは、MXレコードで指定されたプライマリメールサーバへ接続し、メールを配送します。
- フェイルオーバ
- プライマリサーバへ接続できない場合は、次に優先度の高いMXレコードが自動的に利用され、メール受信の継続性が確保されます。
この自動フェイルオーバ機能は、メール停止が業務へ大きな影響を与える企業や組織にとって非常に重要です。
複数のMXレコードを設定しておくことで、サーバ障害が発生した場合でもメールサービスの継続性を維持できます。
MXレコードとその他のDNSレコードの違い
MXレコードは、メールサービスを正しく機能させるために、他のDNSレコードと連携して動作します。
ただし、各DNSレコードにはそれぞれ異なる役割があります。
以下の表では、各レコードの役割と、MXレコードとの関係を整理します。
| レコードタイプ | 目的 | 例 | MXレコードとの関係 |
|---|---|---|---|
| MX | ドメイン宛てメールの配送先となるメールサーバを指定する | example.com→mail.example.com(優先度10) | メール配送の中核となるレコードです。 MXレコードが正しく設定されていないと、メール配信に失敗する可能性があります。 |
| A | ホスト名をIPv4アドレスへ紐づける | mail.example.com→192.0.2.1 | MXレコードで指定されたメールサーバは、Aレコードを通じてIPv4アドレスを取得できる必要があります。 これにより、送信元サーバは接続先のIPアドレスを特定できます。 |
| AAAA | ホスト名をIPv6アドレスへ紐づける | mail.example.com→2001:db8::1 | Aレコードと同様に、IPv6環境でメールサーバのIPアドレスを特定するために使用されます。 MXレコードで指定されたホスト名は、AレコードまたはAAAAレコードで解決できる必要があります。 |
| CNAME | あるホスト名を別のホスト名の別名として設定する | webmail.example.com→mail.example.com | MXレコードでは、CNAMEを指定しないことが推奨されます。 一部のメールサーバでは追加の名前解決を正しく処理できず、メール配信に失敗する可能性があります。 |
| TXT | SPF、DKIM、DMARCポリシーなどのテキスト情報を格納する | v=spf1 include:_spf.google.com ~all | TXTレコードは、MXレコードとあわせてメール認証に利用されます。 SPF、DKIM、DMARCの設定とMXレコードに不整合があると、スパム判定や認証失敗の原因になる可能性があります。 |
| PTR | IPアドレスからホスト名を逆引きする | 192.0.2.1→mail.example.com | 受信側メールサーバは、送信元メールサーバのIPアドレスにPTRレコードが設定されているか確認する場合があります。 PTRレコードのホスト名とMXレコードの設定に不整合があると、メール配信に影響する可能性があります。 |
DNS MXレコードの設定方法
MXレコードを正しく設定することは、安定したメール配信を実現するために欠かせません。
設定手順自体は比較的シンプルですが、小さな設定ミスでもメール配信エラーの原因になる可能性があります。
以下では、ドメインのMXレコードを設定する基本的な方法を解説します。
ステップ1:メールプロバイダからメールサーバ情報を取得する
DNS設定を変更する前に、利用しているメールプロバイダからMXレコード情報を確認する必要があります。
各メールプロバイダは、指定すべきメールサーバ名と優先度(Priority)を提供しています。
これらの値は、案内された内容をそのまま正確に設定してください。
Microsoft 365のMXレコード例
| 優先度 | メールサーバ |
|---|---|
| 0 | yourdomain-com.mail.protection.outlook.com |
Google Workspaceの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 |
必要な設定値は、利用中のメールプロバイダの公式ドキュメントで確認できます。
提供された値は変更せず、そのまま使用してください。
ステップ2:DNS設定画面へアクセスする
ドメインを管理しているサービスへログインします。
利用環境によっては、ドメインレジストラの管理画面である場合もあれば、DNSプロバイダの管理画面である場合もあります。
ログイン後、DNS設定画面へ移動し、DNSレコードの追加や編集ができるページを開きます。
ステップ3:MXレコードを作成または更新する
MXレコードを作成する際は、レコードタイプをMXに設定し、メールサーバ名、優先度、TTLを入力します。
各MXレコードについて、以下の情報を設定してください。
- レコードタイプはMX
- ホスト名(通常は「@」またはドメイン名)
- メールプロバイダが指定するメールサーバ名
- 指定された優先度
- TTL(一般的には3600秒=1時間)
以前利用していたメールサービスのMXレコードが残っている場合は、新しいMXレコードを追加する前に削除してください。
古いメールプロバイダと新しいメールプロバイダのMXレコードが混在していると、メールの配送先が不安定になり、配信トラブルの原因になる可能性があります。
ステップ4:DNS設定の反映を待つ
MXレコードの変更は、DNSサーバ全体へ反映されるまで最大48時間かかる場合があります。
ただし、多くの場合は数時間以内に反映されます。
反映期間中は、一部のメールが古いメールサーバへ送信され、別のメールは新しいメールサーバへ送信されることがあります。
トラブルを避けるため、この期間中は追加のDNS変更をできるだけ行わないようにしましょう。
ステップ5:設定を確認する
DNS設定の反映後は、MX Lookup(MXレコード確認)を実行し、MXレコードが正しく設定され、意図したメールサーバを参照していることを確認します。
PowerDMARCの無料DNSレコードチェッカーを利用すると、MXレコードが正しいメールサーバを指しているか、優先度が適切に設定されているかを簡単に確認できます。
また、外部のメールアドレスからテストメールを送信し、メールが正しいメールサーバで受信されていることも確認してください。
MXレコードの確認方法とトラブルシューティング
MXレコードは、一度設定したら終わりではありません。
メールプロバイダの変更やサーバ構成の更新によって、設定の見直しが必要になることがあります。
また、小さな設定ミスが原因でメール配信障害が発生するケースも少なくありません。
定期的な確認とメンテナンスを行いましょう。
MX Lookupの実行方法
- オンラインMX Lookupツール
- PowerDMARCの無料DNSレコードチェッカーなどを利用すると、現在のMXレコードや優先度、設定状況を簡単に確認できます。
- コマンドラインツール
- nslookupやdigを使用してMXレコードを直接確認することも可能です。
例)nslookup -type=mx example.comまたはdig mx example.com
実行すると、現在設定されているMXレコードが表示されます。 - DNS管理画面
- DNS管理画面からも、公開されているすべてのDNSレコード(MXレコードを含む)を確認できます。
定期的にMXレコードを確認することで、大規模なメール障害につながる前に問題を発見できます。
よくあるMXレコードの問題と対処方法
- MXレコードがCNAMEを参照している
- MXレコードは、AレコードまたはAAAAレコードを持つホスト名を指定する必要があります。
CNAMEを指定している場合、一部のメールサーバではメール配信に失敗する可能性があります。
この場合は、CNAMEではなく実際のメールサーバ名へ変更してください。 - MXレコードが設定されていない
- MXレコードが設定されていない場合、メール配信に失敗したり、迷惑メールとして扱われたりする可能性があります。
MXレコードが正しく設定されていることを確認してください。
誤って削除してしまった場合は、メールプロバイダが案内している値を使って再設定しましょう。 - 重複または競合するMXレコード
- 複数のメールサービスのMXレコードが混在していると、メールの配送先が不安定になり、配信トラブルの原因になります。
利用していないメールサービスのMXレコードは削除してください。 - 優先度の設定ミス
- バックアップメールサーバの優先度がプライマリサーバよりも高く設定されていると、メールが意図しないサーバへ配送される可能性があります。
プライマリサーバには最も小さい数値を設定し、バックアップサーバはその後に続く順番で設定してください。 - TTLが高すぎる
- TTLが高すぎると、古いDNS情報が長期間キャッシュされます。
MXレコード変更前にはTTLを一時的に下げておき、変更後に元へ戻すことで、設定変更をよりスムーズに反映できます。
MXレコード管理のベストプラクティス
- 複数のMXレコードで冗長化する
- メールサービスの安定運用には、複数のMXレコードを設定することが重要です。
プライマリサーバが利用できなくなった場合でも、バックアップサーバへ自動的に切り替えられます。
少なくとも1つのバックアップMXレコードを設定しておくことをおすすめします。 - 分かりやすい優先度を設定する
- 優先度は将来的な拡張も考慮して設定しましょう。
たとえば「1・2・3」ではなく「10・20・30」のように設定しておくと、後から新しいサーバを追加しやすくなります。 - MXレコードを定期的に見直す
- 以下のようなタイミングではMXレコードを確認しましょう。
- メールプロバイダを変更したとき
- 外部メールサービスを追加または削除したとき
- DNSプロバイダを変更したとき
- メール環境のセキュリティ監査を実施したとき
- 認証レコードとの整合性を保つ
- MXレコードで指定したメールサーバが、SPF、DKIM、DMARCの設定とも一致していることを確認してください。
設定の不一致は、スパム判定やメール到達率低下の原因になる可能性があります。
PowerDMARCでは、DNSレコードと認証レコードを一元管理できるため、問題が発生する前に設定ミスを発見できます。
PowerDMARCで安全で信頼性の高いメール配信環境を実現
MXレコードはメール配信の基盤ですが、それだけで十分ではありません。
設定ミスや古いレコード、認証設定との不一致は、気付かないうちにメール配信障害やセキュリティリスク、ドメインの信頼性低下を招く可能性があります。
PowerDMARCは、自動監視、コンプライアンス対応レポート、専門サポートを通じて、安全で信頼性の高いメール環境の維持を支援します。
よくある質問(FAQ)
- MXレコードが設定されていない場合はどうなりますか?
- メール配信に失敗するか、Aレコードで指定されたIPアドレスへ配送されますが、この方法は推奨されません。
- MXレコードは送信メールにも影響しますか?
- いいえ。
MXレコードは受信メールの配送先を指定するためのものです。
送信メールはSMTPサーバによって処理されます。 - MXレコードは何のためにありますか?
- ドメイン宛てメールの配送先となるメールサーバを指定するために利用されます。
- MXレコードには何を設定すればよいですか?
- 利用しているメールプロバイダが指定するメールサーバ名を設定します。
Google Workspaceなら「ASPMX.L.GOOGLE.COM」、Microsoft 365ならMicrosoftが指定するMXレコードを使用します。 - よくあるMXレコードの設定ミスは何ですか?
-
- CNAMEを指定している
- 優先度の設定ミス
- FQDN末尾のドット漏れ
- 古いMXレコードの放置
- PowerDMARCはMXレコード管理をどのように支援しますか?
- PowerDMARCは、自動監視、リアルタイムアラート、コンプライアンス対応レポート、専門サポートを提供し、安全で安定したメール環境の維持を支援します。