あなたの MX レコードは
正しく
設定されていますか？ Decorative underline

壊れた MX レコードはメールの取りこぼしを意味します。ドメインのメール交換設定を数秒でスキャンしましょう。

優先度の値、冗長性、サーバーの到達可能性を、すべて 1 回の無料スキャンで確認します。

有効なドメインを入力してください。
スキャンの前に同意する必要があります。
MX レコードスキャンのイラスト

MX レコードが重要な理由 - 思っている以上に

MX レコードはメールインフラの郵便住所です。MX レコードが誤設定されていたり欠けていたりすると、誰もあなたにメールを送れず、しかもそれが起きていることにすら気づきません。

Email routing 誤設定された MX レコードは受信メールを密かに破棄します - 顧客があなたに連絡できません
Redundancy 冗長性がないと、サーバー 1 台の障害ですべての受信メール配信が止まります
Priority 誤った優先度の値により、メールが不必要にバックアップサーバーへルーティングされ、遅延が生じます

DMARCFlow の MX チェッカーが検証するもの

  • ✓ MX レコードの存在 - ドメインの DNS に少なくとも 1 つの有効な MX エントリがあることを確認します
  • ✓ 優先度の値 - プライマリとバックアップのサーバーに対して優先度の番号が正しく設定されているかを検証します
  • ✓ 冗長性チェック - フェイルオーバー保護のために少なくとも 2 つの MX レコードが存在することを確認します
  • ✓ サーバーの到達可能性 - メール交換サーバーが実際に応答するかどうかをテストします
  • ✓ TTL の値 - DNS の反映速度に影響する time-to-live の設定を確認します

DMARCFlow の無料 MX チェッカーを使う理由

プロ品質の MX 検証 - アカウント不要、即時結果。

Instant lookup
即時 DNS ルックアップ

正確でリアルタイムの結果のために、キャッシュされたデータではなく権威サーバーへのライブ DNS クエリを実行します。

Redundancy analysis
冗長性分析

障害を乗り切るのに十分なバックアップのメール交換サーバーがあるかを自動的にチェックします。

Priority check
優先度の検証

MX の優先度の値が正しい順序になっており、メールが最初に正しいサーバーへルーティングされることを確認します。

Actionable advice
実用的なガイダンス

すべての結果の明確な説明と、お使いの DNS プロバイダー向けの段階的な修正手順。

MX レコードを誤る代償

MX レコードが誤設定されている場合と適切に検証されている場合に何が起こるかをご覧ください。

チェックしない場合
受信メールが密かにバウンスする メールルーティングの単一障害点 誤った優先度が不必要なフォールバックルーティングを引き起こす 到達不能なサーバーが何日も検出されない 取りこぼしたメールによるビジネス機会の損失
DMARCFLOW あり
MX 設定への即時の可視性 冗長性を検証 - 単一障害点なし 最適なルーティングのために優先度の順序を確認 サーバーの到達可能性をリアルタイムで確認 あらゆる DNS プロバイダー向けの明確な修正手順 受信メールが届くという安心 無料、即時、アカウント不要

メールがバウンスし始めるまで待たないでください。今すぐ MX レコードをチェック - 無料です。

よくある 質問 Decorative underline

MX レコードとメールルーティングについて知っておくべきすべてのこと

MX（Mail Exchange）レコードは、あなたのドメイン宛てのメールをどのメールサーバーが受信すべきかをインターネットに伝える DNS エントリです。誰かが user@yourdomain.com にメールを送ると、送信側メールサーバーはあなたの MX レコードを検索して配信先を見つけます。有効な MX レコードがなければ、ドメインはメールを受信できません。

優先度の値（「preference」とも呼ばれます）は、メールサーバーが試される順序を決めます。番号が小さいほど優先度が高く、優先度 10 のサーバーは 20 のサーバーより先に試されます。プライマリ（最も小さい優先度番号）のサーバーが到達不能な場合、送信サーバーは自動的に次のものを試します。

ベストプラクティスは、異なるメールサーバーを指す少なくとも 2 つの MX レコードを持つことです。これにより冗長性が確保され、1 台のサーバーがメンテナンスや障害で停止しても、メールはバックアップサーバーへ配信され続けます。ほとんどのクラウドメールプロバイダー（Google Workspace、Microsoft 365）は複数の MX レコードを自動的に設定します。

3600 秒（1 時間）の TTL（Time to Live）は、MX レコードの広く受け入れられているデフォルトです。メールプロバイダーを変更する予定がある場合は、前日に TTL を一時的に 300〜600 秒に下げて変更が速く反映されるようにします。移行後は、DNS クエリの負荷を減らすために 3600 以上に戻してください。

いいえ。MX レコードは IP アドレスではなくホスト名（mail.example.com など）を指す必要があります。そのホスト名自体が A または AAAA レコードを介して IP に解決される必要があります。MX レコードを IP アドレスに直接向けることは DNS 標準違反であり、多くのメールサーバーでメール配信の失敗を引き起こします。

MX レコードは受信メールのルーティング（誰がドメイン宛てのメールを受信できるか）を扱い、SPF と DMARC は送信メールの認証（送信時に名乗っているとおりの相手であることの検証）を扱います。これらは完全なメールセキュリティスタックの一部として連携します。ドメインには、信頼できる配信となりすましからの保護の両方のために、正しい MX レコードに加えて適切に設定された SPF、DKIM、DMARC が必要です。

MX サーバーが到達不能に見える理由はいくつかあります：サーバーが一時的に停止している、ファイアウォールがポート 25（SMTP）をブロックしている、MX レコードのホスト名が有効な IP に解決されない、またはサーバーの SSL/TLS 証明書が期限切れになっている、などです。プライマリ MX サーバーが到達不能な場合、送信者はメールをキューに入れて再試行するか、存在すればセカンダリ MX レコードにフェイルオーバーします。