WordPressの問い合わせメールが届かない？AIと確認する送信・受信・認証の基本

宿主とAIが問い合わせフォーム・メール送信・ドメイン認証・受信箱・迷惑メールを順番に確認するイラスト AIサイト管理

宿の問い合わせフォームに「送信しました」と表示されたのに、受信箱へメールが届かない。お客様には自動返信が届いたが、宿側の通知だけ見当たらない。迷惑メールに入ったり、ある宛先だけ受信できなかったりする――。

この問題が難しいのは、フォーム画面、WordPress、送信サーバー、メール配送、受信サービスという複数の段階があるからです。WordPressが送信処理を受け付けたことと、宿の受信箱へ届いたことは同じではありません。

この記事では、CodexやClaude Codeに状況整理を手伝わせながら、ITに詳しくない宿主さんでも安全に切り分けられる方法を説明します。

結論：メールは五段階で確認する

問い合わせメールは、次の経路を通ります。

1. お客様がフォームを送信
  ↓
2. WordPress・フォーム機能が内容を処理
  ↓
3. サイトからメールサーバーへ渡す
  ↓
4. 送信元の認証や迷惑メール判定を通る
  ↓
5. 宿の受信箱へ届く

画面に完了表示が出ても、3〜5で失敗する可能性があります。AIへ「メールを直して」とだけ頼まず、どの段階まで確認できたかを整理します。

最初に営業上の代替経路を確保する

問い合わせが届かない疑いがある場合は、調査中もお客様が連絡できる方法を用意します。

  • 電話番号を分かりやすく案内する
  • 利用できるOTAや予約サービスを案内する
  • 公式SNSのメッセージを一時窓口にするか決める
  • 送信済みのお客様へ再連絡をお願いする場合の文面を作る
  • 返信がない場合の連絡方法をフォーム付近へ表示する

個人情報をSNSの公開投稿へ書かないように案内します。「何日分の問い合わせが失われた」と、確認前に断定しません。

第1段階：フォーム画面を確認する

次をパソコンとスマートフォンで確認します。

  • フォームが表示される
  • 必須項目が入力できる
  • 個人情報の案内が読める
  • 送信ボタンが押せる
  • エラー文または完了文が表示される
  • 二重送信にならない
  • 送信後に予約完了と誤解させない

問い合わせは予約確定ではありません。完了文には「送信を受け付けた」ことと、返信時期、急ぎの場合の連絡先を分けて書きます。

テストには実在するお客様の情報を使わず、件名や名前にテストであることを明記します。短時間に何度も送ると、迷惑送信対策で一時的に拒否されることがあります。

第2段階：WordPressが処理したか確認する

フォーム機能によっては、管理画面や専用保存領域へ問い合わせ記録を残せます。保存されている場合、フォーム処理までは通った可能性があります。

ただし、問い合わせ内容をWordPressへ保存すると、個人情報の保管場所が増えます。

  • 何を保存するか
  • 誰が閲覧できるか
  • いつ削除するか
  • バックアップにも含まれるか
  • 保守担当者が閲覧する必要があるか

を決めます。メール不達対策のために、無期限に個人情報を保存してはいけません。

WordPressのwp_mail()は送信処理に使われますが、公式資料でも、処理結果がtrueでも受信者へ届いたことを自動的に意味しないと説明されています。

第3段階：サイトからメール配送へ渡ったか確認する

WordPressは、サーバーのメール機能または外部のメール配信サービスを利用して送信します。ここで確認する項目は次のとおりです。

  • どの仕組みで送っているか
  • 送信元アドレスが宿のドメインか
  • 返信先がフォーム入力者になっているか
  • 送信サービスの認証が有効か
  • 送信失敗の記録があるか
  • 一日の送信上限を超えていないか
  • 契約や支払いが有効か

フォームの入力者アドレスを、そのまま「送信元」にすると、宿のサイトが他人のドメインを名乗って送る形になり、認証に失敗しやすくなります。一般には宿が管理するドメインを送信元にし、お客様のアドレスは返信先として扱います。実際の設定はフォーム製品とメールサービスの公式手順を確認します。

第4段階：SPF・DKIM・DMARCを理解する

これらは、宿のドメインを名乗るメールが正当な送信元から来たかを受信側が確認する仕組みです。

SPF

そのドメインからメールを送ってよいサーバーをDNSへ示します。宿の通常メール、WordPress、予約システム、メールマガジンなど、送信元を洗い出す必要があります。

DKIM

送信メールへ電子署名を付け、途中で改変されていないことと、ドメイン管理者が認めた送信であることを確認しやすくします。

DMARC

SPFやDKIMの結果と、画面上の送信元ドメインが合っているかを確認し、失敗メールをどう扱うか受信側へ方針を示します。集計レポートを受け取り、なりすましや設定漏れを調べる用途もあります。

Googleの送信者向けガイドラインでは、Gmail宛てに送るすべての送信者へSPFまたはDKIMなどの要件を示し、SPF・DKIM・DMARCの設定を推奨しています。

AIへDNSレコードを丸ごと作らせない

SPFへ含める送信元やDKIMの値は、契約中のメール・予約・配信サービスによって異なります。推測した値を設定すると、現在届いているメールまで失敗する可能性があります。

  1. 宿から送信するサービスをすべて一覧化する
  2. 各サービスの公式設定値を取得する
  3. 現在のDNSレコードを読み取り確認する
  4. 重複や上書きの影響を確認する
  5. 変更案を人が承認する
  6. 反映後に複数の受信先で確認する

DNS管理画面のログイン情報や秘密鍵をAIへ貼り付けません。

第5段階：受信側を確認する

送信できていても受信側で分けられる場合があります。

  • 迷惑メールフォルダ
  • 隔離・検疫画面
  • 自動振り分けルール
  • 転送設定
  • 受信拒否リスト
  • メールボックス容量
  • 退職者や旧担当者の宛先
  • メーリングリストの参加状態

宿の受信アドレス一つだけで試すと、受信側固有の問題を見落とします。許可されたテスト用の複数サービス宛てに送り、どこまで届くか比較します。ただし実在するお客様のアドレスを無断でテストに使いません。

自動返信と宿への通知は別に確認する

問い合わせフォームでは、通常二種類のメールがあります。

メール 宛先 確認すること
宿への通知 宿の受付担当 問い合わせを見落とさないか
お客様への自動返信 入力されたアドレス 受付内容・返信目安・連絡先が正しいか

片方だけ届くことがあります。送信元、宛先、件名、本文、返信先をそれぞれ確認します。自動返信へ問い合わせ内容をすべて載せると、アドレス入力ミス時に第三者へ個人情報を送る可能性があるため、掲載内容を必要最小限にします。

メールログを扱うときの注意

配送記録は原因調査に役立ちますが、次の情報を含む場合があります。

  • メールアドレス
  • 件名
  • 本文の一部
  • 送信時刻
  • IPアドレス
  • 内部サーバー名
  • 配送サービスの識別子

AIへログ全文を貼らず、テストメールの時刻と配送状態など必要な部分だけを匿名化します。ログ保存期間と閲覧権限も決めます。

定期テストの方法

月に一度、またはフォーム・メール設定・DNSを変更した後に、次を確認します。

  1. 専用のテスト内容でフォーム送信
  2. 画面に完了表示が出る
  3. 宿への通知が届く
  4. お客様向け自動返信がテスト先へ届く
  5. 迷惑メールへ入っていない
  6. 返信先が正しい
  7. パソコン・スマートフォンでメールが読める
  8. テスト記録と不要な個人情報を整理する

日常の外形監視ではフォームの存在まで確認し、実際の送信は低頻度の機能試験として分けると、不要なメールを増やしにくくなります。

AIに任せられる作業

CodexやClaude Codeは次を支援できます。

  • フォームから受信までの経路図を作る
  • 宿が利用する送信サービスを一覧化する
  • フォーム設定の送信元・返信先を読み取り確認する
  • DNSレコードと公式設定値の差を整理する
  • テストケースとチェックリストを作る
  • エラーを送信・認証・配送・受信に分類する
  • サーバー会社やメール会社への問い合わせ文を作る
  • 個人情報を除いた障害記録を作る

AIへメールアカウントのパスワード、APIキー、DNS管理権限を渡さず、変更は提案と差分確認から始めます。

コピペで使えるAIへの依頼文

まず経路を整理する

WordPressの問い合わせメールが宿へ届かないことがあります。
まだ設定変更やテスト送信をしないでください。

フォーム入力、WordPress処理、送信サービス、SPF・DKIM・DMARC、
受信箱の五段階に分け、確認項目を作ってください。
現在確認できた事実、原因候補、未確認事項を分けてください。
パスワード、APIキー、顧客情報、メール本文は表示しないでください。

フォーム設定を読み取り確認する

問い合わせフォームのメール設定を、変更せず確認してください。
送信元、宛先、返信先、宿向け通知、お客様向け自動返信を整理し、
なりすまし判定や個人情報送信につながる可能性を指摘してください。

秘密値は表示せず、設定場所と確認結果だけ報告してください。
私が承認するまでプラグイン追加、SMTP変更、DNS変更をしないでください。

DNS認証の変更計画を作る

宿のドメインからメールを送るサービス一覧と、各社の公式設定資料を基に、
SPF・DKIM・DMARCの確認計画を作ってください。

推測したDNS値を作らず、現在値、公式の必要値、差分、影響、
元へ戻す方法、反映後テストを示してください。
DNS変更は実行せず、人の承認項目として残してください。

不達時の問い合わせ文を作る

次のテストメール不達について、サーバー会社またはメールサービスへ送る
問い合わせ文を作ってください。

送信日時、送信元ドメイン、宛先サービス、フォーム結果、
配送状態、認証結果、迷惑メール確認の有無を簡潔に含めてください。
メールアドレスは必要に応じて伏せ、本文、顧客情報、認証情報は含めないでください。

メール送信サービスを選ぶ比較項目

特定のプラグイン名だけで決めず、次を確認します。

  • 宿のドメインで送信できる
  • SPF・DKIM・DMARCの公式手順がある
  • 送信結果と失敗理由を確認できる
  • WordPressまたはフォーム機能との公式連携がある
  • 一日の送信数と料金が用途に合う
  • 日本語サポートの有無
  • APIキー等の権限を限定できる
  • 退職・委託終了時に引き継げる
  • ログへ保存される内容と期間
  • 障害時の代替連絡方法がある

共用レンタルサーバーでは、まず提供会社のメール送信仕様と推奨方法を確認します。VPSではメールサーバーを自営する責任が大きいため、外部のトランザクションメールサービスを含めて保守担当者と比較します。

宿主さん向けチェックリスト

  • [ ] フォーム完了と受信箱到達を分けて確認した
  • [ ] 宿向け通知とお客様向け自動返信を別々に試した
  • [ ] テストには架空の個人情報を使った
  • [ ] 送信元と返信先の役割を確認した
  • [ ] 迷惑メール・隔離・転送・容量を確認した
  • [ ] 宿から送信するサービスを一覧化した
  • [ ] SPF・DKIM・DMARCを公式資料と照合した
  • [ ] AIへDNS値や秘密情報を推測させていない
  • [ ] ログは必要部分だけ匿名化して扱った
  • [ ] 定期テストの担当者と記録場所を決めた

迷惑な自動送信を減らす場合は宿の問い合わせフォーム迷惑メール対策を参照してください。公開ページの監視は宿サイトの外形監視、障害時の初動はWordPress障害発生後の最初の30分、毎月の確認は宿泊施設サイトの月次点検で確認できます。

参考にした情報

まとめ

問い合わせ画面に「送信しました」と出ても、宿の受信箱まで届いたとは限りません。フォーム、WordPress、送信サービス、ドメイン認証、受信箱の順に分けて確認します。

AIは経路の整理、設定差分、テスト計画、問い合わせ文を作れます。宿主さんは代替連絡先、個人情報の扱い、送信元サービス、DNS変更の承認、最終的な受信確認を担当します。定期的にテスト送信と受信確認を行えば、「お問い合わせに気づかなかった」という営業上の損失を減らせます。

タイトルとURLをコピーしました