2026年5月24日

MXレコードの設定でメールが届かないときの原因と確認手順

DNS・名前解決

独自ドメインのメールが届かないとき、まず確かめたいのは「MXレコードが、いま使っているメールサービスの受信サーバーを正しく指しているか」です。とくにDNSやサーバーを移行した直後は、MXレコードの移し忘れや、旧サービスのレコードの残りが原因になっていることが多くあります。この記事では、エラーメール（バウンス）の読み方とMXレコードの確認コマンドから始めて、原因を起こりやすい順に確認・修正する手順と、WordPressから送るメールが届かない場合の切り分けを説明します。

まずバウンスメールとDNSの応答を確認する

送信者側にエラーメール（「Undelivered Mail Returned to Sender」「Delivery Status Notification」など）が戻っていれば、本文にSMTPの応答コードが書かれています。これが一番の手がかりです。

「Host or domain name not found」「No MX or A records」など: 宛先ドメインのMX（またはその向き先）が引けていません。この記事の原因1〜3が該当します。
5.1.1（User unknown など）: MXは正しく、受信サーバーまで届いていますが、宛先のアドレスが存在しません。メールボックスの作成状況を確認します。
5.7.x（ポリシーや認証に関するもの）: 受信側がSPF・DKIM・DMARCや送信元IPの評価で拒否しています。宛先側のMXではなく、送信側の設定の問題です。
4.x.x: 一時的なエラーで、送信側は時間をおいて再送します。続く場合は受信サーバーの状態やブロックを疑います。

あわせて、DNSの応答を確認します。

# MXレコード（優先度と受信サーバー名が返る）
dig +short MX example.com
# 10 mx1.mail-provider.example.
# 20 mx2.mail-provider.example.

# 受信サーバー名がIPアドレスに解決できるか
dig +short A mx1.mail-provider.example.

# このドメインの権威DNS（どこで編集すべきか）
dig +short NS example.com

Windowsでは Resolve-DnsName example.com -Type MX で同じ確認ができます。MXの数字は優先度で、小さい値ほど優先されます。

原因1: DNS移行時にMXレコードを移し忘れた（最も多い）

ネームサーバーをレンタルサーバーやCloudflareなどへ切り替えると、それまでのDNSに登録していたレコードは引き継がれません。Webサイト用のAレコードだけを登録して、MXレコードを登録し忘れると、その時点からメールが届かなくなります。

dig +short MX example.com が何も返さない、あるいは旧サービスの値を返している場合は、NSが向いているDNSサービスの管理画面で、利用中のメールサービス（Google Workspace、Microsoft 365、レンタルサーバーのメールなど）が案内している値を登録します。登録する値は各サービスのヘルプに記載されています。案内される受信サーバー名や優先度はサービス側で変更されることがあるため（2026年10月現在）、古いブログ記事ではなく公式の案内を参照してください。

MXが無いときは、送信側はドメインのAレコード（Webサーバー）へ配送を試みる仕様です。そのため「MXが無いのにエラーにならず、Webサーバー側でメールが行方不明になる」こともあります。

原因2: MXの値の書き方が誤っている

MXレコードの値は、受信サーバーのホスト名です。次の誤りがよく見られます。

IPアドレスを直接書いている: MXの値にIPアドレスは書けません。mail.example.com のようなホスト名を書き、そのホスト名にAレコードを用意します。
CNAMEを指している: MXの向き先は別名（CNAME）ではなく、Aレコード（またはAAAAレコード）を持つ名前にする決まりです。受信側によっては配送に失敗します。
末尾のドット忘れ: ゾーンファイルで mx1.mail-provider.example と末尾のドットを省くと、ゾーン名が補われて mx1.mail-provider.example.example.com になります。管理画面ではドットの扱いが自動のことが多いですが、登録後に dig で実際の値を確認してください。
ホスト名欄の誤り: ドメイン全体のメールなら、ホスト名はルート（@ や空欄）です。mail などのサブドメインに登録すると、user@mail.example.com 宛てのMXになります。

自前の受信サーバーを mail.example.com で運用している場合、CloudflareなどのCDNでそのホスト名をプロキシ有効にしていると、メールの通信は中継されないため届きません。メール用のホスト名はDNSのみ（プロキシ無効）にしてください。

原因3: 新旧のMXレコードが混在している

メールサービスを乗り換えたときに旧サービスのMXを消し忘れると、優先度の設定によっては一部のメールが旧サービスへ配送されます。「届くメールと届かないメールがある」場合はこれを疑います。dig +short MX で返る行をすべて確認し、今使っていないサービスの行を削除します。

逆に、MXを 0 . という1行にしている場合は「このドメインはメールを受け付けない」という宣言（Null MX）です。メールを使わないドメインのためのものなので、受信したい場合は消してください。

原因4: Webサーバー自身が宛先ドメインのメールを抱え込んでいる

WordPressのお問い合わせフォームから info@example.com へ送ったメールだけが届かず、外部のGmailから送ると届く、という症状はよくあります。MXは正しく外部のメールサービスを向いているのに、Webサーバーが「example.com は自分宛て」と判断してローカルに配送しているのが原因です。

自分で構築したサーバーでは、Postfix の mydestination にドメイン名が含まれていると、そのドメイン宛てはローカル配送になります。postconf mydestination で確認し、外部サービスでメールを受けるなら、ドメイン名を外します。
cPanel などのコントロールパネルを使うレンタルサーバーでは、ドメインのメール配送先を「ローカル」か「リモート（外部）」か選ぶ設定があることがあります。項目名は製品やバージョンで異なるので、マニュアルでメールのルーティング設定を確認してください。

設定を変える前には、現在の設定ファイルのバックアップを取ってください。

原因5: 受信は正しいが、送信側の認証で拒否されている

MXは受信のための設定で、送信には関係しません。WordPressからのメールが迷惑メールに入る、または5.7.x系で拒否される場合は、送信元ドメインのSPF・DKIM・DMARCを確認します。

WordPressの wp_mail() は、既定ではサーバーのPHPのメール送信機能を使います。サーバーのIPがSPFに含まれていない、DKIM署名が無いといった状態だと、受信側で拒否されやすくなります。対策としては、WP Mail SMTP、FluentSMTP、Post SMTP といったSMTPプラグインで、Google WorkspaceやメールサービスのSMTP・APIから送信する方法が一般的です。プラグインの設定項目や無料版で使える送信方法は変わることがあるので、導入時に公式の説明を確認してください。

送信の失敗を記録したい場合は、コアのアクションフック wp_mail_failed が使えます。mu-plugin などに置くと、送信エラーの内容だけをログに残せます。宛先や本文には個人情報が含まれるため、ログには残さない例にしています。

<?php
// wp-content/mu-plugins/log-mail-failures.php
add_action( 'wp_mail_failed', function ( WP_Error $error ) {
	error_log( 'wp_mail_failed: ' . $error->get_error_message() );
} );

error_log() の出力先は、wp-config.php で WP_DEBUG_LOG を有効にしている場合は通常 wp-content/debug.log です。このファイルが外部から読めないよう、確認後は無効に戻すか、Webサーバー側でアクセスを拒否してください。

修正後の確認方法

dig +short MX example.com を、手元のほか dig @8.8.8.8 や dig @1.1.1.1 でも実行し、新しい値が返ることを確認します。MXのTTLが長いと、古い値がしばらく残ります。
外部のメールアドレス（Gmailなど）から、届かなかった宛先にテストメールを送ります。
受信したメールのヘッダー（Gmailなら「メッセージのソースを表示」）で、Received: 行から経由したサーバーと、SPF・DKIM・DMARCの判定結果を確認します。
WordPressのフォームからも送信し、フォーム経由と外部からの両方で届くことを確認します。

移行作業の前には、MXのTTLを短くしておき、旧サービス側のメールボックスもしばらく残しておくと、切り替え中に届いたメールを取りこぼしにくくなります。

まとめ

バウンスのSMTPコードで、MXの問題（宛先が見つからない）か、宛先アドレスや送信認証の問題かを最初に分けます。
MXの問題では、DNS移行時の移し忘れ、IPアドレスやCNAMEを指す誤り、新旧レコードの混在を順に確認します。
フォームから自ドメイン宛てだけ届かない場合は、Webサーバーがローカル配送していないかを確認します。
WordPressからの送信が拒否される場合は、MXではなくSPF・DKIM・DMARCとSMTPプラグインでの送信を見直します。