配送のリトライが配送詳細で設定した内容より２分ほどずれて送られていることがあるのはなぜか new!
配送リトライ期間の設定「リトライ期間（マシン無応答）」でデフォルト設定（24時間後）にしているが、23時間58分後に送信された。2分ずれたのはなぜかという質問を受けたことがあります。
仕様面と考えられる点を説明します。
まず、リトライ期間（時間）のカウントは、E-Post Mail Server へのメール着信時間に依存しますので、メールがサーバ内に保存されたタイムスタンプからの累計時間となります。
--------------------------------------------------------
（※参考）E-Post Mail Server（SMTP）での処理の略図
epstrd［SMTP受信サービス］
（一時フォルダ temp フォルダ）
↓
（配送キューincomingフォルダ） ←
epstdd［SMTP配送サービス］ ↑
↓ ↑※incomingへ
↓→→配送のリトライ処理待ち→↑
↓ （domains/holdingフォルダ）
↓
--------------------------------------------------------
他のメールが配送キューやリトライ関係フォルダにメールが溜まっていたりすると、配送開始の順番待ちで配送の開始が遅延することがあります。
（※配送キューのincomingフォルダ、配送リトライ関係のdomains/holdingフォルダ、詳細な動きに関しては下記FAQ記事参照)
メール着信直後に1回目の配送が始まっているとは言い切れませんので、その点のタイムラグはどうしてもある前提で確認する必要があります。
なお、疎通ができない状態ですと、記録は接続タイムアウトで終了してからの記録を取ることになるので、タイムラグはどうしても発生してしまいます。
また、SMTP受領サービス側（epstrd）とSMTP配送サービス側（epstdd）の両者は内部通信で”連動をしていない”という意味で、いわゆる非同期で動作していることを前提として認識してください。
epstrd/epstdd 両者が同期しないなら、なぜSMTP受信と配送が継続して行われているのかという点について説明します。
epstdd は単にメールキューであるincomingフォルダにメールデータが存在しているかどうかを判定して配送動作に入ります。
ですので、通常SMTP受領後、メールキューであるincomingにメールデータとしてファイルが生成され存在していれば、配送側に通知が届いたタイミングで送信がされます。
メールキューであるincomingフォルダにメールデータファイルとして存在していない状態のとき、例えば書き込みが遅延しディスクキャッシュにまだとどまっている状態などメールデータが実態として見つからない場合は、ひとまずSMTP配送サービスである epstdd の処理スレッドは終了します。
その場合、次の配送リトライタイミング（デフォルト2分後）に配送トライされるといった2分程度のタイムラグはどうしても発生する可能性があります。
この場合の改善方法としては、SMTP配送サービス側（epstdd）のスレッド数をデフォルト値（30）より例えば50〜100程度に増やしてみると、配送のタイムラグが改善される場合があります。
そのほか、epstdd の［詳細］ボタンで呼び出せる「配送詳細（SMTP）」の「リトライ間隔のまま」チェックボックスをオンにすれば、2分の定間隔で送信を必ずおこなう指定となり、配送のタイムラグがかなり改善される場合もあります。
（関連FAQ）
●リトライ処理が行われるときの情報とフォルダについて
●リトライを待たずに手動で強制的に実行させる方法
●内部アカウントどうしの送信しかない環境のためリトライ回数・リトライ期間を最小限にしたい
●「リトライ間隔のまま」チェックボックスの意味について