EC-CUBEでメールが届かないときの原因の切り分け手順

EC-CUBEからのメールが届かないとき、原因は大きく「送信できていない」か「送信したが受信側で捨てられている」かのどちらかです。この2つは対処法がまったく違うため、先に切り分けないと的外れな作業を続けることになります。ログの確認から始めて、原因を特定するまでの順番をまとめます。

まずログを見て「送信できているか」を判定する

最初にやることは設定の見直しではありません。ログの確認です。ここで送信の成否が分かり、以降の作業が半分に絞れます。

tail -100 var/log/prod/front.log
tail -100 var/log/prod/admin.log

EC-CUBEはメール送信の失敗を捕捉してログに記録します。SMTPサーバーに繋がらない、認証に失敗したといったエラーは、ここに残ります。

判定はこうなります。

ログの状態	切り分け	見るべき箇所
エラーが出ている	送信できていない	MAILER_DSNの設定
エラーが無い	送信はできている	DNS認証（SPF/DKIM/DMARC）

エラーが無いのにMAILER_DSNを何度も書き換える、という遠回りをしないために、この判定を先にしてください。

送信できていない場合はMAILER_DSNを疑う

ログにエラーが出ていた場合、.envのMAILER_DSNが正しくないケースがほとんどです。利用するサービスごとに書式が違います。

# Gmail（アプリパスワードが必要。通常のログインパスワードでは通らない）
MAILER_DSN=smtp://username:app_password@smtp.gmail.com:587

# SendGrid（ユーザー名は固定文字列 apikey）
MAILER_DSN=smtp://apikey:SG.xxxxx@smtp.sendgrid.net:587

# さくらのレンタルサーバ
MAILER_DSN=smtp://username:password@初期ドメイン.sakura.ne.jp:587

詰まりやすいのが次の3点です。

1. Gmailは通常のパスワードでは認証できません。Googleアカウントでアプリパスワードを発行して指定します
2. パスワードに記号が含まれる場合はURLエンコードが必要です。@や#をそのまま書くとDSNの区切りとして解釈され、認証に失敗します
3. ポート番号を省略しない。サービス側が587を要求していても、省略時の既定値が異なると繋がりません

.envの値は実行時に読み込まれるため、書き換えたあとのキャッシュクリアは不要です。保存したらそのまま送信テストを行ってください。

MAILER_DSNの仕組み（未設定時のnull://nullではエラーなしにどこにも送信されない点）と、送信方法別の書き方の詳細はEC-CUBE4のメール設定 MAILER_DSNの書き方と確認点にまとめています。

送信できているのに届かない場合はDNS認証を確認する

ログにエラーが無いのに届かない場合、受信側で拒否されているか迷惑メールに振り分けられています。2024年2月以降、Gmailは送信ドメイン認証を満たさないメールの受信を制限しています。個人向けGmail宛でも影響を受けるため、認証設定は必須と考えてください。

Gmailのポリシーと必要な対策の詳細はGmailにEC-CUBEのメールが届かない・迷惑メールになる時の対策で解説しています。

DNSに設定するレコードの例です。

# SPF（実際に送信に使うサービスを include で並べる）
v=spf1 include:_spf.google.com include:spf.sendgrid.net ~all

# DMARC（まずは監視のみの p=none から始める）
v=DMARC1; p=none; rua=mailto:dmarc@example.com

設定できているかは、届いたメールのヘッダーで確認できます。Gmailなら「メッセージのソースを表示」を開き、Authentication-Resultsの行を探してください。spf=pass dkim=pass dmarc=pass が並んでいれば認証は通っています。

送信元アドレスのドメインをサイトのドメインに合わせる

意外に多いのが、送信元アドレスにフリーメールや無関係なドメインを設定しているケースです。SPFはそのドメインのDNSを参照して検証するため、自分で管理していないドメインを送信元にすると認証を通せません。

EC-CUBEでは管理画面の「店舗設定」で3つのアドレスを設定します。それぞれ役割が違います。

管理画面の項目	メールでの役割	注意点
送信元メールアドレス	From / BCC	サイトと同じドメインにする。SPF検証の対象
返信先メールアドレス	Reply-To	顧客からの返信を受ける窓口
エラー通知先メールアドレス	Return-Path	宛先不明の通知が届く。実在するアドレスにする

エラー通知先を放置していると、不達が起きても気づけません。運用しているアドレスを設定して、定期的に確認してください。

開発環境では実際に送信せず確認する

テスト中に顧客のアドレスへ誤送信すると取り返しがつきません。開発環境では送信内容をブラウザで確認できるツールに向けておくのが安全です。

# MailHog や Mailpit などローカルのSMTPサーバーへ向ける
MAILER_DSN=smtp://localhost:1025

この設定にしておくと、送られたメールは外部に出ず、ツールの画面で本文とヘッダーを確認できます。テンプレートの改修時にも役立ちます。

切り分けの順番

やることを順番に並べると、こうなります。

1. var/log/prod/のログを見て、送信エラーの有無を確認する
2. エラーがあればMAILER_DSNを修正し、キャッシュクリアする
3. エラーが無ければ、届いたメールのヘッダーでspfとdkimの結果を確認する
4. 認証が通っていなければDNSにSPF・DKIM・DMARCを設定する
5. 送信元アドレスがサイトのドメインと一致しているか確認する

この順番を守れば、設定を手当たり次第に変えて状況を悪化させることは避けられます。

EC-CUBEに関するお問い合わせ

[重要]現在公式にセキュリティサポートが切れていないPHPは8.1以上、MySQLは8.0以上で、対応しているEC-CUBEバージョンは4.2以上です。古いEC-CUBEを使っている方は適切なタイミングでバージョンアップをご検討ください。