メール送信時にCCへ自分のアドレスを指定すると、自分宛てのメールが届かないことがある new!
過去のサポート事例では、Toの宛先には届いているものの、CCに指定した自分のアドレスには届かない事象が報告されたことがあります。この事例では、配送リトライ用フォルダにデータが滞留し、EPSTRSとEPSTDSのサービス再起動後に配送が再開しました。
ただし、再起動で復旧したことだけでは原因は確定できません。サポート回答では、内部ドメインの名前解決と同報時のセッション分離設定を確認し、必要な設定後に動作を確認することを提案しています。
【ToとCCの違いが原因か】
ToであれCCであれ、メールサーバにとって同報配送の対象であることは同じです。「自分をCCに指定したこと」自体が原因と確認されたものではありません。ToとCCの宛先ドメインや配送経路が異なる場合は、一方が配送済みであっても、もう一方がリトライ状態となっている可能性があります。
【holding／domainsフォルダの役割】
holdingとdomainsは配送リトライ関係のフォルダです。両方のフォルダに対応するデータが一時的に退避されます。配送リトライが発生する一般的なケースとして、接続相手先から400番台や500番台で拒絶された場合が挙げられますが、名前解決ができない場合や、名前解決に時間がかかる場合でも配送リトライ処理が行われることがあります。
domainsフォルダには、エンベロープ情報を持つ.rcpファイルとともにDomain.mriファイルが作成されます。配送リトライに入った際にDomain.mriを確認し、「Err-code: 0」となっている場合は、名前解決がスムーズにできていない可能性を優先して確認します。この値だけで原因を確定するものではありません。
receivelogに「MoveFileEx successed」が記録されていても、それだけでCC宛ての最終配送完了を判断しないでください。リトライ情報や配送側のログも併せて確認します。
【内部ドメインの名前解決を確認する】
E-Postシリーズでは、内部ドメインをhostsファイルへ記述することを必須事項として案内しています。CCに指定した自分のアドレスが内部ドメインの場合は、そのドメインの記述があるか、内容が現在の環境と一致しているか確認してください。具体的な記述方法は関連FAQ10-53を参照してください。
【EPSTDSの同報セッション分離設定】
報告された環境ではEPSTDS 4.77が使用されていました。ゲートウェイ先指定時の同報処理について、EPSTDS 4.76までの旧来バージョンではセッションを分離することが既定でしたが、4.77以降は分離しない設定へ既定値が変更されています。
本来、同報先に異なるドメインが含まれる場合は、送信処理の都合上、結果的にセッションが分離されて配送されるはずです。サポート回答では、名前解決やリトライとの組み合わせで、何らかの課題により最初のセッション分離が正常に行われなかった可能性を挙げています。ただし、本事例の原因として確定したものではありません。
【確認・対処手順】
- 現象発生時のログと、holding／domainsにある該当メールのリトライ情報を確認します。Domain.mriのErr-codeなどを記録し、内部ドメインの名前解決に問題がないか調べます。
- hostsファイルへの内部ドメインの記述を確認します。未設定の場合はFAQ10-53に従って設定し、その後の動作を確認します。
- FAQ17-74を参照し、EPSTDSのレジストリ設定でセッション分離を指定します。IncludeForwardをDWORD値として作成し、値を0に設定した後、EPSTDSを再起動します。設定場所や適用条件は同FAQで確認してください。
- 使用しているモジュールが古い場合は、適用可能な差分アップデートを確認します。2026年4月16日のサポート回答では20251218差分を案内しましたが、その時点での最新公開版と対象製品を確認してください。
- Toに相手先アドレス、CCに自分のアドレスを指定して送信し、CC宛ての配送状況やリトライデータの滞留が改善するか確認します。改善しない場合は、採取したログと設定情報をサポートへ提示します。
レジストリ変更とサービス再起動は業務への影響を考慮して実施してください。変更前の設定を記録し、必要に応じてバックアップを取得してください。リトライデータは未配送メールに関係するため、原因調査や対処として安易に削除しないでください。
【復旧と原因究明を分けて考える】
本事例ではEPSTRSとEPSTDSの再起動後にincomingおよびholdingのデータが流れ、現象が解消しました。しかし、これは復旧結果であり、incoming内の滞留だけが原因であったことや、再起動のみで再発を防げることを示すものではありません。名前解決、セッション分離、配送リトライの状況を確認し、設定変更後の動作を継続的に確認してください。
（関連FAQ）
●リトライ処理が行われるときの情報とフォルダについて
●hostsファイル記述の必要性と有用性について
●クライアントからのメール送信が遅いケースとhostsファイルの必要性
●内部宛と外部宛の同報メールを送信すると内部宛メールが遅延してしまう
●同報時のリトライ処理の流れはどのように行われるか