Start with the mailbox behavior your users need, then choose Gmail, Microsoft Graph, IMAP/SMTP, or a unified layer without confusing mailbox sync with transactional delivery.
A mailbox integration reads and changes a user's existing mailbox. A transactional email provider sends product notifications from infrastructure you control. They have different identity, consent, synchronization, and deliverability requirements.
Use Gmail API for Google mailboxes and Microsoft Graph for Outlook and Microsoft 365. IMAP handles mailbox access for other providers, while SMTP submission handles sending; IMAP itself does not send mail.
Decide whether each action needs delegated user access or an administrative application permission. Request the least privilege possible and plan for Google verification or Microsoft administrator consent when the selected permissions require it.
A sellable integration must survive pagination, expired cursors, token revocation, duplicate notifications, deleted messages, and provider throttling. Test those states with real accounts before calling the connector complete.
No. A single-provider product may be simpler with that provider's official SDK. A unified layer earns its cost when several providers must share one account, message, event, and error model.
No. IMAP covers mailbox access, but sending requires SMTP and provider APIs expose capabilities, identities, change streams, and administrative controls that IMAP cannot standardize.
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.