滞留していたメールを再送したところ、“cannot resolve［宛先］”のエラーメールが返された。時間をおいて再送すると再現しない new!
EPSTDSサービスの停止などにより、メールキュー（incomingフォルダ）にメールが滞留した状態から回復した後、退避しておいた滞留メールの一部を再送したところ、「cannot resolve［宛先］」のエラーメールが返された。ただし、時間をおいて別のメールを同じように再送すると再現せず、正常に送信できた、というご報告をいただいたことがあります。
本記事では、このエラーメールが返される仕組みと、考えられる原因、確認するとよい点を説明します。なお、EPSTDSサービスが停止してメールが滞留した事例については、下記記事「メーリングリストを使ってのメール配送時にEPSTDSサービスが停止したことがある」を参照してください。
「cannot resolve」のエラーメールが返される2つのケース
E-Post（EPSTDSサービス）が外部ドメイン宛にメールを配送する際は、まず宛先ドメインのMXレコードを、続いてAレコードを参照して、接続先を決めます。この名前解決（DNS参照）は、リトライのたびに改めて行われます。
「cannot resolve」のエラーメールは、次のいずれかの場合に返されます。
・宛先ドメインの名前解決ができなかった場合
・送信先ドメインは存在するが、送信先のマシンへ接続できない状態が「リトライ期間（マシン無応答）」（デフォルト24時間）を過ぎるまで続いた場合
後者の場合は、送信先からの応答がなくエラーコードが得られないため、エラー理由は一律で名前解決エラーとして返されます（例："Unable to deliver to destination domain Cannot resolve xxxxx.jp"）。
つまり、エラーメールの表示だけでは、どちらが原因かを判別できません。いずれの場合も、設定されたリトライが行われたうえで、最終的に配送できなかった時点で送信者へエラーメールが返されます。
時間をおくと再現しない場合に考えられること
ご報告の事例のように、時間をおいて再送すると再現せず正常に送信できる場合は、メールの内容やE-Post側の設定に問題があったのではなく、該当する時間帯に、DNSサーバ自体の問題や、DNS参照の通信（ネットワーク）に一時的な問題があった可能性があります。
確認するとよい点
現象の発生した時間帯の前後について、次の点を確認してください。
1.配送ログで、失敗した時刻と理由を確認する
faillog（配送失敗ログ）とsenderlog（配送時の詳細ログ）で、該当メールのメッセージIDをもとに、配送に失敗した時刻と理由を確認します。
2.その時間帯に、DNSサーバの障害・再起動・応答遅延・高負荷がなかったか
E-PostのDNS参照は、次の2系統に分かれています。それぞれについて確認してください。
・MXレコードの参照 → Mail Control画面の「サーバ設定」タブにある「DNSサーバ」
・Aレコードの参照 → hostsファイル、続いてWindowsのネットワーク接続で設定されたDNSサーバ
なお、Mail Controlの「DNSサーバ」に対するEPSTDSサービスの問い合わせは、タイムアウト約5秒・リトライ4回で固定されています。
3.DNSサーバまでの経路（社内ネットワーク・上位回線）や、送信先サーバとの通信で、障害や輻輳がなかったか
4.同じ時間帯に、他のシステムでも名前解決やネットワーク起因の不具合が出ていなかったか
これらに該当する事象が確認できれば、その一時的な問題によって配送できず、「cannot resolve」のエラーメールが返されたもの、と切り分けられます。
一方、恒常的に「cannot resolve」のエラーメールが多発する場合は、一時的な事象ではなく、参照先DNSの設定や冗長性、名前解決経路の安定性そのものを見直す必要があります。この場合は、上記の確認結果とあわせて弊社サポートまでお問い合わせください。
（関連FAQ）
●リトライ回数やリトライ期間の設定について
●配送処理とDNS参照について
●メールサーバがDNSを参照するときの動きについて
●E-Postシリーズに設定するDNSサーバに対してEPSTDSサービスから行われるDNS問い合わせのタイムアウト時間とリトライ回数は？
●配送できなかったメールをログで確認する方法
●EPSTDSサービスが配送失敗時に生成するエラーメール "Delivery failure" はどういう形になるか
●メーリングリストを使ってのメール配送時にEPSTDSサービスが停止したことがある