Sending from a user's mailbox and sending product mail are separate architectures; choose the identity and delivery evidence first, then design composition, safety, retries, and result semantics.
Use Gmail, Microsoft Graph, or SMTP submission when the message must appear in a connected user's mailbox. Use a transactional delivery provider for application notifications from domains the product operates.
Accept structured sender identity, recipients, subject, text and HTML alternatives, attachments, reply context, and an idempotency key. Validate addresses, size, authorization, and suppression before enqueueing.
Persist the send intent, perform the provider call once under a lease, record its acknowledgement, and publish the result. Retry only when the prior outcome is known or safely deduplicated.
Queued, submitted, provider-accepted, delivered, bounced, opened, and replied are not interchangeable. Only expose later states when there is provider-supported evidence, and never infer an open from a successful send response.
Yes, if the first provider result is unknown. Require an idempotency key and retain the command and provider acknowledgement so a retry can return the original result.
No. It means only what the API documents at submission time, typically that the provider accepted the request. Final delivery is a later and separate outcome.
Not yet. Gmail, Microsoft Graph, and IMAP/SMTP connectors are planned. This guide documents the intended architecture and the provider requirements a production release must satisfy.
DewEngine is in development. Real use cases decide what ships first.