Short answer: treat a failed email as an evidence problem before treating it as a retry problem. Record the request identity, timestamp, recipient, provider response, and the later delivery event. Retry only failures that can plausibly change. An invalid address will not become valid because the worker tried five more times.

For a customer-support contact form, I would keep the first send path small: submit once, persist a structured attempt record, and poll delivery events through GET /v1/email/event/list . The important design choice is the boundary between transient and permanent failure. That boundary protects deliverability, keeps the queue quiet, and gives an operator enough evidence to explain what happened.

How should I handle error logging and retry strategies for failed email?

A request can fail before an email exists, after the provider accepts it, or later when a mailbox rejects it. Those are different incidents. A timeout around the send call does not prove that no message was accepted.…