「メールが届かないんですけど」
メールの問い合わせで一番多いのが、これです。でも「届かない」の中身は、エラーメールが返ってきた、何も返ってこない、迷惑メールフォルダーに入っていた、遅れて届いた……とさまざまです。
第11回では、第1回から第10回までの知識を使って、「届かない」を切り分ける手順と、よくあるエラーの読み方をまとめます。送った側から順にたどり、止まった場所を突き止めましょう。
「届かない」の切り分け
| 段階 | 確認すること | コマンド・画面の例 | 分かること |
|---|---|---|---|
| 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=<ops@corp.example.jp>, … relay=mail.corp.example.jp. [192.0.2.25], dsn=2.0.0, stat=Sent (Ok: queued as 4cXyZ1abcd)
（一時） to=<ops@corp.example.jp>, … dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
（拒否） to=<ops@example.com>, … 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 <ops@example.com>: Relay access denied; from=<vcsa-alert@corp.example.jp> to=<ops@example.com> proto=ESMTP helo=<vcsa01.corp.example.jp>
（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の後の判定。受信者からヘッダーを送ってもらう
次回はいよいよ最終回。これまでの知識を使って、メールの経路・認証・移行を要件から決める設計演習に取り組みます。
連載「メール入門」全12回
- メールが届くまで
- SMTPのやり取り
- メッセージの構造
- ポートと暗号化・認証
- 送信ドメイン認証 前編
- 送信ドメイン認証 後編
- 迷惑メール対策と配信
- MTAの運用
- コマンドで調べる
- クラウドと現代のメール
- メールのトラブルシュート（この記事）
- メールの設計演習
コメント