How to connect a mailbox to a CRM

IMAP/SMTP and a provider API are the two common mechanisms. Both pull email threads into the CRM. The difference shows up in setup complexity, rate limits, and what breaks first.

An admin approves every new account by hand. Nothing is created until then. We reply by email; no newsletter, no sequence.

app.salescrew.io/inbox
The unified reply inbox with classified threads

The short answer

  • Mailbox connections work through one of two mechanisms. IMAP/SMTP, a long-standing protocol that works with nearly any provider, including cPanel-hosted mail. Or a provider-specific API (Gmail API, Microsoft Graph for Outlook) that requires an OAuth login rather than a password.
  • IMAP/SMTP connections generally use an app-specific password rather than a normal account password. Most providers now block plain password authentication for third-party apps as a security measure.
  • A provider API connection is authorized through the provider's own OAuth screen. The CRM never handles or stores the account's password, only a token it can revoke later.
  • Whether several team members can act on the same shared mailbox (a support@ or sales@ address) depends on the CRM's design. Not every CRM supports a genuinely shared inbox model.

Why there are two different mechanisms, not one

IMAP/SMTP is an old, universal protocol supported by essentially every email provider, including small business hosting like cPanel-based mail that has no modern API at all. A CRM that supports IMAP/SMTP can connect almost any mailbox. That is why it remains the fallback mechanism even in tools that also offer provider-specific APIs.

Provider APIs (the Gmail API for Google Workspace accounts, Microsoft Graph for Outlook and Microsoft 365) are a more modern alternative that some CRMs use instead of, or beside, IMAP/SMTP. They tend to offer better rate limits, more reliable real-time updates, and OAuth authorization instead of a stored password. The trade-off is that they only work with that provider. IMAP/SMTP works everywhere a provider still exposes it.

Most providers have moved away from allowing a plain account password for third-party IMAP access. They require an app-specific password generated separately instead. This is a security measure on the provider's side, not a CRM limitation. The connection step usually involves generating that app password inside the provider's own account settings before entering it into the CRM.

IMAP/SMTP versus a provider API

IMAP/SMTPProvider API (Gmail API, Microsoft Graph)
Works withNearly any provider, including cPanel-hosted mailOnly that specific provider
AuthenticationApp-specific passwordOAuth token, no password stored
Setup complexitySometimes requires generating an app password manuallyUsually a one-click provider login
Real-time updatesPolling-based, small delay possibleOften faster, sometimes push-based

What to check once a mailbox is connected

Confirm both sending and receiving work, not only one direction. Some setups connect for reading threads but need a separate step for sending to be enabled. Send a real test email and reply to it from an external address. Confirm the reply lands in the CRM's inbox view, not only in the mailbox's own webmail. If the mailbox will be used for a shared team inbox, confirm the CRM supports several people acting on it. Do not assume a personal-mailbox connection behaves the same way.

Two-factor authentication on the mailbox account is worth checking before connecting. Some providers require an app-specific password precisely because 2FA is enabled. Others block IMAP/SMTP entirely until 2FA is turned on and the app password is generated through it. Sorting this out ahead of time avoids a confusing failed-connection error that looks like a CRM problem but is a mailbox security setting.

Disclosure: SalesCrew is our product. It connects mailboxes via IMAP/SMTP, covering Gmail, Outlook and cPanel-hosted mail through the same mechanism. It supports a shared inbox with threads, drafts, snooze and SLA tracking for several team members on one connected mailbox. It does not use the Gmail or Microsoft Graph APIs directly. IMAP/SMTP is the mechanism for every provider.

A stale app password is a common silent failure

A mailbox connection using an app-specific password can stop working quietly if that password is regenerated or revoked on the provider's side, sometimes weeks later. Check for a connection health warning periodically. Do not assume a mailbox that worked at setup still does.

Questions

What credentials does connecting a mailbox actually need?
For IMAP/SMTP, an app-specific password or the account's regular credentials, depending on the provider's security settings. For an API connection (Gmail, Outlook), an OAuth authorization the user grants through the provider's own login screen. The CRM never sees the password.
Can more than one person connect the same shared mailbox?
It depends on the CRM's design. Some support a shared inbox where several team members see and act on the same connected mailbox. Others tie each mailbox connection to one user. Confirm which model a CRM uses before assuming a shared support@ or sales@ mailbox will work the way you expect.
Does connecting a mailbox let the CRM send email as that address automatically?
Once connected for sending, yes. The CRM can send from that mailbox, through a manual reply, a drafted-and-approved AI reply, or an automated cadence step, depending on what the CRM and the team's own settings allow.