VtigerCRM OSSの導入・運用 ｜ メール障害の切り分け
VtigerCRMでメールが送れないときの確認手順｜SMTP・ワークフロー・CRON
テストメールも失敗する場合は送信メールサーバーの設定から確認します。手動送信は届くのに自動通知だけ届かない場合はワークフローとCRON、送信サーバーが受け付けたのに相手に届かない場合は配送ログと受信側を調べます。
症状別の早見表
どの段階でメールが止まったか確認する
管理下の検証用アドレスを使い、件名に「CRMメール試験 A01」などの識別子を付けます。SMTP設定のテスト送信、CRM画面からの手動送信、ワークフローによる自動送信を分けて試すと、最後に通過した段階が分かります。比較できる範囲で宛先と差出人をそろえます。
| 症状 | 最初に見る場所 | 確認する証跡 |
|---|---|---|
| テスト送信も失敗 | VtigerCRMのSMTP設定 | 管理ユーザーのメールアドレス、接続・TLS・認証のエラー |
| 手動送信は成功し、自動通知だけ届かない | ワークフローとCRON | 発火条件、宛先、Workflowの最終開始・終了、SMTPへの送信記録 |
| 送信後に相手側で届かない | SMTP事業者の配送ログと受信側 | Message-ID、配送ステータス、バウンス、隔離 |
01 ／ テスト送信も失敗する
送信メールサーバーの設定と接続を確認する
管理者でCRM設定の「送信メールサーバー（Outgoing Server）」を開きます。OSS 8.4.0標準では、設定の保存時に操作中のユーザーのメールアドレスへテストメールを送ります。保存時にエラーが出る場合は、ユーザー設定のメールアドレスと、メール事業者が案内するSMTP条件を照合します。
- 接続先とポート。SMTPホスト名とポートを事業者の案内に合わせます。タイムアウトなら、CRMが動くサーバーからSMTPへの名前解決と外向き通信を確認します。接続拒否の場合は、ポートの選択やサーバー側の許可条件も調べます。
- 暗号化方式。587番のSTARTTLSと465番の暗黙TLSは接続方式が異なります。OSS 8.4.0標準で事業者から587番のSTARTTLSを指定された場合、サーバー欄の表記例は
tls://smtp.example.com:587です。証明書のエラーが出たら、ホスト名、サーバー時刻、CA証明書を確認します。 - 認証方式と差出人。SMTP認証の要否、ユーザー名、認証方式、許可されたFromを確認します。
535が返る場合は、認証情報に加え、アカウントや組織のSMTP利用ポリシーを確認します。利用中の認証方式が事業者の要件と合わない場合は、承認済みのSMTPリレーなどをメール管理者と検討します。
テスト設定を保存できたら、まずテストメールを受信できるか確認します。続いて、CRMの通常のメール画面から、同じ検証先へ添付なしで送信します。ログを共有するときは、認証情報、トークン、本文を除き、試験時刻とエラーコードを残します。
02 ／ 手動送信は届くが自動通知が届かない
発火条件・担当者メール・Workflowジョブを確認する
1. 実際の操作がワークフローの条件に合うか確かめる
対象モジュール、ワークフローとメールアクションの有効状態、実行条件を見ます。たとえば「見込み客の新規作成時」なら、既存レコードを編集する代わりに、条件を満たす検証用レコードを1件作成します。アクションに設定した実行予定時刻や遅延条件も確認します。
2. 宛先と差出人がどのアドレスに解決されるか確かめる
宛先が「担当者」などの差し込みの場合、対象レコードでアドレスが取得できるか確認します。担当がグループのときも、想定の宛先に解決されるかを試します。検証用ワークフローで固定の管理下アドレスへ送ると、宛先の差し込みとキュー処理を切り分けられます。差出人も手動メールと比較し、SMTP事業者で送信を許可されたアドレスを使用します。
3. CRMのスケジューラーとサーバーのCRONを照合する
OSS 8.4.0の標準ワークフローメールは、キューに入ったあと、定期実行で処理されます。「CRM設定 → スケジューラー」の Workflow 行で、有効状態、実行間隔、最終開始と最終終了を確認します。対象時刻に実行履歴が進まなければサーバーのCRONを、開始だけ進んで終了しなければPHP CLIやジョブのエラーを調べます。
最終終了が進んでいても、個々のメールの配送はSMTP側で確認します。障害後に再送する場合は、送信記録を確認してから対象を絞ります。標準のキュー処理だけで送信エラー後に必ず再試行されるとは限りません。
03 ／ CRM上は送信済みでも相手に届かない
配送ログとバウンスで受信先まで追う
送信側のSMTPがメッセージを受け付けた後も、配送の遅延、宛先側の拒否、迷惑メール振り分け、管理者隔離が起こります。SMTP事業者の送信ログで時刻と宛先を検索し、可能なら Message-ID またはキューIDを控えます。拒否の理由は、バウンス（配信不能通知）や配送ログのSMTP応答で確認します。
| ログの結果 | 次に確認すること |
|---|---|
| 送信記録がない | 接続したSMTPのログを見ているか確認。ワークフローだけならジョブ、宛先の差し込み、実際の送信時刻を調べる。 |
| 一時エラー（4xx） | 送信事業者の再試行・保留状況と、応答本文にある制限理由を確認。保留中の手動再送は重複に注意する。 |
| 恒久エラー（5xx） | バウンスの全文から理由を確認。たとえば Gmail の 550 5.7.26 は、SPF・DKIM・DMARCなどの認証に関する拒否で現れる。 |
| 受信側サーバーが受け付けた | 受信側の迷惑メール、隔離、受信ルールを確認。見つからなければ受信側管理者に時刻とMessage-IDを渡す。 |
送信ドメイン認証を調べるときは、SPFで実際の送信サービスが許可されているか、DKIMでそのサービスの署名が付くか、DMARCで表示上のFromと、検証に通ったSPFまたはDKIMのドメインが整合するかを確認します。受信できた試験メールがあれば、原文ヘッダーの Authentication-Results が手がかりです。
復旧確認 ／ 記録を残す
エラー解消後は、同じ条件で1件ずつ再テストする
調査を引き継ぐときは、発生日時とタイムゾーン、送信種別、検証用の件名、Fromと宛先のドメイン、エラーコード、Message-IDまたはキューIDを記録します。自動通知の場合は、対象ワークフロー、レコードID、ジョブの最終開始・終了時刻も控えます。
設定を修正したら、テスト送信、手動送信、自動通知のうち失敗した経路を再現します。SMTPログで配送結果を追い、対象の宛先で受信できたところまで確認すると、復旧を判断できます。
vtplus ｜ VtigerCRMの導入・運用支援
SMTP設定や通知が止まった箇所を相談する
VtigerCRMの運用環境で、SMTP、ワークフロー、サーバーの定期実行のどこで止まっているか判断が難しい場合は、発生時刻とエラーコードを添えてご相談ください。