MXレコードとは — MXを設定したのにメールが届かない場合のチェック手順と、MXが無いドメインへ送ったメールがどうなるか
TL;DR
MXレコード（Mail eXchanger record）は、ドメイン宛てのメールをどのメールサーバーで受け取るかを指定するDNSレコードです。MXが無いドメインへ送ったメールは即座にエラーにならず、SMTPの仕様（RFC 5321 §5.1）に従ってAレコードのIPアドレスへ配送が試みられ、数日後にバウンス（配信不能通知）が返ります。「送ったのにエラーも来ない、でも届いていない」という状態は、この挙動によるものです。
設定画面にMXが入っていることと、メールが実際に届くことは、別の話です。
MXの向き先のホスト名にAレコードが無い。SPF/DKIM/DMARCが揃っていない。サービスが指定したホスト名と一字違う。どれも、nslookupではMXが正しく引けるのにメールは届かない、という状態を作ります。この記事では、その切り分けを確認すべき順番どおりに書きます。
逆向きのケースも扱います。「取引先にメールを送ったが届かない。先方のDNSを調べたらMXが無かった」という状況です。MXが無いドメインへ送ったメールは、その場でエラーにはなりません。数日たってから初めてバウンスが届きます。なぜそうなるのかを、先方への説明にそのまま使える形でまとめます。
MXレコードとは何ですか？
MXレコード（Mail eXchanger）は、ドメイン宛てのメールを受け取るメールサーバーのホスト名を指定するDNSレコードです。メールを送る側のサーバーはMXレコードを参照して、どのサーバーに接続するかを決めます。
メールを送る仕組みを整理すると、次のようになります。誰かが あなた@example.com 宛てにメールを送るとき、送信側のMTA（Mail Transfer Agent：メールを転送するプログラム）は最初に example.com のMXレコードを問い合わせます。そこに書かれているホスト名（例：mail.example.com）に接続して、メールを渡します。
MXレコードの書式は次のとおりです。
example.com. IN MX 10 mail.example.com.左から「ドメイン名」「レコード種別（MX）」「優先度」「メールサーバーのホスト名」の順です。優先度の意味は後のセクションで説明します。
一点だけ覚えておくべきことがあります。MXレコードが指す値はIPアドレスではなく、ホスト名（別のドメイン名）です。 mail.example.com というホスト名に対して、別途Aレコードが設定されていて初めてメールサーバーに到達できます。Google WorkspaceやMicrosoft 365を設定する際に「MXの設定」と「Aレコードの設定」が別々に出てくるのはこのためです。
MXレコードとAレコードの関係
よくある誤解として、「MXをいじったらウェブサイトに影響するか」という不安があります。答えはNOです。MXレコードとAレコードは独立しているため、メールの受信先を変更してもWebサイトの表示には影響しません。
メールとWebサイトを別々のサーバーで動かすことも可能です。例えば、WebサーバーはレンタルサーバーのIPを向いているAレコードのままにしておいて、MXだけGoogle WorkspaceやMicrosoft 365のメールサーバーに向けることができます。
一方、「AレコードとMXが同じIPを指している場合、MXレコードを省略できるか」という疑問についての答えはNOです。MXレコードが無い場合に何が起きるかについては、このあとのセクションで詳しく説明します。
DNSレコード全体の役割と使い分けについては、DNSレコードとは何か — A/CNAME/MX/TXT/TTLを初めて設定する人向けに噛み砕いて解説をあわせて参照してください。AレコードとAAAAレコードの詳細はAAAAレコードとは — IPv6対応とAレコードとの使い分けで扱っています。
MXレコードを設定したのにメールが届かない — nslookupで確認する手順
Windowsのコマンドプロンプトで
nslookup -type=MX 自分のドメインを実行します。MXが正しく引ければ設定は完了しています。それでも届かない場合は、MXの向き先（ホスト名）にAレコードが無いか、SPF/DKIM/DMARC設定の不足が原因として考えられます。
まず、MXが正しく登録されているかを確認します。コマンドプロンプトを開いて次を実行してください。
nslookup -type=MX example.com 8.8.8.8example.com の部分を自分のドメインに置き換えてください。末尾の 8.8.8.8 はGoogleのパブリックDNSサーバーを指定しています。DNSの変更直後で自分のPC側にキャッシュが残っている場合でも、この指定で新しい状態を確認できます。
出力の見方は次のとおりです。
Server: dns.google
Address: 8.8.8.8
Non-authoritative answer:
example.com MX preference = 10, mail exchanger = mail.example.commail exchanger = mail.example.com のような行が返ってくれば、MXレコードの設定は完了しています。
macOSやLinux環境では dig MX example.com で同じことが確認できます。
MXが返ってこない場合は、MXレコードがまだ設定されていないか、DNSへの反映が完了していません。設定後にすぐ確認しても反映されていないことがあります。これはDNSのTTL（Time To Live：キャッシュの有効時間）によるもので、DNSのTTLとは — 反映時間を短くする方法と変更前の確認で詳しく扱っています。
MXが正しく返ってくるのに届かない場合のチェックリストは次のとおりです。
- MXが指すホスト名（
mail.example.comなど）にAレコードが無い — MXにホスト名は書いてあるが、そのホスト名がIPアドレスに紐づいていないと接続できません。nslookup mail.example.comでAレコードを確認してください。 - SPF/DKIM/DMARCが設定されていない — MXの設定とは別に、送信ドメイン認証の設定が不足していると、受信側のスパムフィルターで弾かれます。SPF/DMARCとMXの違いについては後のセクションで整理します。
- MXのホスト名がサービス指定のものと一致していない — Google WorkspaceやMicrosoft 365は、設定すべきMXのホスト名を管理画面で指定しています。コピー元の手順書と現在の設定が一致しているか確認してください。
MXレコードが無いドメインへメールを送るとどうなりますか？
MXレコードが無いドメイン宛てのメールは、SMTPの仕様（RFC 5321 §5.1）によりAレコードのIPアドレスへの配送が試みられます。Webサーバーしか動いていない場合、送信側が数日間再送を繰り返した末に、バウンス（配信不能通知）が返ります。即座にエラーにはなりません。
これが「送ったのにエラーも来ない、でも届いていない」という状態の正体です。
仕組みを順に説明します。
- 送信側のMTAが
example.comのMXレコードを問い合わせる - MXが見つからない場合、SMTPの国際標準仕様（RFC 5321 §5.1）に従って、Aレコードに登録されたIPアドレスへ配送を試みる（これをimplicit MX、暗黙のMXと呼ぶ）
- そのIPにはWebサーバーしか動いておらず、メール受信のポート（25番）に応答がない
- 送信側のMTAはメールをキューに保留し、仕様上の目安は少なくとも4〜5日（RFC 5321 §4.5.4.1）にわたって断続的に再送を試み続ける
- 設定された上限期間が過ぎた時点で、送信者にバウンス（配信不能通知）が届く
RFC 5321 §5.1 の原文は次のように定めています。
“If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.”
（MXの問い合わせに空の応答が返った場合、そのアドレスに対してそのホスト自体を指す優先度0の暗黙のMXレコードがあるものとして扱われる）
この動作は、MXレコードを設定していないウェブ専用ドメインを自分が持っている場合だけでなく、取引先のドメインにMXが無いときにも起きます。
独自ドメインのメールが数日後にエラーで返ってくる場合
「送信側の設定によって異なりますが、数日後にバウンスが届いた」という状況では、送信先のMXレコードが設定されていないことが原因の一つとして考えられます。
確認コマンドです。
nslookup -type=MX 取引先のドメインこの結果に MX preference = の行が返ってこない、あるいは *** 〜 can't find 〜: Non-existent domain のような応答が返ってきた場合、先方のドメインにMXレコードが設定されていません。
即座にエラーが返ってこなかった理由は、上で説明した暗黙のMX動作によって送信側が数日間再送を続けたためです。
取引先のMXが無い場合の説明文（コピペ用）
先方の担当者がDNSの専門知識を持っていない場合、次の文章をそのまま使って説明できます。
「送ったメールが届いていない原因を確認したところ、御社ドメインにMXレコード（メール受信先を指定するDNS設定）が設定されていないことが分かりました。MXレコードが無い状態でもメールの配送は一度試みられますが、最終的に数日かかって不達となります。DNS設定をご担当の方に、MXレコードの追加をお願いできますでしょうか。メールサービスの契約があれば、そのサービスの設定手順書に記載のMXレコード値を追加する作業になります。設定例をご共有することも可能です。」
Null MX — 「このドメインはメールを受け取らない」と明示する方法
MXレコードが無い状態とは別に、意図的に「メールを受け取らない」と宣言する方法があります。これをNull MXと呼び、RFC 7505 で規定されています。
設定値は次のとおりです。
example.com. IN MX 0 .ドット（.）だけを指定することで、「このドメインではメールを受け取らない」と明示します。この設定があると、送信側のMTAはAレコードへのフォールバックを行わず、即座に「メール受け取り不可」と判断して配送を中止します。
MXレコードが無い状態（数日後にバウンスが返る）と比べると、Null MXはエラーが即座に返るため、送信者も先方もすぐに状況を把握できます。Webサイトのみを運用しているドメインや、メール受信を想定していないサブドメインには設定を検討する価値があります。
MXレコードの優先度（preference）の数字の意味は何ですか？
MXが1つだけの場合、優先度の数字は何でも動作は同じです。2つ以上のMXを設定するときに、どのサーバーへ先に配送を試みるかを数字で制御します。数字が小さいほど優先されます。
「なぜ10にするのか、1や5ではダメなのか」と尋ねられたときの答えは次のとおりです。MXが1つしかない間は、何の数字でも同じ動作をします。10という値が使われることが多い理由は、後からMXを追加するときに「5」「20」「30」といった数字を挿入しやすいからです。始めから1を使うと、それより低い優先度を持つバックアップMXを後から設定しにくくなります。
2つ以上のMXを設定する例を示します。
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.この場合、送信側は優先度10の mail1.example.com に最初に接続を試みます。接続できない場合に限り、優先度20の mail2.example.com に試みます。
2つのMXを同じ優先度にした場合は、送信側がランダムに選択します。 これは負荷分散を意図した設定です。
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 10 mail2.example.com.Google WorkspaceやMicrosoft 365の設定手順書には、複数のMXレコードと各優先度の値が記載されています。その値をそのまま使うのが正解です。自分でカスタマイズする必要はありません。
MXレコードとSPF・DKIM・DMARCは何が違いますか？
MXは「どのサーバーでメールを受け取るか」の設定です。SPF/DKIM/DMARCは「送ったメールが本物かどうかを証明する」設定です。役割が異なるため、両方必要です。
| 設定 | 役割 | 方向 |
|---|---|---|
| MX | 受信先サーバーの指定。「このドメイン宛てメールを、どのサーバーへ届けるか」 | 受信 |
| SPF | 送信元IPの認証。「自分のドメインから送信できるIPはこれだ」と宣言する | 送信 |
| DKIM | 電子署名。「このメールは途中で改ざんされていない」と証明する | 送信 |
| DMARC | SPF/DKIMの結果に基づくポリシー。なりすまし対策のルールを定義する | 送信 |
混同が起きやすいのは、どちらもDNSのTXTレコードを使うためです。SPF/DKIM/DMARCはTXTレコードとして設定しますが、MXはMXレコードとして別に設定します。
「MXを設定したのにメールが届かない」状況で、SPF/DKIM/DMARCが設定されていないと何が起きるかというと、受信側（GmailやMicrosoft 365など）のスパムフィルターが送信元の信頼性を判断できず、迷惑メールフォルダに振り分けたり拒否したりすることがあります。MXが設定されていても、送信ドメイン認証が揃っていないと届かないケースがあるのはこのためです。
SPF/DKIM/DMARCの設定を含む独自ドメインメールの全体像については、独自ドメインのメールを持つには？自前サーバーは必要かで詳しく扱っています。
CNAMEとAレコードの使い分けについてはCNAMEとAレコードの違い — どちらを設定するかも参照してください。
まとめ — 確認する順番
MXまわりで問題が起きたときに確認すべき順番を整理します。
nslookup -type=MX 自分のドメイン 8.8.8.8でMXが正しく引けるか確認する- MXが引けているのに届かない場合は、MXの向き先（ホスト名）にAレコードがあるかを確認し、次にSPF/DKIM/DMARCが設定されているかを確認する
- 取引先のMXが無い場合、送ったメールは即座にエラーにはならず、数日後にバウンスが届く。この挙動はSMTPの仕様（RFC 5321 §5.1）によるもの
- Null MX（
MX 0 .）を設定すると、送信側に即座に「配送不可」を返せる。MXが無い状態との違いは、エラーが即座に返るかどうか
MXの設定を間違えても、メールが即座になくなるわけではありません。送信側が数日間再送を試み続けます。だからこそ、設定ミスに気づきにくい。この記事で確認した手順でMXが正しく引けることを確かめれば、次の段階（SPF/DKIM/DMARCの設定）に進めます。一歩ずつで大丈夫です。
メールの設定や不達トラブルで詰まっている場合は、状況をメールでお送りください。確認すべき箇所を一緒に整理します。