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.

Want to see it first? Book a demo

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 standard that almost every email provider supports. That includes small business hosting like cPanel mail, which 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 are the newer option: the Gmail API for Google Workspace, and Microsoft Graph for Outlook and Microsoft 365. Some CRMs use them instead of, or beside, IMAP/SMTP. They tend to offer better rate limits, more reliable live updates, and an OAuth sign-in 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. To connect, you usually create that app password in the provider's account settings first, then paste 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 quick provider sign-in
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. Sort this out ahead of time. Otherwise you'll get a confusing connection error that looks like a CRM problem but is really 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 linked with an app password can quietly stop working if someone resets or revokes that password at the provider, 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, it's an app password or the account's normal login, 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 as a manual reply, an AI reply you've approved, or a cadence step. Which ones you get depends on the CRM and your team's settings.