人気のツール

テーマ

MXレコード検索

MXレコード検索で、あらゆるドメインのMXレコードを確認できます：配信順に並んだメールサーバー、その運用者、IPv4・IPv6アドレス、STARTTLSに応答するかどうか。ドメイン自身のネームサーバーから直接取得し、GoogleとCloudflareのキャッシュのコピーと並べて表示します。

情報源：ルートサーバーからたどった、ドメインのネームサーバー · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · ムンバイにある当サイトのサーバーからメールサーバーをテスト

入力した名前をそのまま検索します：www.やサブドメインを別の名前に書き換えることはありません。

例

MXレコードとは？

MX（mail exchange、メール交換）レコードは、ドメイン宛てのメールを受信するサーバーを指定するレコードで、それぞれに優先度の数値が付いています：送信側は数値が最も小さいものから試行します。

誰かがname@airbnb.com宛てにメールを書くと、その人のメールサーバーはDNSにairbnb.comのMXレコードを問い合わせ、数値が最も小さいサーバーを選んで、ポート25でSMTPを使って配信します。レコードに入るのはホスト名で、IPアドレスではありません。そのホスト名には自身のAまたはAAAAレコードが必要で、別名（CNAME、RFC 2181 §10.3）であってはなりません。

MXレコード検索は、これらのレコードを読み取り、各サーバーをそのアドレス、ネットワーク、背後のプロバイダーまでたどります。MXが決めるのは受信メールの行き先だけです：ドメインとして誰が送信できるかを決めるのは、SPF、DKIM、DMARCです。

MXレコードの構造airbnb.com自身のネームサーバーから
airbnb.com.名前300TTLINクラスMXタイプ1優先度aspmx.l.google.com.メールサーバー（exchange）
名前 · TTLメールを受信するドメインと、キャッシュがこの応答を保持できる時間：300秒＝5分。
優先度小さいほど先に試行されます。airbnb.comは1、5、5、10、10です。
メールサーバー自身のAレコードとAAAAレコードを持つホスト名：192.178.211.27と2404:6800:4000:1025::1b。
1 aspmx.l.google.com.AレコードとAAAAレコードを持つホスト名
1 192.0.2.25IPアドレスはexchangeとして無効
1 mail → CNAMEexchangeに別名は使えません（RFC 2181 §10.3）
airbnb.com自身のネームサーバーが返したとおりの全フィールドです。ツールは、IPアドレス、CNAME、アドレスのない名前を指すMXに警告を表示します。

MXレコードの確認方法

上の欄にドメインを入力してMXを検索を押すか、ターミナルからDNSに問い合わせます：macOSとLinuxではdig example.com MX、どのシステムでもnslookup -type=mx example.com、WindowsのPowerShellではResolve-DnsName example.com -Type MXです。

応答の各行が1台のサーバーで、優先度、ホスト名の順に並びます。INの前の数値はTTL、つまりリゾルバーがこのコピーを返し続けてよい秒数です。@とネームサーバーを加えると（dig @dns1.p08.nsone.net airbnb.com MX）、キャッシュではなくゾーン自身の応答を読めます。

dig example.com MX +short

各行は優先度、メールサーバーの順です。キャッシュを経由しないようにするには、@とネームサーバーを加えます。

digの応答の読み方2026年10月23日に記録
bash · zsh
$ dig airbnb.com MX
;; ->>HEADER<<- opcode: QUERY, status: NOERROR1
;; flags: qr rd ra; QUERY: 1, ANSWER: 5

;; ANSWER SECTION:
airbnb.com.    3002  IN  MX   13 aspmx.l.google.com.4
airbnb.com.    300   IN  MX   5 alt1.aspmx.l.google.com.
airbnb.com.    300   IN  MX   5 alt2.aspmx.l.google.com.
airbnb.com.    300   IN  MX  10 alt3.aspmx.l.google.com.
airbnb.com.    300   IN  MX  10 alt4.aspmx.l.google.com.

;; SERVER: 8.8.8.8#53(8.8.8.8)5
  1. ステータス： NOERRORで応答あり。NXDOMAINは名前が存在しないこと、応答のないNOERRORはMXがないことを意味します。
  2. TTL： このコピーをあと何秒返せるか。情報源では300で、キャッシュではカウントダウンしていきます。
  3. 優先度： 送信側が試行する順番。小さいものから試行します。
  4. メールサーバー： ポート25で接続するホスト。末尾のドットで名前が終わります。
  5. 応答したサーバー： 8.8.8.8はキャッシュです。@dns1.p08.nsone.netはゾーン自身に問い合わせます。
同じ5行は、ツールの「サーバー」表示で優先度ごとに並べ替え・グループ化され、各サーバーのアドレスとともに表示されます。

MXレコード検索の結果の見方

冒頭の1文で、ドメインのメールを誰が受信し、その背後に何台のサーバーがあるかを、プロバイダーのマークとともに示します。その下の色付きの行が、重要な指摘事項です。

「サーバー」表示では、すべてのMXホストを優先度順に、アドレス、ネットワーク、逆引きDNSとともに一覧表示します。最初のサーバーはポート25で自動的にテストし、ほかのサーバーは選んだときにテストします。右側の配信経路は、送信側がこれらの応答をもとにどう動くかを図示します。

MXレコード検索の結果：Google Workspaceの5件のMXレコード、各メールサーバーのアドレスとSTARTTLSテスト、配信経路MXレコード検索の結果：Google Workspaceの5件のMXレコード、各メールサーバーのアドレスとSTARTTLSテスト、配信経路判定メールの受信先、サーバーと優先度の段階、ネットワーク、TTL、応答したネームサーバー。サーバー優先度順の各MXホストと、そのIPv4・IPv6アドレス、AS番号、正引きで確認したPTR。SMTPテスト当サイトのサーバーからポート25で確認したSTARTTLSとTLSのバージョン。行を開くと、やり取り全体が表示されます。配信経路送信者、最初の経路の保護、優先度の各段階、そしてメールボックスとその根拠。
airbnb.comのMXレコード検索の例です。判定、優先度順のサーバーとそのアドレスやSTARTTLSテスト、メールがたどる経路を表示します。番号を選ぶと、各部分に何が表示されているかを確認できます。

MXの優先度とは？

優先度（RFC 5321ではpreferenceと呼びます）は順番を決めます：送信側は数値が最も小さいものから試行し、そのサーバーが応答しないか、一時的な4xxの応答でメッセージを保留した場合にだけ、次に進みます。

同じ数値のサーバーは負荷を分け合います：送信側はその中から1台をランダムに選びます。意味を持つのは順番だけで、数値の間隔は関係なく、0も有効な数値です。Microsoft 365やMimecastのように、背後の名前が多数のサーバーに分散している場合は、MXレコードは1つで十分です。

バックアップMXについての当サイトの助言：プライマリよりフィルタリングの甘い他社のバックアップはスパムの抜け道として知られており、ホスティング型のプロバイダーは1つのMX名の背後ですでに冗長なサーバーを運用しています。バックアップを置く場合は、プライマリと同じSPFとスパムのチェックを適用する必要があります（RFC 7208、付録F）。

airbnb.comの5台のサーバーを送信側がたどる順番優先度 1 · 5 · 10
1回目優先度1
aspmx.l.google.com常に最初に試行
250 OK

応答がないか4xxを返した場合のみ

2回目優先度5
alt1.aspmx.l.google.comランダムに選択 · ½alt2.aspmx.l.google.comまたはこちら · ½
同じ数値は負荷を分散

次に

3回目優先度10
alt3.aspmx.l.google.com½alt4.aspmx.l.google.com½
すべて失敗：キューに入れて数日間再試行
0も有効github.comは唯一のMXに優先度0を設定しています。
1, 5, 10 ≡ 10, 20, 30意味を持つのは順番だけで、間隔は関係ありません。
MXは1つでも十分hp.comの1台のMXホストの背後には6つのアドレスがあります。
送信側がリストの次に進むのは、サーバーが応答しないか一時的なエラーを返した場合だけです。すべてのサーバーが失敗すると、メッセージはキューで待機し、4〜5日間再試行されます（RFC 5321）。

Google WorkspaceのMXレコード

新しいGoogle Workspaceのドメインに必要なMXレコードは1つだけです：優先度1のsmtp.google.comです。2023年より前に設定されたドメインでは、aspmx.l.google.comで始まる5件のレコードのセットを今も公開していることがよくあります。Googleは、どちらも機能し、動作している設定は変更不要だとしています。

ツールはどちらのセットでもGoogle Workspaceと表示し、古いほうを旧来の構成として示しますが、エラーとは扱いません。MXに加えて、SPFのinclude:_spf.google.comと、管理コンソールで設定するDKIMを組み合わせてください。Googleは、新しいMXレコードが全体に反映されるまで最大72時間かかるとしています。

Google Workspaceの2つの構成の比較2026年10月23日時点のMX
現在レコード1件推奨
1 smtp.google.com.
使用例： google.comsendgrid.com
旧来レコード5件現在も有効
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.
使用例： airbnb.comnytimes.comuber.comspotify.com
google.com自身のMTA-STSポリシーは両方を許可しています：smtp.google.comaspmx.l.google.com*.aspmx.l.google.com
spotify.comは、古いaspmx2〜aspmx5.googlemail.comのホストを優先度10で今も記載しており、合計7件のレコードになっています：旧来の名前が余分にあっても害はありません。

Microsoft 365のMXレコード

Microsoft 365では、各ドメインにmail.protection.outlook.comの下のMXレコードが1つ割り当てられます。たとえばmicrosoft-com.mail.protection.outlook.comで、優先度は通常0です。最初の部分はMicrosoft 365管理センターからコピーするトークンで、ドメインのドットをダッシュに置き換えた形のことが多いものの、常にそうとは限りません。

受信SMTP DANEを有効にしたドメインには、代わりにmx.microsoftの下のホストが割り当てられます。たとえばsiemens-com.h-v1.mx.microsoftです。このゾーンはDNSSECで署名されているため、送信側はDANEでサーバーの証明書を確認できます。移行中は両方のレコードが有効で、新しいレコードは最初は古いレコードの後ろに、次にその前に置かれ、最後に古いレコードが削除されます。Microsoftはmail.protection.outlook.comに署名する予定はないため、旧来のホストが時代遅れになったわけではありません。

Microsoft 365のMXホストの読み方microsoft.com · siemens.com
Exchange Online一般的な形式
microsoft-com管理センターのトークン.mail.protection.outlook.comExchange Online Protection
使用例： microsoft.comgithub.comunilever.com
DANE対応DNSSECで署名されたゾーンDANE
siemens-com管理センターのトークン.h-v1シャード.mx.microsoft署名済みのゾーン
使用例： siemens.comshell.com
新しいホストへの移行中両方のレコードが有効。数値の小さいほうが優先
0contoso-com.o-v1.mx.microsoft.新 · 最初に試行
30contoso-com.mail.protection.outlook.com.旧 · 削除されるまで
旧来のホスト1つとmx.microsoftのホスト1つが異なる優先度で並んでいるのは、Microsoftが手順として示している移行の途中であり、エラーではありません：ツールは警告せず、そのように表示します。

MXレコードがない場合とnull MXの場合、どうなる？

MXレコードのないドメインでも、メールを受信できることがあります：送信側はドメイン自身のAまたはAAAAのアドレスに切り替えて配信します（RFC 5321 §5.1）。ドメインがメールを一切受け付けないことをすべての送信側に伝えられるのは、null MX、つまり0 .という単一のレコードだけです（RFC 7505）。

そのため、メールを一切受信しないドメインにはnull MXが適したレコードです：送信側は何日も再試行する代わりに、556 5.1.10ですぐにバウンスします。誰もそのドメインとして送信できないよう、example.comのようにv=spf1 -allとDMARCのp=rejectも加えてください。MXレコードは1つの名前にだけ属します：www.example.comはexample.comのMXを引き継ぎません。

4つの応答、4つの結果それぞれの場合に送信側が行うこと
MXレコードありairbnb.com優先度の順にサーバーへ配信します。配信250 OK
MXなし、A/AAAAありwww.google.com名前自身のアドレスに配信：AレコードとAAAAレコードです。そこでポート25が応答しなければ、メールは待機した後、バウンスします。暗黙のMXRFC 5321 §5.1
null MX：0 .example.com配信を一切試みません。送信側はメッセージをすぐにバウンスします。拒否556 5.1.10
名前が存在しないairbnb.cmoバウンス：ルートに.cmoがないため、その下の名前も存在しません。バウンス5.1.2

メールの送信も受信もしないドメイン：MX 0 .v=spf1 -all_dmarc p=reject

各行は、その例に対するツール自身の判定です：ツールの上にある例のチップから開けます。

メールが届かない？トラブルシューティングにおけるMXの位置づけ

まずバウンスメールを読んでください：ステータスコードが、どの段階で失敗したかを示します。MXの問題は「host not found」（ホストが見つからない）や長い遅延として現れます。メールボックスが存在しない場合は5.1.1、認証の失敗は5.7.xの拒否です。

上から順に確認していきます：ドメインが存在すること、MXが利用中のプロバイダーを指していること、各MXホストが名前解決でき、ポート25で応答すること。それが済んで初めて、SPF、DKIM、DMARC、ブラックリストがメッセージの行き先を左右します。

バウンスから解決まで拡張ステータスコード（RFC 3463）
ホストまたはドメインが見つからない5.1.2 · NXDOMAINドメインまたはそのMXホストが存在しません。つづりとネームサーバーを確認してください。DNS検索
メールがまだ古いプロバイダーに届くMXの変更後キャッシュはTTLが切れるまで古いMXを保持します。ゾーンの応答をGoogleとCloudflareのコピーと比較してください。「コピー」表示
遅延の後にバウンス4.4.1 · ホストの応答なしMXホストがダウンしているか、アドレスがないか、ポート25がブロックされています。当サイトからサーバーをテストしてください。サーバーをテスト
ユーザー不明5.1.1MXは機能していますが、プロバイダーにそのメールボックスが存在しません。メールアドレス存在確認
拒否：認証されていない5.7.1受信側が送信者を拒否しました。送信ドメインのSPF、DKIM、DMARCを修正してください。SPFレコードチェッカー
アドレスでブロックされる、または迷惑メールに入る登録あり送信サーバーのIPがブラックリストに登録されています。IPブラックリストチェック
強調表示された2つの段階はこのツール自身の表示で、それ以外は対応するツールが開きます。

メールサーバーのMTA-STS、DANE、TLS

メールサーバーは双方がSTARTTLSを提供する場合にのみ暗号化するため、経路上の誰かがその提供を取り除けば、メッセージを読むことができます。MTA-STSとDANEを使うと、ドメインは送信側にTLSを要求できます。

MTA-STSは、許可するMXホストとモードを記載したポリシーをHTTPSで公開します（https://mta-sts.<domain>/.well-known/mta-sts.txt）。enforceの場合、送信側はそれらのホストに有効なTLSでのみ配信します（RFC 8461）。DANEはサーバーの鍵を_25._tcp.<mx host>のTLSAレコードに置きますが、これが意味を持つのは、そのゾーンがDNSSECで署名されている場合だけです（RFC 7672）。TLS-RPTは送信側に失敗の報告を求めます（RFC 8460）。ツールは、実際のすべてのMXがポリシーのmx:行と一致するかを確認します。

1つの経路にかかる3つの鍵送信者 → proton.me（実測）
送信者任意のメールサーバー
STARTTLS · 提供あり、TLS 1.3STARTTLSだけでは途中で取り除かれる可能性があります：250-STARTTLSが応答から消えるだけです。
MTA-STS · enforceモードmx: mail.protonmail.ch · mx: mailsec.protonmail.ch · max_age: 604800 ✓ 実際のMXホスト2台とも一致
DANE · TLSA 3 1 1_25._tcp.mail.protonmail.ch、DNSSECで署名（protonmail.ch） ✓
mail.protonmail.ch優先度10
TLS-RPTも有効です：v=TLSRPTv1; rua=https://reports.proton.me/reports/smtptls。ツールはSTARTTLSを当サイトのサーバーからテストし、MTA-STSとDANEはDNSとポリシーファイルから読み取ります。

主要プロバイダーのMXホスト

ほとんどのドメインは、数十社ほどのプロバイダーのいずれかにMXを向けており、各社は見分けのつくホスト名を公開しています。ツールはこれを手がかりにドメインのメールプロバイダーを特定します。設定をプロバイダー自身の値と照らし合わせて確認することもできます。

Mimecast、Proofpoint、Barracudaなどのゲートウェイは、メールボックスのホストの前段に置かれます。その場合、ツールはSPFとAutodiscoverを読み取り、背後にあると思われるメールボックスを特定します。

プロバイダー別のMXホストとSPFのincludeツールが識別する110以上のプロバイダーのうち16社
プロバイダーMX（優先度 ホスト）SPF
Google Workspace1smtp.google.comまたは 1 aspmx.l.google.com + 4 altinclude:_spf.google.com
Microsoft 3650<token>.mail.protection.outlook.comまたは <token>.<x>-v1.mx.microsoftinclude:spf.protection.outlook.com
Zoho MailTLDで地域を区別10mx.zoho.com20mx2.zoho.com · 50 mx3.zoho.cominclude:zohomail.com
Proton Mail10mail.protonmail.ch20mailsec.protonmail.chinclude:_spf.protonmail.ch
iCloud Mail10mx01.mail.icloud.com10mx02.mail.icloud.cominclude:icloud.com
Fastmail10in1-smtp.messagingengine.com20in2-smtp.messagingengine.cominclude:spf.messagingengine.com
Yandex 36010mx.yandex.netredirect=_spf.yandex.net
Titan Email10mx1.titan.email20mx2.titan.emailinclude:spf.titan.email
GoDaddy Professional Email0smtp.secureserver.net10mailstore1.secureserver.netinclude:secureserver.net
Namecheap Private Email10mx1.privateemail.com10mx2.privateemail.cominclude:spf.privateemail.com
Cloudflare Email Routing転送route1/2/3.mx.cloudflare.net優先度はドメインごとに設定include:_spf.mx.cloudflare.net
Amazon SESWorkMailと共用10inbound-smtp.<region>.amazonaws.cominclude:amazonses.com
Mimecastゲートウェイ10<region>-smtp-inbound-1.mimecast.com10<region>-smtp-inbound-2.mimecast.cominclude:<region>._netblocks.mimecast.com
Proofpointゲートウェイmx0a-<id>.pphosted.com · mx0b-<id>または mx1-us1.ppe-hosted.com (Essentials)a:dispatch-us.ppe-hosted.com (Essentials)
Barracudaゲートウェイ1<id>.ess.barracudanetworks.com10<id>.ess.barracudanetworks.cominclude:spf.ess.barracudanetworks.com
NAVER WORKS韓国10kr1-aspmx1.worksmobile.com20kr1-aspmx2.worksmobile.cominclude:spf.worksmobile.com

MXレコード検索：よくある質問

MXレコード検索は何に使いますか？

MXレコードの検索では、ドメインのメールをどのサーバーが受信し、誰が運用しているかがわかります。企業のメールプロバイダーを調べる、プロバイダーの移行後にMXの変更を確認する、バウンスや遅延の原因を調べる、送信前にドメインを確認するといった用途に使えます。このツールは、当サイトのサーバーから各メールサーバーのSTARTTLSもテストし、ドメインのSPF、DMARC、MTA-STSも読み取ります。

nslookupでMXレコードを確認するにはどうすればよいですか？

nslookup -type=mx example.comを実行します。応答の各行には、優先度が「MX preference」、サーバーが「mail exchanger」として表示されます。nslookup -type=mx example.com 8.8.8.8のように末尾にサーバーを加えると特定のリゾルバーに問い合わせられ、ドメイン自身のネームサーバーを指定すれば、キャッシュをすべて回避できます。macOSとLinuxでは、dig example.com MXで同じ応答が得られます。

1つのドメインに複数のMXレコードを設定できますか？

できます。各MXレコードは、1台のメールサーバーを優先度とともに指定します。送信側は数値が最も小さいものから試し、サーバーが応答しないか保留した場合にだけ次に進みます。同じ数値のサーバーの中からはランダムに選ぶため、負荷が分散されます。gmail.comは5つの優先度で5件のMXレコードを、yahoo.comは同じ優先度で3件を公開しています。

MXレコードにIPアドレスやCNAMEを指定できますか？

できません。MXの値は、自身のAまたはAAAAレコードを持つホスト名でなければなりません。IPアドレスは有効な値ではなく、RFC 2181は別名（CNAME）であるMXホストを禁じています。CNAMEをたどったりIPに接続したりする送信側もあれば、拒否する送信側もあるため、送信元によってメールが届いたりバウンスしたりします。ツールはどちらにも警告を表示します。

MXレコードの変更が反映されるまでどのくらいかかりますか？

古いレコードのTTLの長さだけかかります。古いMXをキャッシュしたリゾルバーは、コピーの期限が切れるまでそれを使い続け、その後ドメインのネームサーバーに改めて問い合わせます。キャッシュされた「MXなし」の応答も同じように期限切れになります。プロバイダーを切り替える前日にTTLを下げておきましょう。プロバイダーは安全のための余裕を示しており（Googleは最大72時間）、「コピー」表示ではGoogleとCloudflareのコピーがいつ更新されるかがわかります。

null MXレコードとは何ですか？

null MXは、優先度0でホストにドット1つだけを指定した単一のMXレコード、0 .です（RFC 7505）。そのドメインがメールを一切受け付けないことを示すため、送信側は何日も再試行せず、556 5.1.10ですぐにメッセージをバウンスします。null MXは唯一のMXレコードでなければなりません。example.comは、SPFの-allとDMARCのp=rejectとあわせて公開しています。

ドメインにMXレコードがないとどうなりますか？

それでもメールの配信は試みられます。MXレコードがない場合、送信側はドメイン自身のAまたはAAAAのアドレスに配信します。これが暗黙のMXです（RFC 5321の5.1節）。そこでポート25に何も応答しなければ、メッセージは送信側のキューで待機し、4〜5日間再試行された後にバウンスします。メールを受信すべきでないドメインは、代わりにnull MXを公開してください。

MXレコードが1つだけなのは問題ですか？

問題ありません。背後の名前が負荷分散されていれば、MXレコード1つで完全な設定です：Google Workspaceのsmtp.google.comも、Microsoft 365のmail.protection.outlook.comのホストも、それぞれ多数のサーバーから応答します。RFC 5321はMXレコードの最小数を定めていません。ツールは各MXホストの背後にあるIPv4とIPv6のアドレス数を表示するため、冗長性を確認できます。

MXに表示されるプロバイダーが予想と違うのはなぜですか？

メールボックスの前段にゲートウェイが置かれていることがあります。Mimecast、Proofpoint、Barracuda、Cloudflare Email Securityはメールを先にフィルタリングするため、MXにはゲートウェイが表示され、メールボックスはその背後のMicrosoft 365、Google Workspace、または別のプロバイダーにあります。ツールはドメインのSPFのincludeとAutodiscoverレコードを読み取って、メールボックスのプロバイダーと思われるものを特定し、その根拠を表示します。

MXレコードは公開されていますか？

はい。MXレコードは設計上、公開のDNSデータです：世界中のどのメールサーバーも、あなたのドメインに配信するためにMXレコードを検索できなければなりません。わかるのは、どのサーバーがメールを受信し、誰が運用しているかであり、誰が送信しているかやメールボックスの中身ではありません。MXレコードを隠すと、メールが届かなくなります。

MXレコードはメールの送信に影響しますか？

影響しません。MXレコードが決めるのは、受信メールをあなたのサーバーに届ける経路だけです。どのサーバーがあなたのドメインとして送信できるかはSPF、DKIM、DMARCで決まり、受信側はメッセージごとにそれらを確認します。送信と受信で別のプロバイダーを使うこともでき、その場合は両方がSPFに記載され、MXには受信用のプロバイダーだけが記載されます。

自分のコンピューターからポート25に接続できないのはなぜですか？

ほとんどの家庭用・モバイルのネットワークや、AWS、Google Cloud、Azureなどのクラウドは、スパム対策としてポート25への外向きの接続をブロックしているため、メールサーバーへのtelnetやopensslはタイムアウトします。これはサーバーの状態とは無関係です。このツールは、ポート25に接続できるムンバイの当サイトのサーバーから各メールサーバーをテストし、やり取り全体を表示します。

その他のDNS・メールツール