死活監視でWebサイトの異常が記録されているのに、通知メールが届かない場合は、①メール通知機能が提供・有効化されているか、②アラートが成立したか、③送信処理が実行されたか、④メールサーバー間の配送が成功したか、⑤受信側で振り分け・拒否されていないかの順で確認します。最初から迷惑メールフォルダーやDNS設定だけを調べても、そもそも送信されていないメールは見つかりません。
特に「監視画面に異常がある」ことと「通知メールが送信された」ことは別です。メール送信に対応していない監視サービスや、メール通知が無効のプランでは、異常を検知してもメールは届きません。また、送信サービスが「送信受付済み」と表示しても、受信者の受信トレイに入った証明にはなりません。
この記事では、通知メールの未着を原因別に切り分けるフロー、受信側・送信側の確認手順、SMTP・メールAPIの送信結果の読み方、SPF・DKIM・DMARCの確認ポイント、サービス管理者へ渡す調査記録を解説します。対象は、メール通知に対応した一般的な死活監視サービスを利用している担当者です。アラートの重大度や担当者への連絡順を決める話はWebサイト監視のアラート設計で扱い、本記事では送られるはずの通知メールが届かない原因調査に限定します。
エンリンクをご利用の場合：2026年10月24日時点の公式機能一覧では、障害・復旧・SSL期限などの管理画面内アラートと既読・未読管理が案内されています。障害通知メールの自動配信機能は公開説明から確認できません。エンリンクの管理画面内アラートが表示されることと、メールが配信されることを混同しないでください。
通知メールが届かないときに最初に見る5つの確認先
未着調査は「何が起きたか」を時系列に沿って追うと効率的です。どこまで事実が確認できたかで、次に見る管理画面やログが変わります。最初の確認先は、通知サービスの提供機能・監視結果・送信記録・配送記録・受信先の順です。
1．利用中の監視サービスは通知メールに対応しているか
監視サービスには、管理画面内だけで知らせるもの、メールやチャットへの外部通知に対応するもの、上位プランでのみ使えるものがあります。まず公式の機能一覧・契約プラン・管理画面の通知設定を確認し、メール配信が提供中で、有効になっていることを確かめます。
プランを変更した直後や無料プランへ戻した後は、外部通知の対応範囲が変わっていないかも確認します。外部通知機能そのものが存在しなければ、迷惑メール設定を変えても解決しません。メール配信の有無は推測せず、現行の公式説明と実際の管理画面で照合してください。
2．その異常で通知対象のイベントが成立したか
監視履歴に一回の失敗が残っていても、「連続失敗が一定回数に達したら障害イベントを作る」方式では、通知対象となるイベントが成立していない場合があります。反対に、障害イベントは作られたものの、通知を送信しない条件や一時停止が設定されていることもあります。
まず対象URL・チェック時刻・失敗回数・障害イベントの有無を照合してください。単発失敗と連続失敗の違いは別記事で説明しています。本記事では判定ルールを作り直すのではなく、今回の未着事象が「通知すべきイベントだったか」を確認することが目的です。
3．送信処理が開始され、メールサービスへ渡されたか
通知イベントがあっても、アプリケーションからの送信処理が実行されていなければメールは届きません。メール通知に対応するシステムでは、送信ジョブ・キュー・SMTP接続・メールAPIのリクエスト結果などを確認することがあります。これはシステム管理者やサービス提供元が確認する範囲です。
送信ログが存在しない場合、通知設定の不備だけでなく、ジョブの停止や実行失敗、メールサービスへの接続失敗などが候補になります。一方、ログに「受付成功」と記録されている場合は、その次の配送段階を確認します。送信処理の起動と最終的な受信は別の事実です。
4．メールが配信されたか、遅延・拒否されていないか
メール送信サービスが使われているなら、該当する時刻・受信アドレス・メッセージIDで配送状況を調べます。一般的に、送信受付、配送完了、配信遅延、バウンス、苦情、送信抑制などの状態があります。たとえばAmazon SESはイベント発行によって配信やバウンス、遅延などを確認できると説明しています。
配送ログが「Delivery」でも、受信者の受信トレイへ必ず表示されたことまでは示しません。受信サーバーがメールを受け付けた後に、迷惑メールや隔離フォルダーへ振り分ける場合もあります。配送結果の意味を確認し、次に受信側の保管場所や管理ルールを調べます。
5．受信側のすべての保管先と管理ルールを確認する
受信者は受信トレイだけでなく、迷惑メール、すべてのメール、アーカイブ、ゴミ箱、隔離フォルダー、転送先などを確認します。自動振り分けルールや共有メールボックス、グループアドレスでの配送も見落としやすい場所です。
会社のGoogle WorkspaceやMicrosoft 365を利用している場合は、権限を持つ管理者がメールログ検索やメッセージ追跡を使って状態を確認できます。一般利用者が管理ログを閲覧できるとは限らないため、必要な時刻・送信元・宛先を揃えて管理者に調査を依頼します。
未着原因別の切り分けフローを順番に確認する
以下の流れは、メール通知に対応した監視サービスを前提とした一般的なトラブルシューティング例です。特定の製品の画面構成を再現したものではありません。確認できた事実に応じて次の段階へ進み、憶測で設定を変更しないことが大切です。
最初の分岐：メール通知の機能と対象イベントがあるか
まず、そのサービスでメール通知機能が使えるか、現在の契約で有効かを調べます。対応していなければ「メールが届かない障害」ではなく、送信機能がない状態です。対応している場合は、監視履歴にアラート条件に一致するイベントがあったかを確認してください。
イベントがない場合には、監視がその時間帯に実行されたか、失敗判定が成立したかを記録します。この時点でメール配送のSPFや迷惑メールを調べても原因には近づけません。まず通知処理が発生する条件を満たしたことを確かめます。
次の分岐：送信ログに該当メールがあるか
送信対象イベントが記録されているなら、メール送信ログに対応する記録があるか調べます。管理画面で「通知済み」とだけ表示される場合は、その表記が送信予約済み・SMTP/API受付済み・最終配送済みのどこを意味するか確認します。
該当ログがなければ、配信先設定・通知抑止・メールジョブ・サービス提供元の障害などを調べる段階です。ログがある場合は、メールサービス側のメッセージIDと処理結果を追います。送信先を含めた情報の閲覧には適切な管理権限が必要です。
第三の分岐：配信結果が成功・保留・失敗のどれか
配送完了なら受信側のフィルター、隔離、転送、削除などを確認します。配信保留なら一時的な受信サーバーの拒否や遅延、再試行の状態を調べます。恒久的な失敗なら、宛先不存在・認証エラー・ポリシー違反など、返された具体的な理由を確認してください。
Amazon SESのイベントでは、送信受付後のDelivery、Bounce、DeliveryDelayなどを区別します。Microsoft 365ではメッセージ追跡にDelivered、Failed、Pendingなどの状態があり、隔離・ルールによる処理を追えます。同じ「送信済み」表示でも製品によって意味が異なるため、各サービスの公式資料で確認することが重要です。
最後の分岐：受信側が受け付けた後に何が起きたか
受信サーバーが受け付けたことを確認できた場合でも、利用者がメールを見つけられないことがあります。迷惑メールへの振り分け、自動削除、隔離、別アドレスへの転送、グループのメンバー設定などを調べます。
Google Workspaceの公式メールログ検索では、送信者・受信者・時刻・メッセージIDを指定して検索し、配送後に付与されたラベルや保管場所、迷惑メール判定、削除の有無などを確認できる範囲があります。ただし個人用Gmailと管理者向けGoogle Workspaceでは使える機能が異なります。受信側の調査で行き詰まったら、組織のメール管理者に確認を依頼してください。
通知メールが届かない原因を7種類に分類する
未着原因は大きく「送る設定になっていない」「送信処理が失敗した」「配送途中で止まった」「受信側で見えなくなった」に分けられます。原因がどの段階にあるかに応じ、確認する担当者やログも変わります。下表は一般的な原因分類の例です。
| 原因の分類 | 代表的な症状 | 最初に確認する場所 | 担当の目安 |
|---|---|---|---|
| メール通知機能がない・利用不可 | 画面内のアラートはあるがメールが来ない | 公式機能一覧・契約プラン | 利用者・サービス提供元 |
| 通知対象イベントが未成立 | 単発失敗はあるが通知記録なし | 監視履歴・通知イベント履歴 | 監視サービスの管理者 |
| 宛先間違い・通知停止 | 担当者変更後から届かない | 通知先設定・停止状態 | 監視サービスの管理者 |
| 送信ジョブ・SMTP/API失敗 | イベントはあるが送信記録がない | ジョブ・アプリケーション・送信APIログ | サービス提供元・開発担当 |
| バウンス・送信抑制・遅延 | 送信履歴あり、配信失敗または保留 | メール配送サービスのイベント | 送信ドメインの管理者 |
| 認証・受信ポリシーで拒否 | 受信先ドメインだけ未着 | 拒否理由・SPF/DKIM/DMARC・受信ルール | 送信者と受信側管理者 |
| 迷惑メール・隔離・転送 | 配送完了なのに受信トレイに見えない | 全フォルダー・隔離・メールログ | 受信者・組織のメール管理者 |
宛先アドレスの間違い・変更は最初に除外する
管理担当者のメールアドレスが変わった、別の部署の共通アドレスを登録した、ドメイン名が古いといった問題は、送信サービスが正常でも起こります。実際に送信対象として記録されたアドレスと、いま受信トレイを確認しているアドレスを一致させてください。
宛先を変更しただけでは、過去のアラートメールが新しいアドレスへ再送されるとは限りません。変更日と発生時刻を照合し、どの宛先へ送る設定だったかを確認します。共有メールボックスの転送ルールや、グループのメンバー変更も見落とさないようにしましょう。
一時的な遅延は受信者側の問題とは限らない
受信側が一時的にメールを受け付けない、送信サービスが再試行している、メールを送るためのキューで処理待ちになっているなど、複数の段階で遅延が発生する場合があります。現時点で届いていなくても、後から到着する可能性があります。
メールAPIが成功を返していても、実際の配送が完了していなければ、送信成功と断定しないでください。遅延・再試行が長引く場合は、サービスの配送イベントと受信サーバーの応答理由を照合します。監視対象サイトが復旧していても、配信キューが残っていることがあります。
一人だけ届かない場合と全員届かない場合を分ける
同じ通知イベントで複数の宛先が設定されている場合、一人だけ未着なら宛先・個別フィルター・受信容量・アカウント状態を重点的に調べます。すべての宛先で届かないなら、通知機能の利用可否、イベント生成、共通の送信処理などを先に確認します。
ただし全員が同じ会社のドメインを使っている場合、そのドメインの受信ルールだけが影響することもあります。単に「何人に届いたか」ではなく、届かない宛先のドメインや共通点を整理すると切り分けが進みます。
迷惑メール・隔離・転送を受信者側で確認する方法
配送ログが受信側への到達を示している場合は、受信トレイ以外の場所を確認します。GmailとMicrosoft 365では管理者が追える情報が異なりますが、まず受信者自身が検索・振り分けを確認し、必要な場合に管理者が配送記録を確認する順番は共通です。
Gmailでは迷惑メールだけでなく全メールを探す
Gmail利用者は、通知メールの送信元・件名・発生日時を手掛かりに検索します。迷惑メールやゴミ箱も含めて確認し、受信トレイ以外にあるメッセージを見落としていないか確かめます。自動フィルターでアーカイブや転送を行っていないかも確認してください。
メール検索で見つかった場合、どのラベルや保管場所にあるかを見ると、受信はしたが見つけられなかった問題だと分かります。一方、検索しても存在しない場合は「受信していない」と直ちに断定せず、送信元と受信先の管理ログで配送状況を調べます。Google Workspace管理者向けのメールログ検索の公式資料が参考になります。
Google Workspaceでは管理者がメールログ検索を使う
会社のGoogle Workspaceを利用している場合、必要な管理権限があれば管理コンソールのレポートからメールログ検索（Email Log Search）を利用できます。送信者、受信者、時刻、件名またはMessage-IDなどを絞り込み、該当メッセージの配信記録を確認します。
Googleの公式資料では、メールログ検索により配送状況に加えて配送後の保管場所や迷惑メール・削除の扱いを確認できる範囲が説明されています。ただし利用できる機能や調べられる期間には制限があり、通常の個人用Gmailアカウントに同じ管理機能があるわけではありません。受信トレイにないことと、Googleの受信基盤に届いていないことは別です。
Microsoft 365ではExchangeのメッセージ追跡を確認する
Microsoft 365のExchange Onlineでは、権限のある管理者がExchange管理センターのメッセージ追跡を使い、送信者・受信者・期間などの条件からメールを探せます。Microsoftの公式FAQでも、未着の原因として隔離、拒否、配送保留、ルールによる振り分け、未送信などが挙げられています。
追跡の状態がDeliveredでも、迷惑メールフォルダーや隔離の確認が必要な場合があります。Failedなら拒否理由、Pendingなら再試行や処理待ちの詳細を確認します。Exchange Onlineのメッセージ追跡FAQを参照してください。
グループ宛て・共有アドレスはメンバーへの到達を確認する
部署の共有アドレスや配布グループへ送っている場合、グループがメールを受け付けたことと、担当者の個人メールボックスに届いたことは同じではありません。メンバーから除外された、承認待ちになった、転送先が停止したといった可能性があります。
まず通知サービスに設定された宛先がグループか個人か確認し、管理権限のある担当者に配布先・転送・メンバーシップの状態を調べてもらいます。グループ内の個人アドレスを記事や公開フォーラムへ無断掲載しないようにしてください。
送信ログで確認するステータスと「配信完了」の意味
送信者側の管理権限がある場合、送信アプリのログ、SMTPサーバーの応答、メール配信サービスのイベントを照合します。「送信したつもり」「APIに受け付けられた」「受信サーバーが受け付けた」「受信トレイで読める」はそれぞれ別の段階です。
| 送信・配送状態の例 | 確認できる内容 | まだ分からないこと |
|---|---|---|
| 通知イベントあり | システムが通知対象を記録した | 送信処理が実行されたか |
| メール送信処理開始 | アプリが送信を試みた | 送信サービスが受付したか |
| SMTP/API受付成功 | 送信サービスが要求を受け付けた | 受信サーバーへの配送完了 |
| Delivery・配信済み | 指定の配送処理が成功した | 受信トレイで表示・閲読されたか |
| DeliveryDelay・Pending | 配送が遅れている・再試行中の可能性 | 最終的に届くか |
| Bounce・Failed | 配送が失敗した記録がある | 具体的な原因は詳細の応答で確認 |
| Suppressed・送信抑制 | その宛先への送信を抑えた可能性 | 元のバウンスや苦情の詳細 |
| 隔離・迷惑メール | 受信側のポリシーで振り分けられた | 利用者が受信トレイで気づいたか |
SMTPで受け付けたことと受信者へ届いたことは別
SMTPで送信サーバーが要求を受理しても、その先の相手サーバーへ配送できないことがあります。後からバウンスが返る、次の配送先で拒否される、転送先でエラーになるなど、配送の経路は複数段階です。送信アプリが返した「成功」だけで受信完了としないようにします。
またAPIを使うメールサービスでも、APIリクエストの受付と配送結果は別の情報として扱われる場合があります。メールプロバイダーの配送イベントが利用できるなら、そのメッセージIDを使って後続の状態を追います。
Amazon SESのDelivery・Bounce・DeliveryDelayを区別する
Amazon SESの公式ドキュメントでは、イベント発行で送信・配送・バウンス・苦情・遅延などを確認できると説明されています。Deliveryは受信側のメールサーバーへの配送を示し、Bounceは配送失敗、DeliveryDelayは一時的な理由による配送遅延を示します。
SESなどの配信サービスが使われている場合は、該当するメッセージID、宛先、時刻、イベント種別を確認します。送信抑制リストに宛先が含まれる場合、配信が実行されないこともあります。ただしAmazon SESは一般的なサービス例であり、エンリンクが障害通知メールにSESを使っていると示すものではありません。SESのイベント監視公式資料を参照してください。
バウンス後の送信抑制は原因を確認してから解除する
配送先が存在しないなどの恒久的な失敗や、迷惑メールの苦情が出た場合、配信サービス側でそのアドレスが送信抑制リストへ追加されることがあります。以後の通知イベントが正しく生成されても、当該宛先への配送が試みられない状態が起こり得ます。
Amazon SESのアカウントレベルのサプレッションリストでは、バウンスや苦情を理由に受信アドレスが登録される仕組みがあります。該当する場合は、元の失敗理由を解決してから扱いを見直してください。原因未解決のまま無制限に再送したり、抑制を一括解除したりすることは避けます。
メールのMessage-IDと送信APIのIDを混同しない
配信トラブルの調査では、アプリが発行した通知ID、メール送信サービスが返すメッセージID、メールヘッダーのMessage-IDなどが登場します。これらは同じ文字列とは限りません。システム側でどのIDがどの配送イベントへ紐づくか確認する必要があります。
受信側管理者へ調査を依頼するなら、送信先アドレス、送信元アドレス、発生時刻、件名、分かる場合のメールMessage-IDを伝えます。トークンやAPIキー、SMTPパスワードを引継ぎ資料や問い合わせメールへ記載しないでください。
SPF・DKIM・DMARCによる拒否を調べるときの注意点
送信されたメールが迷惑メール判定や受信拒否の対象となった場合は、送信元ドメインの認証状態を確認します。ただし、すべての未着がSPF・DKIM・DMARCの問題というわけではありません。まず配信記録に認証失敗やポリシー拒否を示す証拠があるか確認してください。
SPFは送信を許可されたサーバーを示す
SPFは、送信に使うドメインからメールを出してよいサーバーをDNSで示す認証の仕組みです。メール送信サービスを変更したのに、送信に関係するSPF設定が適切でない場合、受信側の判定へ影響する可能性があります。
ただし、受信する側のMXレコードを変更すれば送信メールの認証問題が直るわけではありません。SPFとMXは用途が違います。またサードパーティーのメール配信では、実際に使われるエンベロープ送信元などが関わるため、公開DNSだけを見て安易に推測しないことが重要です。
DKIMはメールの電子署名を検証する
DKIMは送信メールに付けられた署名を、受信側がDNSの公開情報などを用いて検証する仕組みです。メール送信サービスの変更や署名設定の不備によって、意図した認証結果にならない場合があります。実際に届いたメッセージの認証結果や送信サービスの設定画面で確認します。
DKIMが設定済みでも、そのメールが想定したドメインで署名されているか、受信側でpassとなっているかは別に確認する必要があります。ドメイン管理者に無断でDNSレコードを削除・変更すると、別の正規メールまで届かなくなる恐れがあります。
DMARCはFromドメインと認証結果の整合性を見る
DMARCは、SPFまたはDKIMの認証結果と、受信者が見るFromドメインとの整合性などをもとに処理方針を示す仕組みです。DMARCの判定が不合格となり、送信元ドメインのポリシーが拒否を指示している場合、受信側の対応によってメールが受け取られないことがあります。
Googleのメール送信者のガイドラインでも、SPF・DKIM・DMARCの認証と送信者ドメインの整合性が説明されています。ただし受信先や送信量などの条件で要件は異なるため、常に三つすべてがないと一通も届かない、といった断定は避けてください。
DNSを変更する前に拒否コードと送信元を照合する
まず送信先で拒否された理由、SMTPのエラー内容、実際の送信元ドメインと送信サービス、DNSの認証設定を確認します。例えばGoogleのガイドラインでは、認証されていないメールが拒否や迷惑メールへの振り分けの対象になる場合があると説明しています。
しかしSPF・DKIM・DMARCを設定するにはDNSの変更権限と影響範囲の理解が必要です。原因が確認できない段階でTXTレコードを削除・追加しないようにしてください。監視サービスが管理する送信元ドメインについては、利用者側が変更できない場合があるため、提供元の公式対応を確認します。
症状別に変わる確認順序と原因の絞り方
未着の原因は、いつから・誰に・どのイベントで発生しているかによって絞りやすくなります。現象を分類してからログを探すと、不要なDNS変更や一斉再送を避けられます。
昨日までは届いていたのに今日から届かない
最後に届いたメールの時刻と、最初に届かなくなった時刻を整理します。その間に通知設定・受信アドレス・メール送信サービス・DNS・受信ポリシーが変更されていないかを確認します。サービス側で障害情報が公表されている場合は、その影響範囲と発生時刻を照合してください。
ただし直前に変更があったことだけでは、それが原因とは確定できません。ログに拒否や送信失敗の理由が残っているかを確認し、確かめられた事実から調査を進めます。
特定の担当者だけ届かない
同じ通知が別の担当者には届いているなら、受信側の自動振り分け、迷惑メール、共有メールボックスの設定、宛先誤り、受信アカウントの状態を優先して調べます。送信サービス側で個別の受信アドレスが抑制対象となっていないかも確認します。
一方、同じ会社ドメインの担当者だけ全員届かないなら、組織共通のセキュリティポリシーやドメイン単位のフィルターが関係する可能性があります。個人側で問題が再現しないだけで、送信側が完全に正常とは断定しないことも重要です。
障害メールだけ届かず、復旧メールは届く
通知のイベント種別ごとに送信処理が異なるサービスなら、障害イベントと復旧イベントの設定や発生条件が異なる可能性があります。まず本当に障害イベントが成立したか、そのイベントに対応する送信ログがあるかを確認します。
反対に、障害メールと復旧メールの両方が送信されたことが確認できるなら、受信側で件名や本文条件によって異なるルールが適用されていないか調べます。通知種類別の設定方法そのものはサービスによって異なるため、未提供の機能があることを前提にしないようにします。
遅れて届くが、異常発生時には届かない
通知が数十分後などに到着する場合、アラートイベント生成までの時間、送信キューの待機、メール配送の再試行、受信側の処理遅延のどこで時間が経過したかを分けて確認します。時刻が一つしか分からないと、どの段階で遅れたか特定できません。
発生時刻・通知イベント時刻・送信受付時刻・配信済み時刻・実際に確認した時刻を、同じタイムゾーンで並べます。監視間隔や連続失敗判定がある場合、チェックした瞬間にメールが送られる仕組みではない可能性もあります。これは通知ルールを推奨する話ではなく、既に発生した遅延の位置を特定するための確認です。
メールが届かないのに監視画面では「既読」になっている
管理画面の既読・未読は、管理画面内のお知らせを見たことや表示状態を管理する機能であり、メールの配送状態と一致するとは限りません。管理画面にアラートが表示されたこと、既読にしたこと、メールの送信・受信が完了したことは別です。
外部メール通知が存在するサービスなら配送ログを調べます。管理画面内の通知のみを提供するサービスなら、そもそもメール配信を行う機能があるかを確認する必要があります。既読表示を「メール配信済み」の証拠として扱わないことが重要です。
メールを送らずにできる未着調査の実務手順
未着調査を始める際、最初にテストメールを送信する必要はありません。まず利用者が確認できる監視履歴と受信フォルダーを調べ、管理者が送信・配送ログを照合します。実際に送信テストが必要な場合でも、担当者の権限と承認を得てから実施します。
手順1：対象URL・監視時刻・通知種類を確定する
どのURLに、いつ、どのような異常が記録されたかを確認します。例えば「2026年10月24日 09:15 JST、企業サイトのトップページがHTTP 503、継続失敗により障害イベントが記録された」といった形でまとめます。これは説明用の架空例です。
日時をUTCとJSTで混同せず、監視チェックの時刻と障害イベントの記録時刻も区別します。HTTPの一回の失敗だけでメール通知が出る設定ではない場合、未着の調査対象そのものが成立していないことがあります。
手順2：通知先アドレスと受信側の保管場所を確認する
通知先として登録されていたメールアドレスを確認し、現在使っている受信者のアドレスと一致するか調べます。受信者は迷惑メール・アーカイブ・ゴミ箱・転送先などを探し、送信元や件名、日時で検索します。
管理者権限がない場合、必要以上に他人のメールボックスを開いたり、受信ルールを変更したりする必要はありません。受信者本人または権限のあるメール管理者に確認を依頼します。見つからなかった時も、調べた範囲を記録してください。
手順3：送信処理と配信ステータスを照合する
メール送信に対応するサービスなら、提供元の送信ログや配送サービスのイベントで該当するメッセージを探します。通知イベントのIDとメール配送のメッセージIDが紐づいているか、受付成功・保留・失敗・配送完了のどの状態か確認します。
ログを閲覧できない利用者は、送信元アドレス、宛先、発生時刻、対象URL、通知の種類を整理して公式サポートへ調査を依頼する形が適切です。パスワード、メールAPIキー、認証トークンは提供しないでください。メッセージ本文に個人情報が含まれる場合は必要な部分のみ共有します。
手順4：拒否理由があれば認証・ポリシーの確認へ進む
配信が拒否された記録があれば、SMTPのエラーコードや配送サービスが記録した理由を確認します。宛先不存在や容量不足であれば受信先の状況、認証不一致であればSPF・DKIM・DMARC、組織ポリシーの拒否であれば管理者のルールを調べます。
拒否理由が不明なのにDNSを一括変更したり、迷惑メール対策を無効化したりしないようにします。自分が管理していない送信ドメインの場合は、受信側から送信者へ必要なエラー情報を共有し、正当な管理者が確認することが必要です。
手順5：必要な場合だけ承認されたテストを行う
ログだけでは原因を特定できず、再現試験が必要な場合は、まずテストを実施してよい権限と範囲を確認します。監視サービスが公式にテスト通知機能を提供するなら、その手順に従います。テスト用宛先や件名を決め、本番の障害通知と混同しない形で結果を記録します。
テスト通知機能がないサービスに対し、架空の障害を作るために本番サイトを停止させることは避けましょう。また自動メール送信を無断で有効化しないこと、複数の顧客や担当者へ一斉送信しないことも重要です。本記事で紹介するのは確認手順であり、実際のメール送信を行うものではありません。
手順6：確認結果を記録し、未着が解消した範囲を明確にする
調査が終わったら、原因、確認した時刻、送信・配送・受信の各段階で分かったこと、実施した対策、未確認の範囲を記録します。受信トレイにメールが見つかった場合でも、別の通知種類や次の障害時まで必ず届く保証とはなりません。
「特定の宛先で配送済みを確認」「組織の隔離フォルダーで保管されていた」「送信対象イベント自体が生成されていなかった」など、結果を具体的にまとめましょう。対策後の再確認が必要なら、事前承認された方法で行い、メール配信機能の利用可否と運用ルールも同時に確認してください。
調査依頼に必要な記録と時系列のまとめ方
サポートやメール管理者へ相談するときは「メールが来ません」だけでは原因を調べにくくなります。対象と時刻を揃え、監視・送信・配送・受信のどの段階まで確認できたかを短い表にして渡すと、切り分けが進みます。以下は架空の記入例です。
| 調査項目 | 記入例 | 確認する理由 |
|---|---|---|
| 対象サイト・URL | https://example.com/ |
どの監視対象の問題か特定 |
| 監視時刻（JST） | 10月24日 09:15 | 前後の監視履歴と照合 |
| イベント種類 | 障害の可能性 | どの種類のメールを期待していたか |
| 宛先 | ops@example.com |
受信アカウントと送信先を照合 |
| 受信側の確認結果 | 受信トレイ・迷惑メール・隔離を確認 | 調査済み範囲を共有 |
| 送信記録 | 未確認 | 送信対象だったかを確認 |
| 配送記録 | 未確認 | 配信・拒否・保留を確認 |
| 担当者・調査状況 | メール管理者へ調査依頼予定 | 次の確認先を明確にする |
時刻はJSTとUTCを混在させない
監視サービスとメール配信サービスのログでは、表示タイムゾーンが異なることがあります。例えばJSTの9時15分はUTCの同日0時15分です。違う時刻の記録を同じものとして扱うと、正常なメールを未着と誤認する可能性があります。
調査記録には日付・時刻・タイムゾーンを明記します。通知メールが遅れた場合は、障害発生、アラートイベント、送信受付、配信結果、受信者が発見した各時刻を分けて残してください。
「未送信」「配信失敗」「見つからない」を分けて報告する
通知イベントは発生したが送信処理が実行されていない場合は「未送信の可能性」、配信サービスが宛先への拒否を記録した場合は「配信失敗」、受信者の受信トレイで見つからないだけなら「受信トレイで未確認」と区別します。
具体的な状態を確認できるまでは「監視サービスがメールを紛失した」「メールが削除された」といった断定を避けます。管理者が確認した事実と、まだ調べていない項目を分けて共有すると、サポート側も同じ場所から調査を始められます。
他人のメール・認証情報を調査資料に含めない
配送エラーの全文には宛先の個人情報や内部システムの情報が含まれる場合があります。問い合わせには必要な範囲だけを共有し、認証トークン・SMTPパスワード・APIキーなどを記載しないでください。
ログをダウンロードして共有する場合も、閲覧権限と保存先、保存期間を組織の方針に合わせて管理します。技術的な調査のために第三者のメールへ無断でアクセスする必要はありません。
エンリンクの通知機能とメール未着の違い
エンリンクの公式機能一覧には、管理画面内のアラート、未読・既読管理、障害・復旧・SSL期限などの情報が案内されています。ここで説明したSMTP・メールAPI・迷惑メールや配送ログの調査は、一般的なメール通知に対応したサービスで発生するトラブルへの対処です。エンリンクに同じメール通知機能が実装されていることを示すものではありません。
エンリンクで確認できるのは管理画面内のアラート
公開されているエンリンクの機能一覧では、HTTP/HTTPSの定期監視、連続失敗による障害の可能性の記録、障害・復旧履歴、管理画面内アラート、既読・未読管理が案内されています。登録したサイトに異常が記録されているかを管理画面から確認することができます。
ただし、障害時のメール自動送信、外部チャット通知、メールの再送、配信ログの閲覧については、現行の公開機能説明から提供を確認できません。管理画面にアラートがあるのにメールが届かない場合、最初に「メール通知機能が利用可能か」を確認することが必要です。
登録確認メールと監視アラートメールは別の機能
エンリンクでは、新規登録時のメール確認コードやメンバー招待メールに関する機能が公開されています。これらのメールを受信できることは、監視異常をメールで知らせる機能が提供されている証拠にはなりません。
「登録メールは届くのに障害メールが届かない」という場合でも、まずその通知種別が製品の提供機能に含まれるかを確認してください。逆に登録確認コードの未着については、アカウントの本人確認という別の場面での問題であり、この記事の中心テーマとは異なります。
監視履歴と管理画面のアラートを確認する
エンリンクの管理画面では、登録サイトの監視状態、チェックごとの結果、HTTPコード、応答時間、判定理由、障害・復旧履歴などが案内されています。現在の異常の可能性を確認し、いつどのようなチェックが行われたかを整理する用途に使えます。
チェック結果の具体的な読み方はWebサイト監視の履歴の見方にまとめています。なお、監視記録が残っているからといって、メール送信機能が存在することや、メールが送信されたことを意味しません。
必要な機能を確認して管理対象サイトを整理する
2026年10月24日時点の料金プランでは、無料プランは5サイトまで登録でき、定期監視は1日2回、有料プランは最短15分・5分・1分の間隔が案内されています。これらは監視の実行間隔であり、通知メールの配送速度やメール機能の存在を示すものではありません。
まず管理中のサイトの監視状況と履歴をまとめて確認したい方は、エンリンクの無料アカウント登録から利用を始められます。メールへの自動通知を必須条件としている場合は、導入前にサービスごとの提供機能と配送方式を確認してください。
死活監視の通知メール未着についてよくある質問
実際に未着が起きたときに判断を誤りやすい点を、送信・配送・受信の段階に分けてまとめます。特定サービスで利用できる操作は、公式の機能説明と契約条件により異なります。
死活監視の異常はあるのにメールが届かないのはなぜですか？
主な原因は、メール通知機能がない・無効、通知対象のイベントが成立していない、送信処理の失敗、配送の遅延・拒否、迷惑メールや隔離への振り分けなどです。まずメール通知機能の提供状況と、送信対象イベントがあったかを確認してください。
迷惑メールフォルダーにも見つからない場合は？
受信トレイ以外の全フォルダーや転送先、組織の隔離フォルダーを確認し、送信元・宛先・時刻で検索します。見つからなければ、送信サービスの配送記録や、組織のメール管理者によるメッセージ追跡を調べます。迷惑メールにないことだけでは未送信と断定できません。
監視画面に「通知済み」とあれば配信は成功していますか？
表示の意味はサービスによります。通知対象イベントの記録、送信要求の受付、実際の配送完了をそれぞれ「通知済み」と呼ぶことがあります。提供元の仕様を確認し、必要ならメッセージIDで後続の配送状態を追ってください。
送信済みメールなのに受信側で見つからないのはなぜですか？
受信サーバーに届いた後に迷惑メール、隔離、転送、削除などが行われる場合があります。また「送信済み」が単にSMTP/API受付済みを意味し、配送自体は失敗している可能性もあります。送信側のステータスと受信側のログを照合します。
SPF・DKIM・DMARCが未設定だと必ず届きませんか？
一律に届かないとは限りません。受信者のサービスや送信条件によって判定は異なりますが、認証不備は拒否や迷惑メールへの振り分けにつながる可能性があります。まず拒否理由と実際の認証結果を確認し、DNSは権限のある管理者が変更してください。
一人だけ通知メールが来ない場合、どこを調べますか？
その人の登録アドレス、迷惑メール・隔離、個別の転送や振り分け、受信アカウントの状態、配信サービスの送信抑制を優先して確認します。ほかの受信者に届いていることは、対象の一人にも届いた証拠ではありません。
メールが数十分遅れて届く原因は何ですか？
監視から通知イベントが成立するまでの時間、メール送信処理の待機、受信サーバーの一時拒否と再試行、受信側の処理遅延などが考えられます。監視時刻・イベント時刻・送信受付・配送完了の時刻を並べ、遅延が発生した段階を探します。
エンリンクは障害を検知するとメール通知しますか？
2026年10月24日時点の公式機能一覧で確認できるのは管理画面内アラートと既読・未読管理です。障害メールの自動配信が提供されていることは確認できません。登録確認メールやメンバー招待メールとは別の機能として、現行の公式案内を確認してください。
届かないか確かめるために何度もテスト送信すべきですか？
まず送信・配送・受信のログを確認する方が適切です。無断の大量再送は配送制限や迷惑メール判定を招く場合があります。テストが必要なら、サービスの公式機能と組織の承認を確認し、テスト用の宛先で必要最小限に実施します。
まとめ：通知メール未着は「機能→イベント→送信→配送→受信」で調べる
死活監視の通知メールが届かないときは、メール通知機能の有無、通知イベントの成立、送信ログ、配送状態、受信側の振り分けを順に確認します。最初に迷惑メールだけを探したり、送信の事実を確認せずDNSを変更したりすると、原因から遠回りしてしまいます。
送信要求が受付されたことと、受信者の受信トレイにメールが表示されたことは別です。バウンス、配信遅延、送信抑制、隔離などの状態を分け、メッセージID・宛先・日時で照合しましょう。原因が分からないときは、どこまで確認できたかを記録して正しい管理者へ引き継ぐことが重要です。
エンリンクでは、現在の公開機能説明に基づき、監視の履歴と管理画面内アラートを確認するサービスとして案内しています。最大5サイトまで無料で監視を始める場合も、メールへの自動通知を必須条件とするなら、その機能の提供有無を事前に確認してください。
参照した一次資料：Google Workspace「Email Log Search」、Google Workspace「特定の送信者からのメールが届かない」、Microsoft「Exchange Onlineのメッセージ追跡FAQ」、AWS「Amazon SESのイベント発行」、AWS「SES送信抑制リスト」、Google「メール送信者のガイドライン」（確認日：2026年10月24日）。
