1. 最初に、通知メールと受付記録を分ける

フォームの受付、メールの送信、担当者の受信は、それぞれ別の確認が必要です。以下はhirostaが提案する切り分け方で、すべてのフォームに同じ保存機能や管理画面があるという意味ではありません。

確認する工程 確かめるもの 分からないときの確認先
フォームの受付・保存 受付日時、管理番号、管理画面や保存先の記録 制作会社・フォームの管理者
通知メールの送信 通知先、送信履歴、送信サービスの応答やエラー 保守会社・送信サービスの管理者
受信・担当者への引き継ぎ 受信先、振り分け、転送、担当者の対応状況 メール管理者・受付担当者

送信完了画面が出たこと、フォームの管理画面に記録があること、メールが受信トレイにあることを同じ「成功」にまとめません。分からない工程は「失敗」ではなく「未確認」と残します。

通知メールだけが記録になる構成なら、別の受付一覧がある前提では調べられません。取得できるログと保存期間を管理者へ確認し、記録がないという理由だけで問い合わせ自体がなかったとは判断しないようにします。

2. 受付日時を絞り、再送前に対応状況を確かめる

社内の受付担当者が、いつから、どのフォームで、誰向けの通知が届かないかを整理します。担当者向けの通知と、お客様向けの自動返信は別に確認してください。一方が届いても、もう一方の到達は確認できません。

  1. 対象を絞る。 フォームのページ、発生日時とタイムゾーン、最後に届いた日時、対象の通知先を残します。
  2. 受付記録を探す。 管理番号や日時で探し、同じ依頼の再送、対応中・対応済みの記録がないか確認します。
  3. 影響期間の未対応を拾う。 記録が残っている範囲で担当者を決め、通知の復旧を待つ間の対応も管理します。
  4. 再送するなら対象を決める。 受付の再登録が必要なのか、社内の通知だけでよいのかを分けます。お客様への自動返信までまとめて再送しません。

受付済みの問い合わせは、元の記録にひも付けて対応します。連絡の必要がある場合は、社内で認めた連絡先と方法を使い、誰が返答するかを先に決めます。原因不明のまま「届くまで何度も送信する」運用にしないことが大切です。

3. 保守会社には「送ったか」と「どこまで届いたか」を聞く

受付記録がある場合は、通知先の設定と送信履歴を調べます。社内でログを読めなければ、保守会社へ次の形で依頼できます。

対象フォーム、発生日時とタイムゾーン、受付番号、届かない通知の種類を共有します。受付の保存、通知処理の実行、送信サービスの受付、宛先側への配信のうち、どこまで確認できるか教えてください。エラーがある場合は、発生日時・コード・原文と、次に確認する担当をお願いします。設定変更や再送の前に、対象範囲と他のメールへの影響も確認したいです。

「送信済み」という表示が何を表すかはサービスによって異なります。送信サービスが受け付けた段階なのか、宛先側のサーバーが受け付けた段階なのかを確認し、担当者が読める場所への到着と区別します。

Googleの配信不能メールの案内も、エラーの内容から原因を確認する手順です。自社の通知では、配信不能通知が戻る先を誰が確認できるかも聞いてください。エラーが見つからないことだけで、到達済みとは判断しません。

共有するのは調査に必要な範囲に絞り、宛先などの情報は既知の保守窓口へ承認された経路で渡します。問い合わせ本文、顧客の連絡先、認証情報を公開の掲示板や外部AIへそのまま貼り付けないようにします。

4. 受信側を調べ、Gmailの要件は対象を確かめて使う

受信担当者は迷惑メールやゴミ箱、別フォルダーを確認し、メール管理者は振り分け・転送・容量などを調べます。Gmailの場合は、公式ヘルプに沿って確認できます。他サービスの管理画面や制限は、その提供元の案内で確認します。

転送して使っているなら、元の受信先と転送後の受信先を分けて調べます。元の受信先に記録があるだけでは、最終的な通知先まで届いたことにはなりません。知らない転送設定などが見つかった場合は、通常の不達対応だけで終えず、社内のセキュリティ窓口へ相談します。

メール認証は、対象の送信経路を管理者が確認する

Googleのメール送信者のガイドラインは、個人用Gmail（@gmail.com、@googlemail.com）宛ての送信を対象としています。自社ドメインで使うGoogle Workspaceや、他社のメールサービス全体に、そのまま同じ条件を当てはめません。

同ガイドラインでは、すべての送信者と大量送信者で認証の必須条件が異なります。SPF・DKIMは送信元の認証に使う仕組み、DMARCはその認証と差出人ドメインの関係などを扱う仕組みです。具体的な要件は公式資料を参照し、管理者が実際の送信元・経路・送信量と合わせて確認します。認証の設定だけで不達の原因を決めたり、到達を保証したりはできません。

フォームに入力されたお客様のアドレスを、通知の差出人（From）にそのまま使っていないかも確認項目です。差出人と返信先（Reply-To）をどう分けるか、使う送信サービスで認証できる構成を保守担当者に相談します。これは構成を見直す提案であり、この記事で自社の設定不良を特定できるものではありません。

DNSや認証の設定は他の業務メールにも関わります。担当者が分からないまま値を追加・置換せず、メール管理者と保守担当者が現状、影響、戻し方を確認して変更します。迷惑メール対策を一括で無効にして解決しようとしないでください。

5. 想定シナリオ：受付は残り、営業担当への転送後に見つからない

以下は架空の卸売会社の未実施の想定シナリオです。フォームの管理画面には見積依頼が残っていますが、営業担当の受信トレイには通知がありません。通知は共通窓口から営業担当へ転送する構成を想定します。

最初に受付担当者が管理番号と対応状況を確認し、未対応の依頼を担当者へ引き継ぎます。フォームの再送は依頼せず、元の受付を使います。次に保守担当者が通知の送信履歴を確認し、メール管理者が共通窓口と転送先を調べます。

記録する一覧のイメージは次のとおりです。問い合わせ本文は複製せず、閲覧権限のある元の記録を参照します。

確認項目 この例で残す内容
対象 フォーム、受付番号、受付日時とタイムゾーン
受付・業務対応 保存済み。営業担当へ引き継ぎ、返答状況は元の受付で管理
送信 保守担当が調べた通知先・送信結果・確認日時
受信 共通窓口では見つかったが、転送先では未確認
次の対応 メール管理者が転送先の振り分けと配信状況を調べ、社内で決めた期限までに回答

転送先の迷惑メールに見つかった場合も、すぐに全件を再送しません。管理者が原因と必要な変更を確認した後、了承を得た確認用送信で、受付・通知・受信をつなげて確かめます。並行して、影響期間に未対応の依頼が残っていないかを受付担当者が点検します。

AIを使うなら、共有を認めた情報から確認事項や依頼文の下書きを作る補助にとどめます。受付の有無、配信結果、再送の可否は元の記録で人が確かめ、AIに設定変更や顧客への送信を任せる前提にはしません。

6. 復旧の完了条件と、費用・期間を決める

復旧の確認は、実際の顧客情報を使わず、送信先・内容・実施時間の了承を得て行います。既存の問い合わせ対応や外部への通知と混ざらない方法を保守担当者と決めてください。

  • 受付の記録、通知の送信結果、担当者の受信を同じ確認用の受付に対応させて確認できたか。
  • お客様向け自動返信を使う場合は、その送信と受信も別に確認したか。
  • 影響期間の未対応と重複を確認し、残る依頼に担当者と次の対応があるか。
  • 原因、変更した設定、残る未確認、次に不達が起きたときの窓口を残したか。

確認用のメールが届くことと、過去の未対応を解消したことは別です。記録を取得できない期間があれば、その範囲を残し、全件確認済みとは報告しません。

費用は、ログ調査、送受信設定の修正、フォーム改修、確認作業、今後の保守を分けて見積もります。既存契約の対象と追加作業、送信サービスの利用料も確認します。期間は管理権限やログの有無、外部事業者への確認、変更後の確認日程で変わるため、一律の復旧日数や料金は示せません。

通知が不達でも受付を確認できる運用にするかは、HP制作の発注範囲と合わせて検討できます。受付後の分類や返答は問い合わせ対応のガイド、人が確認して送る流れは問い合わせ対応の事例が参考になります。この事例は、通知の不達を解決した実績を示すものではありません。

業務全体の整理はAI業務改善ガイド、支援内容と料金はサービス案内をご覧ください。現状が分からない段階でも、お問い合わせからご相談いただけます。