Monitor ZoneMTA queues and recover deferred delivery
Correlate queued bodies and recipient delivery work, inspect deferred causes, and avoid duplicate submissions or destructive database cleanup.
Reviewed
ZoneMTA persists outgoing work and retries delivery. A successful submission is not proof that every recipient has accepted the message; inspect queue and recipient-level outcomes before retrying from the application.
Establish operational evidence
- Follow queue/logging and optional web-admin guidance in the official repository.
- Record the application’s send intent and returned queue/message correlation before interpreting later delivery state.
- Monitor queue age, per-destination deferrals, storage capacity, worker health, and MongoDB/Redis connectivity.
- Separate recipient rejection, remote throttling, TLS/DNS failures, and local dependency problems.
The upstream architecture stores message bodies with queue metadata and reference relationships. Do not manually remove database records or blobs as a generic cleanup step; that can lose outstanding mail or break referential assumptions.
Recover deliberately
Fix the underlying destination/worker problem before forcing delivery. Use the supported operator tools and approve actions that retry or remove real messages. An application resend can duplicate a still-queued original.
Back up persistent queue/configuration state consistently and rehearse a compatible isolated restore. Prevent restored workers from delivering the same queue alongside production. If a separate receiving service handles replies, its event identities and retry policy remain distinct from ZoneMTA’s outbound queue; do not use an incoming-event replay to justify another outgoing send automatically.