2026年9月30日

メールが受信できないときの原因の調べ方｜MXレコード・ポート25・ログの確認手順

DNS・メールサーバー

独自ドメインのメールが受信できないとき、原因は「DNSで配送先がわからない」「配送先のサーバーに接続できない」「サーバーが受け取りを拒否している」「受け取ったが受信箱に入っていない」のどこかにあります。この記事では、送信側から受信箱まで、メールが通る順に調べる方法を説明します。

コマンドの例は、LinuxのVPSで Postfix（SMTPサーバー）と Dovecot（IMAP/POP3サーバー）を使っている構成を前提にしています。レンタルサーバーやGoogle Workspaceなどのメールサービスを使っている場合も、DNSと送信側のエラーメールの確認は同じ手順で行えます。example.com と user@example.com は自分のドメインとアドレスに置き換えてください。

1. 送信側に戻ってきたエラーメールを読む

外部のアドレス（Gmailなど）から自分のアドレス宛てにテストメールを送り、送信側にエラーメール（バウンスメール）が戻ってくるかを確認します。エラーメールの本文には、受信側のサーバーが返したエラーコードが書かれていて、原因を絞り込む手がかりになります。

エラーの例	意味	調べる場所
`Domain not found`、`Host or domain name not found`	ドメインのMXレコードもAレコードも引けない	DNS（手順2）
`Connection timed out`、`Connection refused`	配送先のサーバーのポート25に接続できない	ポート25の疎通（手順3）
`550 5.1.1 User unknown`	受信側のサーバーに、そのアドレスが存在しない	メールアカウントの設定（手順4）
`554 5.7.1 Relay access denied`	受信側のサーバーが、そのドメインを自分宛てとして扱っていない	Postfixのドメインの設定（手順4）
`552 5.2.2 Mailbox full` など	メールボックスの容量が足りない	ディスクと容量（手順5）

エラーメールが戻ってこない場合は、送信は成功していて受信側で迷惑メールとして振り分けられているか、送信側でまだ再送を待っている（相手のサーバーに一時的に接続できない）可能性があります。

2. MXレコードと向き先を確認する

送信側のサーバーは、宛先ドメインのMXレコードを調べて配送先を決めます。

dig +short example.com MX

10 mail.example.com. のように、優先度とホスト名が返れば登録されています。次に、そのホスト名のAレコードを確認します。

dig +short mail.example.com A

確認するポイントは次のとおりです。

MXの向き先のホスト名に、Aレコード（またはAAAAレコード）があること。MXにIPアドレスを直接書くことはできない
向き先のIPアドレスが、今メールを受け取っているサーバーのものであること。サーバーを移転したあとに古いアドレスのままになっていることがある
DNSをCloudflareで管理している場合、メールサーバーのAレコードのProxy statusがDNS only（グレーの雲）であること。Proxiedだと、Cloudflareのアドレスが返ってメールが届かない
ネームサーバーを変えた直後は、古いDNSの内容がキャッシュに残っていることがある。ドメインの権威サーバーに直接問い合わせて比べる

# 権威サーバーの名前を調べる
dig +short example.com NS

# 権威サーバーに直接問い合わせる（ns1.example.net は上の結果に置き換える）
dig +short example.com MX @ns1.example.net

3. ポート25に外から接続できるかを確認する

メールは、送信側のサーバーから受信側のサーバーのTCP 25番ポートに届きます。まず、受信側のサーバーでPostfixが25番で待ち受けているかを確認します。

sudo ss -ltnp | grep ':25 '
sudo systemctl status postfix

次に、別のネットワークのサーバー（別のVPSなど）から接続できるかを確かめます。家庭用の回線は、プロバイダーが外向きの25番への通信を止めていること（OP25B）が多いので、自宅のパソコンからの確認では判断できません。

nc -vz mail.example.com 25

接続できない場合は、次を確認します。

OSのファイアウォールで25番を許可しているか（sudo ufw status、sudo firewall-cmd --list-all など）
VPS会社の管理画面のファイアウォール（パケットフィルター）で25番を許可しているか
Postfixの inet_interfaces が loopback-only や localhost になっていないか

postconf inet_interfaces

外からのメールを受け取るサーバーなら、値は all にします。変更したら sudo systemctl restart postfix で反映します。

4. Postfixのログとキューを確認する

テストメールを送ってから、Postfixのログを見ます。ログの場所はディストリビューションによって違います。

# Debian / Ubuntu
sudo tail -n 100 /var/log/mail.log

# RHEL / AlmaLinux / Rocky Linux
sudo tail -n 100 /var/log/maillog

# ログファイルが無い場合（systemd-journald だけに記録している構成）
sudo journalctl -u postfix --since "30 min ago"

受信したメールの行には status= が付きます。

表示	意味
`status=sent`	ローカルのメールボックスや、次の配送先（Dovecotなど）に渡せた
`status=deferred`	一時的な理由で渡せず、キューで再送を待っている
`status=bounced`	渡せないことが確定し、送信元にエラーを返した
`NOQUEUE: reject:`	受け取る段階で拒否した（理由が続けて書かれている）

NOQUEUE: reject: ... Relay access denied が出る場合は、Postfixがそのドメインを自分宛てとして扱っていません。受け取るドメインの設定を確認します。

postconf myhostname mydestination virtual_mailbox_domains

Linuxのユーザーでメールを受け取る構成なら mydestination に、バーチャルドメインの構成なら virtual_mailbox_domains に、ドメインが入っている必要があります。User unknown が出る場合は、宛先のアドレスに対応するユーザーやバーチャルメールボックスが登録されているかを確認します。

キューに残っているメールは、次のコマンドで一覧できます。

sudo postqueue -p

Postfixの設定を変えたら、次のコマンドで設定の誤りを確認してから反映します。

sudo postfix check
sudo systemctl reload postfix

5. ディスクの空きとメールボックスの容量を確認する

ディスクがいっぱいだと、Postfixはメールを受け取れなくなります。

df -h
df -i

df -i は、ファイルの数（inode）の空きを表示します。Maildir形式はメール1通を1ファイルとして保存するので、容量に余裕があってもinodeが足りなくなることがあります。

DovecotのQuota（容量制限）を設定している場合は、ユーザーごとの使用量も確認します。

sudo doveadm quota get -u user@example.com

レンタルサーバーの場合は、管理画面でメールアカウントの容量の上限と使用量を確認します。

6. 受け取っているのに見えない場合

ログに status=sent が出ているのにメールソフトで見えない場合は、受信箱以外を確認します。

迷惑メールフォルダー（サーバー側のフィルターや、メールソフトの振り分け）
転送の設定（別のアドレスに転送したあと、元のメールを残さない設定になっていないか）
メールソフトがPOP3で受信し、サーバーからメールを削除していないか（別の端末で見えなくなる）

Dovecotのログで、メールソフトからのログインに失敗していないかも確認できます。

sudo journalctl -u dovecot --since "30 min ago"

WordPressのサーバーが自ドメイン宛てのメールを抱え込む問題

メールをGoogle Workspaceなど別のサービスで受け取っているのに、WordPressのお問い合わせフォームの通知だけが届かない、という場合があります。原因の一つは、WordPressが動いているサーバーのPostfixが、自分のドメインを「自分宛て」として扱っていることです。

mydestination に example.com が入っていると、そのサーバーから info@example.com 宛てに送ったメールは、MXレコードを見ずにサーバー内のメールボックスに配送されます。外部のメールサービスには届きません。

postconf mydestination

このサーバーでメールを受け取らないなら、/etc/postfix/main.cf の mydestination から自分のドメインを外し、$myhostname, localhost のようにサーバー自身の名前だけにします。変更後は sudo postfix check と sudo systemctl reload postfix を実行し、もう一度フォームから送って、ログに外部のメールサーバーへ渡した記録（relay= に Google などのサーバー名）が出るかを確認します。

レンタルサーバーでも、サーバー側のメール機能で同じドメインを使っていると同じことが起きます。管理画面で、そのドメインのメールを外部のサービスで受け取る設定があるかを確認してください。

WordPressからの送信そのものが失敗している場合（ログに送信の記録が無い、フォームでエラーになる）は、受信ではなく送信の問題です。SMTPプラグインで認証つきの送信に切り替える方法を確認してください。

まとめ

まず送信側のエラーメールを読み、エラーコードから調べる場所を決める
dig でMXレコードと、向き先のAレコードを確認する。CloudflareではメールサーバーをDNS onlyにする
別のネットワークから nc -vz mail.example.com 25 で接続できるかを確かめる
Postfixのログの status= と NOQUEUE: reject: を見て、mydestination や virtual_mailbox_domains を確認する
ディスクとinodeの空き、メールボックスの容量、迷惑メールフォルダーも確認する
WordPressのフォームの通知だけが届かないときは、Webサーバーの mydestination に自分のドメインが入っていないかを見る