「メールが届かない」という状況は、送信前・配送中・相手サーバー受理後のどこでも起こります。配送の遅れや拒否だけでなく、受信後に迷惑メールや別フォルダーへ移動する場合もあります。送信済みフォルダーへ入っているだけでは、相手の受信箱へ届いた証明になりません。

最初に問題の一通を特定し、配送経路に沿ってどこまで進んだかを確認します。同じメールを何度も再送するとログが増え、重複受信の原因にもなります。送信者・受信者・正確な時刻・Message-ID・返送通知を集めてから調査を始めます。

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

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

件名と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連携を使う場合は、認証アカウント・送信元・エラーログを確認し、秘密情報を画面へ表示しません。

再発防止では、フォーム受付をメール通知だけに依存しない運用を検討します。管理画面の受付一覧や定期確認があれば、一通の通知障害で問い合わせ自体を失いにくくなります。テスト送信日時と結果を運用記録へ残します。

解決後は原因と確認できた範囲を記録する

再テストでは、送信者と受信者の双方で結果を確認します。送信ログの受理だけで終えず、受信箱または意図した隔離先に一通だけ届いたことを見ます。添付やフォームなど問題になった条件も戻して確認します。

記録には、問題の一通・停止した段階・応答コード・変更した設定・テスト結果を残します。「DNSを直した」のような表現ではなく、対象レコードや認証結果を記載します。個人情報と本文は必要以上に複製せず、ログの保管期限へ従います。

未着はメール全体の設定を一度に変えると原因が分からなくなります。一通を特定し、送信受付から受信後の振り分けまで順に追えば、変更が必要な場所を限定できます。