メールが届かない・迷惑メールに入るときの切り分け方

メールが届かないときは、宛先の誤り、返送エラー、迷惑メール・隔離、メールボックス容量が最初の確認点です。送信済みフォルダーにあるだけでは、相手の受信箱へ届いたとは限りません。

エラーが返っているなら、その説明が原因の手掛かりになります。返っていない場合は、受信側の振り分けや配送の遅れも考えられます。同じメールを何度も再送するより、対象の一通と送信時刻を絞って調べる方法が有効です。

症状から確認する場所を絞る

一人にだけ届かない場合と、誰にも届かない場合では、疑う場所が異なります。代表的な症状と確認先をまとめます。

どれも確定診断ではありませんが、最初に見る範囲を絞れます。

問題の一通を特定できる情報

送信者と受信者の完全なメールアドレスを確認します。表示名だけでは同姓の別アドレスやエイリアスを区別できません。送信時刻は分単位で記録し、端末とサーバーのタイムゾーンが違う場合に備えて「日本時間」など基準も添えます。

件名とMessage-IDも重要です。Message-IDはメッセージを識別するヘッダーで、送信ログと受信ログの照合に使える場合があります。受信者から転送されたコピーではヘッダーが追加されるため、可能なら「原文を表示」などの機能で元のヘッダーを保存します。

送信者へエラーメールが返っている場合は、件名だけでなく全文を保全します。宛先・Status・Diagnostic-Codeなどに停止理由が含まれます。配送状態通知のRFCでも、失敗・遅延・配送などの状態と診断情報を受信者単位で表す形式が定義されています。

返送エラーは4xxと5xxを分けて読む

SMTPの応答コードは、先頭の数字で大きな状態を分けられます。2xxは要求を受け付けた状態、4xxは再試行できる一時的な失敗、5xxは同じ条件で再試行しても成功しない恒久的な失敗です。後ろに続く拡張コードと説明文も合わせて読みます。

4xxには、相手サーバーの一時停止・受信量制限・DNSの一時障害などが含まれます。送信サーバーが自動で再試行するため、利用者が同じ内容を繰り返し送らない方がよい場合があります。どのくらい再試行するかは送信サービスの仕様を確認します。

5xxには、宛先不存在・方針による拒否・認証不備などがあります。アドレスを確認せず再送しても改善しません。SMTPのRFCでは、DATA後の2xxを返したサーバーが配送責任を引き受けますが、これは利用者が受信箱で読んだことまでは示しません。

送信側から受信側へ経路を順番に追う

まず送信サービスのログで、問題の一通を受け付けたかを確認します。ログにない場合は、メールソフトが送信できていない可能性があります。別のSMTPサーバーを使っている場合や、Webフォーム内部で止まった場合もあります。送信済み表示だけで次の段階へ進みません。

送信ログに相手サーバーの応答があれば、受理・一時失敗・恒久失敗を分けます。相手サーバーが2xxで受理した記録がある場合は、受信側の管理者へ時刻・送信者・受信者・Message-IDを伝えます。送信側だけで受信後の振り分けを確認することはできません。

受信側では、配送ログ・管理者隔離・迷惑メール・受信ルール・転送先・メールボックス容量を確認します。Google Workspaceではメールログ検索の公式手順のように、管理ログから配送と配送後の状態を追える機能があります。利用サービスが持つ同等機能と保存期間を確認します。

切り分けは一つの条件だけ変えて試す

調査の基本順は次のとおりです。

1. 送受信者、時刻、件名、Message-ID、返送通知を集める
2. 送信サービスが一通を受け付けたかログで確認する
3. 相手サーバーの応答コードと診断文を確認する
4. 受信側ログ、隔離、迷惑メール、受信ルールを確認する
5. SPF・DKIM・DMARCと送信元の評判を原本ヘッダーで確認する
6. 原因候補を一つ修正し、件名を変えた一通で再テストする

同じ会社の一人だけ届かないなら、個人のルールやアドレス誤りを優先して見ます。社内全員へ届かないなら、受信側のドメイン設定や組織ポリシーが候補です。複数の異なる受信サービスへ届かない場合は、送信側認証や送信元の問題を調べます。

本文と添付を外したテストで届くなら、内容やファイル形式の影響を切り分けられます。ただし、業務上必要な添付を恒久的に外すことが解決とは限りません。受信側の制限と安全な共有方法を確認します。

迷惑メールに入った場合は原本の認証結果を見る

受信済みで迷惑メールへ入った場合は、配送経路の停止ではなく受信後の判定です。原本ヘッダーからSPF・DKIM・DMARCの結果と、認証されたドメインが表示上のFromドメインと整合するかを見ます。転送メールではSPFなどの結果が変わることがあるため、最初の受信者側の原本を確認します。

認証が失敗していれば、まずそのメールを実際に送ったサービスの設定を確認します。メールサービスだけでなく、Webフォーム・複合機・請求サービス・メール配信も同じドメインで送信する場合があります。受信側へ許可を頼む前に、正規送信が認証される状態へ直します。

認証が成功していても、送信量・受信者の報告・本文やリンクなどで迷惑メールと判断されることがあります。原因は一つとは限りません。受信側フィルタの調整方法は迷惑メールフィルタの仕組みと業務メールでの設定ポイントで分けて説明しています。

Webフォームの未着は受付とメール配送を分ける

問い合わせフォームで完了画面が出ても、担当者への通知メールが届いた証明にはなりません。WordPressが入力を受け付けた段階と、メールサーバーへ渡した段階、相手サーバーが受理した段階を分けます。フォーム内に受付記録が残るなら、最初にデータが保存されているかを確認します。

WebサーバーのPHPから直接送る構成では、通常の社内メールと送信経路が違う場合があります。SPFやDKIMの対象に入っていないこともあります。SMTP連携を使う場合は、認証アカウント・送信元・エラーログを確認し、秘密情報を画面へ表示しません。

再発防止では、フォーム受付をメール通知だけに依存しない運用を検討します。管理画面の受付一覧や定期確認があれば、一通の通知障害で問い合わせ自体を失いにくくなります。保存する場合は、問い合わせ内容を閲覧できる人と保管期間にも配慮します。

テストで届いた後にも確認したいこと

短い本文なら届いたが、通常の添付付きでは届かない場合は、まだ元の問題が解消していません。問題になった形式でも送受信できるかを確認します。ただし、危険な添付や本物の顧客情報をテストのために広く送ることは避けます。

設定を一度に変えると、何が原因だったか分からなくなります。宛先、送信受付、相手側の受理、受信後の振り分けに分ければ、自分で確認できる範囲と、メール管理者へ相談する範囲も見えやすくなります。