【メール入門第11回】メールのトラブルシュート ― 「届かない」の切り分け手順、よくあるエラー、迷惑メールフォルダーの原因

seichan — Fri, 23 Oct 2026 09:00:00 +0000

「メールが届かないんですけど」

メールの問い合わせで一番多いのが、これです。でも「届かない」の中身は、エラーメールが返ってきた、何も返ってこない、迷惑メールフォルダーに入っていた、遅れて届いた……とさまざまです。

第11回では、第1回から第10回までの知識を使って、「届かない」を切り分ける手順と、よくあるエラーの読み方をまとめます。送った側から順にたどり、止まった場所を突き止めましょう。

「届かない」の切り分け
エラーは「どの段階で返ったか」で読む
よくあるエラー① 接続・認証・リレー
よくあるエラー② 送信ドメイン認証・送信者ガイドライン
vCenterの通知メールのエラー
迷惑メールフォルダーに入る原因
原因と確認コマンドの対応表
連載の早見表
1. 参考資料
考えてみよう
まとめ
連載「メール入門」全12回

「届かない」の切り分け

段階	確認すること	コマンド・画面の例	分かること
0 症状を固める	誰から誰へ、いつから、全員か一部か、バウンスの有無と文言	バウンス（NDR）の本文、受信者への聞き取り	送信側の問題か受信側の問題か
1 送信側のキュー・ログ	キューに残っていないか、ログの status=・dsn=	postqueue -p、grep キューID /var/log/maillog、Microsoft 365 は Get-MessageTraceV2	相手に渡せたか、どの応答で止まったか
2 DNS	宛先の MX、自社の SPF・DKIM・DMARC、送信 IP の PTR	dig MX・dig TXT・dig -x、Resolve-DnsName -Type MX／TXT／PTR	配送先の誤り、認証の設定の誤り
3 経路	ポートの疎通、STARTTLS と証明書、MTA-STS	nc -vz、openssl s_client -starttls smtp、Test-NetConnection -Port	ファイアウォールや25番の遮断、TLS の失敗
4 受信側	拒否の応答、迷惑メールフォルダー、隔離	相手の管理者へ時刻・キューID・Message-ID を伝えて調べてもらう	フィルター、評判、容量

バウンスがあれば、応答コードと拡張ステータスコード（第2回）で、どの段階で止まったかの見当が付く
バウンスが無いのに届かないときは、送信側のログで相手が250で受け付けたかを確かめる。受け付けていれば、そこから先は受信側の迷惑メールの判定や振り分けを疑う

ポイント
相手が250を返したかどうかで、調べる場所が送信側と受信側に分かれる。

エラーは「どの段階で返ったか」で読む

エラーの文言を1つずつ覚えるより、SMTPのどの段階で返ったかを見るほうが、原因の見当が早く付きます（SMTPの流れは第2回）。

Postfixのログなら、(in reply to RCPT TO command)や(in reply to end of DATA command)が段階を教えてくれます（第8回）。1桁目が4なら送信側が再送し、5なら直すまで届きません。

よくあるエラー① 接続・認証・リレー

応答の例	意味	よくある原因	対処
554 5.7.1 <宛先>: Relay access denied（550 を返すサーバーもある。Microsoft 365 は 550 5.7.64 TenantAttribution）	中継が許可されていない	機器の IP がリレーの許可に無い、宛先がそのサーバーの担当外	サーバー側で許可する（Postfix は mynetworks）。Microsoft 365 はコネクターの IP・証明書を直す
535 5.7.8（Microsoft 365 は 535 5.7.3、535 5.7.139）	認証の資格情報が無効	パスワードの誤り、SMTP AUTH の無効化、セキュリティの既定値や条件付きアクセスで Basic 認証を禁止	資格情報と SmtpClientAuthenticationDisabled を確認し、OAuth へ移す
530 5.7.0 Must issue a STARTTLS command first	STARTTLS が必須	機器の TLS の設定がオフ	STARTTLS を有効にする（TLS 1.2 以上）
554 5.7.1 Service unavailable; Client host [IP] blocked using …	送信 IP が DNSBL に載っている	送信 IP の評判、動的 IP の範囲からの直接送信	原因を止めてから各リストの解除手続きをする（第7回）
452 4.2.2／552 5.2.2	受信者のメールボックスが容量超過	相手の容量	相手に伝える。4xx なら送信側が再送する
Connection refused／タイムアウト	SMTP の前の TCP で失敗	サービスの停止、ポートの誤り、ファイアウォール、25番の遮断	nc -vz・Test-NetConnection で経路を確かめる（第9回）

拡張ステータスコード（RFC 3463、登録簿はRFC 5248）は、事業者が独自の番号を追加しているため、文言と各社の説明で確かめます。

よくあるエラー② 送信ドメイン認証・送信者ガイドライン

応答の例	返す相手	意味	対処
550 5.7.26	Gmail	認証されていないメールを、送信ドメインの DMARC ポリシーにより拒否	SPF か DKIM を From のドメインとそろえて合格させる
550 5.7.509	Microsoft 365（企業向け）	DMARC に不合格で、送信ドメインが p=reject	同上
550 5.7.515	Outlook.com（個人向け）	大量送信者の認証の要件を満たさない（SPF・DKIM・DMARC）	3つとも設定し、From とそろえる
421 4.7.27／4.7.30／4.7.32	Gmail	SPF・DKIM が不合格、または From が認証したドメインとそろわず、一時的に制限	放置すると 5xx の拒否に変わる。認証をそろえる
550 5.7.25／451 4.7.23	Gmail	送信 IP に PTR が無い、または PTR の正引きが送信 IP と一致しない	PTR と A をそろえる（第7回）
421 4.7.28	Gmail	送信の量や苦情が急に増え、一時的に制限	送信量を下げ、Postmaster Tools で迷惑メール率を確かめる
421 4.7.0 [TSS04] など	Yahoo	送信量や苦情により一時的に保留	送信量を下げ、Sender Hub の要件を確かめる

Gmailは2025年11月から、ガイドラインを満たさない大量送信（1日5,000通以上）への一時的・恒久的な拒否を強めています。Microsoft（Outlook.com）は2025年5月から、要件を満たさない大量送信を550 5.7.515で拒否しています。要件は第5回・第6回と、連載「DNS入門」第6回を参照してください。

4xxの一時的な制限を放置すると、5xxの拒否に変わることがあります。一時エラーのうちに直しましょう。

vCenterの通知メールのエラー

第10回で扱ったvCenterの通知メールは、届かないときの調べ方にも癖があります。

送信の流れは、vpxd（アラームのアクション）→ 内部のSendmail（127.0.0.1）→ 社内リレーまたはメールサーバー。アクションが動いたかは/var/log/vmware/vpxd/vpxd.log、Sendmailが送れたかは/var/log/vmware/messagesで見る
Sendmailは1通につきfrom=・STARTTLS=・to=の行を出す。relay=が外部のサーバーになっているto=の行のdsn=とstat=が本当の結果

（正常）  to=, … relay=mail.corp.example.jp. [192.0.2.25], dsn=2.0.0, stat=Sent (Ok: queued as 4cXyZ1abcd)
（一時）  to=, … dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
（拒否）  to=, … relay=mail.corp.example.jp. [192.0.2.25], dsn=5.7.1, stat=Service unavailable
（相手のPostfix）NOQUEUE: reject: RCPT from unknown[192.0.2.20]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo=
（OAuth が必要な相手）AUTH=client, available mechanisms=LOGIN do not fulfill requirements
（抜粋）

Deferredは再送されるが、5.x.xは再送されない
127.0.0.1へのConnection refusedは内部のSendmailの停止、リレー拒否はリレー側の許可の不足、最後の行は相手がBasic認証を受け付けない場合（Broadcom KB 428447）
vCenter自身から、ncかcurl -v telnet://宛先:25で試す（第9回）

時刻とキューIDで、vCenterとリレーの両側のログを突き合わせます。

迷惑メールフォルダーに入る原因

エラーは返らないのに「届いていない」と言われたら、迷惑メールフォルダーを疑います。

原因	見分け方（受信側のヘッダーなど）	対処
認証の失敗・From とのずれ	Authentication-Results の spf=・dkim=・dmarc=。Microsoft 365 は compauth=	送信 IP を SPF に入れ、DKIM で署名し、From とそろえる（第5回）
送信 IP・ドメインの評判	Microsoft 365 は X-Forefront-Antispam-Report の SCL、Gmail は Postmaster Tools	苦情を減らし、送信量を少しずつ増やす（第7回）
大量送信の作法の不足	List-Unsubscribe の有無、迷惑メールの報告率	ワンクリック登録解除（RFC 8058）を付け、2日以内に反映
逆引きが無い・一致しない	Received に unknown や一致しない名前	PTR と A をそろえる
本文・URL・添付	短縮 URL、他社ドメインのリンク、実行ファイルやマクロの添付	本文とリンクを見直す。ファイルは共有リンクで渡す
受信者側の設定	受信者の迷惑メールのルール、隔離のポリシー	「迷惑メールではない」と報告してもらう。許可リストは最後の手段

迷惑メールフォルダーへの振り分けは、相手が250で受け付けた後の判定です。送信側のログは正常に見えるので、受信者から届いたメールのヘッダーを送ってもらって読むのが近道です（ヘッダーの見方は第3回、Authentication-Resultsの読み方は第6回）。

原因と確認コマンドの対応表

原因	見える症状	確認コマンド（Linux ／ PowerShell）	参照
送信側で止まっている	キューに溜まる	postqueue -p、journalctl -u postfix ／ Get-MessageTraceV2（Microsoft 365）	第8回
MX の誤り・MX が無い	配送先が見つからない	dig MX 宛先ドメイン／ Resolve-DnsName 宛先ドメイン -Type MX	第1回、連載「DNS入門」第6回
SPF・DKIM・DMARC	5.7.26、5.7.509、迷惑メール	dig TXT _dmarc.example.jp、dig TXT s1._domainkey.example.jp ／ Resolve-DnsName _dmarc.example.jp -Type TXT	第5回・第6回
PTR が無い・一致しない	5.7.25、迷惑メール	dig -x 送信IP ／ Resolve-DnsName 送信IP	第7回
ポートの遮断	タイムアウト、Connection refused	nc -vz 相手 25 ／ Test-NetConnection 相手 -Port 25	第4回・第9回
TLS・証明書	530 5.7.0、TLS のエラー	openssl s_client -connect 相手:587 -starttls smtp ／ SslStream のスクリプト	第4回・第9回、連載「証明書入門」
DNSBL への掲載	554 5.7.1 … blocked using	dig 25.113.0.203.zen.spamhaus.org ／ Resolve-DnsName 25.113.0.203.zen.spamhaus.org	第7回
認証の失敗	535 5.7.8、535 5.7.3	第9回の手順で AUTH を試す／ (Get-CASMailbox 名前).SmtpClientAuthenticationDisabled	第4回・第10回

連載の早見表

困ったときに戻る場所を、連載全体でまとめておきます。

回	テーマ	押さえること	使う場面
第1回〜第2回	全体像、SMTP のやり取り	MUA・MSA・MTA・MDA、MX、4xx は再送・5xx は恒久、拡張ステータスコード	バウンスの読み方（第12回の問4）
第3回	メッセージの構造	エンベロープとヘッダー、Received を下から読む、MIME	ヘッダーの調査
第4回	ポートと暗号化・認証	25・587・465、STARTTLS の弱点と MTA-STS、OAuth 2.0	送信の設定、Basic 認証の廃止（問1）
第5回〜第6回	送信ドメイン認証	SPF・DKIM・DMARC と From とのアラインメント、送信者ガイドライン	DMARC の強化（問2）
第7回	迷惑メール対策と配信	PTR、DNSBL、ワンクリック登録解除、苦情率	大量送信（問3）
第8回〜第9回	MTA の運用、調べ方	オープンリレーの禁止、キューとログ、dig・openssl・Resolve-DnsName	すべての調査
第10回	クラウド	Microsoft 365 の4方式、SES、25番の制限、機器の通知	通知の経路（問1）、移行（問5）
第11回	トラブルシュート	送信側 → DNS → 経路 → 受信側の順、エラーの読み方	障害対応（問4）

どの回も、「いま見ているのはエンベロープかヘッダーか」「誰が誰に、どの経路で渡しているか」を意識すると理解しやすくなります。

参考資料

RFC：5321（SMTP）、5322（メッセージ形式）、5598（アーキテクチャ）、6409（サブミッション）、8314（465）、3207（STARTTLS）、4954（AUTH）、3463・5248・7372（拡張ステータスコード）、7208（SPF）、6376（DKIM）、9989・9990・9991（DMARC）、8617（ARC）、8461・8460（MTA-STS・TLS-RPT）、7672（DANE）、8058（ワンクリック登録解除）、6531（SMTPUTF8）
送信者ガイドライン：Gmailのメール送信者のガイドラインとFAQ、Yahoo Sender Hubのベストプラクティス、MicrosoftのOutlook.com大量送信者の要件（2025年）、M3AAWGのベストプラクティス、JPAAWGの資料
公式ドキュメント：Postfixのドキュメント（postfix.org）、Microsoft Learn（多機能デバイスやアプリからの送信、SMTP AUTH、High Volume Email、Exchange Onlineの制限、NDRの一覧）、Google Workspace管理者ヘルプ（SMTPリレー）、Amazon SES開発者ガイド、Broadcom TechDocs（vCenterのメール送信者の設定）とKB 428447

考えてみよう

「メールが届かない」という問い合わせを受けたら、最初に利用者から何を聞き取りますか。この記事の「0 症状を固める」を、自分の言葉で質問のリストにしてみましょう。
送信側のログはstatus=sentなのに、相手は「届いていない」と言います。次に何を確かめ、相手に何を頼みますか。
自社の送信サーバーのログに421 4.7.27が出始めました。放置するとどうなりますか。何から直しますか。

ヒント：この記事の切り分けの図、エラーの段階の図、迷惑メールフォルダーのヘッダーの図、「よくあるエラー②」の表が手がかりです。まずはdig TXT _dmarc.自社のドメイン（WindowsはResolve-DnsName _dmarc.自社のドメイン -Type TXT）を実行してみてください。

まとめ

「届かない」は、まず症状を固める。誰から誰へ、いつから、バウンスの文言
送信側のキュー・ログ → DNS → 経路 → 受信側の順にたどる。相手が250を返したかで分かれる
エラーはSMTPのどの段階で返ったかで読む。1桁目が4なら再送、5なら直すまで届かない
認証のエラー（5.7.26・5.7.509・5.7.515）はFromとそろえる。4xxの制限を放置しない
vCenterはrelay=の行のdsn=とstat=が本当の結果
迷惑メールフォルダーは250の後の判定。受信者からヘッダーを送ってもらう

次回はいよいよ最終回。これまでの知識を使って、メールの経路・認証・移行を要件から決める設計演習に取り組みます。

迷惑メール | 徒然なるままに

【メール入門 第11回】メールのトラブルシュート ― 「届かない」の切り分け手順、よくあるエラー、迷惑メールフォルダーの原因