Connecting email accounts: BYOC, explained
Every account you connect — the inbox campaigns actually send from — goes through the Accounts page. SubsiMail supports three connection methods.
Three ways to connect
| Gmail | OAuth, via a Google Cloud app you register yourself |
| Outlook / Microsoft 365 | OAuth, via an Azure AD app you register yourself |
| SMTP/IMAP | Any provider that gives you SMTP + IMAP credentials — Amazon SES, Zoho, a custom mail server, etc. |
Why Gmail and Outlook need "your own app" (BYOC)
Most cold-email SaaS tools connect to Gmail/Outlook through their own shared OAuth app. That requires Google/Microsoft to review and verify the app for sensitive scopes — a slow process, and it means every customer's mail flows through the vendor's registered identity.
SubsiMail avoids that by having you register a small OAuth app under your own Google Cloud or Azure account, then connecting through it:
- No app review/verification needed — a Testing-mode Google consent screen and a single-tenant Azure app are both exempt from the strict review process, regardless of the scopes requested
- The connection uses your own API quota, under your own account
- SubsiMail (the company) never sees your OAuth app's credentials or your inbox — they're stored only in your own instance's database
The tradeoff is a one-time setup step per provider: creating that app in Google Cloud Console or Azure Portal. It's about 10 clicks, and Connect Gmail / Connect Outlook walk through every one with screenshots.
Which one should you use?
Use Gmail or Outlook OAuth if that's where your sending inbox actually lives — it's the more robust option since reply detection and sending both go through the provider's real API. Use SMTP/IMAP for anything else: a transactional-email provider like Amazon SES, a custom domain mailbox, or any provider that doesn't offer OAuth at all.