お問い合わせフォームの通知が来ないとき、最初の30分でやること
お問い合わせフォームの通知が来ない/急に減ったときに、最初の30分で「送信/到達/見落とし」を切り分けて止血する手順です。
お問い合わせフォームの通知が来ない（または急に減った）とき、最初の30分でやるべきことは「そもそも送信が発生していない」のか「送信は発生しているが到達していない」のか「到達しているが見落としている（迷惑メール・振り分け・監視漏れ）」の3つに分けて、止血することです。
問い合わせが止まると、売上が止まります。最初の30分は“原因の場所”だけを確定させ、修正箇所を間違えないことを優先します。
0. まずやらないこと
- いきなりフォームのUIを作り直す（原因がメール側のことが多い）
- いきなりDNS（SPF/DKIM/DMARC）を闇雲に触る（設定変更は慎重に）
- いきなり「最近のリリースのせい」と決めつける（まず事実を固定）
1. 症状を1行で固定（3分）
次のどれかを一つ選び、まず“症状”を固定します。
- 問い合わせが完全に0になった（昨日まで来ていたのに、今日からゼロ）
- 問い合わせが減った（来てはいるが、明らかに少ない）
- 一部だけ届かない（特定ドメイン/特定フォームだけ届かない）
この違いで、疑う順番が変わります。
2. 「送信が発生していない」かを最速で確認（7分）
最初に確認したいのは、「ユーザーが送信できていない」可能性です。
- フォーム送信後の画面は“成功”になっているか
- 直近30分でフォーム送信のリクエスト自体が来ているか（アクセスログ/アプリログ）
- 4xx/5xx が増えていないか（とくに 429 / 500 / 503）
ここでリクエストが1件も来ていないなら、原因はフォーム送信（フロント/バック/インフラ）側に寄ります。
3. 「送信は発生しているが通知が来ない」を分解（10分）
送信自体は発生しているのに通知が来ない場合、次のどれかです。
- 送信処理が失敗している（メール送信APIが失敗/タイムアウト）
- 送信は成功しているが到達していない（迷惑メール・拒否・レピュテーション）
- 到達しているが見落としている（振り分け/監視/通知先ミス）
最初の30分で、この分類だけは確定します。
4. “送信処理が失敗している”の止血（5分）
メール送信の失敗が見えるなら、まず止血は「送信を確実に成功させる（または代替経路を用意する）」です。
- タイムアウトやレート制限が出ていないか
- 送信先（To）が環境変数/設定で空になっていないか
- 送信ログにエラーが残っていないか
この段階では、内容の改善より「確実に通知が届く経路」を復旧させます。
5. “到達していない”が濃厚なときの最短チェック（5分）
到達しない場合は、だいたい以下のどれかです。
- 送信ドメインの認証（SPF/DKIM/DMARC）や整合性に問題がある
- 送信元の評価が落ち、迷惑メール/拒否が増えている
- 送信先側の受信ルール（社内フィルタ/個人の振り分け）が変わった
止血としては「別の通知先に同報する」「ダッシュボード/DBに記録して見落としを防ぐ」など、到達を待たずに“取りこぼしをなくす”手が強いです。
6. “見落としている”を潰す（5分）
実は届いているのに見落としていることも多いです。
- 迷惑メール/プロモーション/通知タブに入っていないか
- ルール/フィルタでアーカイブされていないか
- 通知先（To/CC/BCC）が意図した受信箱か
この確認は、最短で“復旧”につながります。
7. 30分で出す“結論”の型
最初の30分で、次のどれかに分類して次の作業を固定します。
- 送信が発生していない: フォーム/バックエンド/インフラの障害。まず送信を復旧。
- 送信は発生しているが通知処理が失敗: 送信API/設定/レート。まず成功率を戻す。
- 送信は成功しているが到達しない/見落とす: 受信側/認証/監視。取りこぼし防止を優先。
この分類ができれば、次の1時間で“直す場所”を間違えません。
関連
参考にした一次情報
この記事を書いた人
川原
SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。
関連記事
次にやること
複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。
料金を見る相談したい / お問い合わせ