Find Your IMAP and SMTP Settings (All Providers)

If you’re wiring up a CRM, shared inbox, or an automation workflow and got stuck at “Enter IMAP/SMTP server,” this guide is for you. I’ll show you exactly how to find the right server names, ports, and security options for major providers, how to verify they work, and how to deploy them safely in your business without wrecking deliverability or getting blocked.

Three acronyms run most business email connections: IMAP, SMTP, and POP3. In plain terms, IMAP handles reading and syncing mail from the server to your device or app. SMTP sends mail out. POP3 downloads messages and (often) removes them from the server. For almost every modern workflow - CRMs, helpdesks, automation tools - IMAP + SMTP is the right combo.

IMAP shines because it keeps mail on the server and syncs across devices. That means your sales lead who replied from a phone will also see the thread on their laptop and in the shared inbox. POP3, by contrast, is legacy: it’s simpler but single-device oriented and can create version drift. If business continuity, team access, and auditability matter (they do), avoid POP3 except for edge cases.

SMTP is your outbound rail. It’s how your app hands off a message to the mail server for delivery. In most business setups you’ll use the “submission” port with encryption, authenticate as a user, and observe rate limits. One important distinction: SMTP relays for bulk marketing or transactional messages are a different beast than user-submitted SMTP for personal or team inboxes. Don’t mix the two if you care about sender reputation.

Email pipes run hot with policy. Providers are (rightly) strict about authentication and transport security. Expect to use TLS/SSL and modern authentication wherever supported. At a minimum, make sure your IMAP connection uses port 993 with SSL/TLS and SMTP uses 587 with STARTTLS or 465 with implicit TLS. Plain ports (143 for IMAP, 25 for SMTP) are either blocked or heavily filtered in most business networks.

If your account uses two-factor authentication (2FA), you may need an app-specific password for IMAP/SMTP - Gmail, iCloud, Yahoo, and others enforce this. Microsoft 365 prefers OAuth (Modern Auth) and has disabled basic authentication for IMAP/POP in most tenants. They still allow SMTP AUTH for specific mailboxes if you enable it, but OAuth-based connections are the safer long-term bet.

Finally, lock down credential storage. If you’re connecting a CRM or automation tool to IMAP/SMTP, use per-user credentials or OAuth, not a single shared password sprinkled across tools. Document who owns each connection and rotate app passwords when people leave. It’s boring ops work that saves you when things go sideways.

There are industry-standard ports that just work across providers. While some services support multiple options, stick to these defaults unless official docs say otherwise. They maximize compatibility and minimize weird TLS errors in legacy networks.

For IMAP, use 993 with SSL/TLS. For SMTP submission, use 587 with STARTTLS or 465 with SSL/TLS. Avoid port 25 for application sending; many ISPs block it, and most providers expect 587/465 for authenticated submission. POP3, if you must, is 995 with SSL/TLS.

One more note: “SSL/TLS” vs “STARTTLS.” Implicit TLS (465/993/995) starts the connection encrypted. STARTTLS (commonly 587 for SMTP) begins unencrypted, then upgrades to TLS. Both are secure when properly configured; follow your provider’s recommendation.

Google Workspace and Gmail

For Gmail and Google Workspace, IMAP is typically imap.gmail.com (port 993, SSL/TLS) and SMTP is smtp.gmail.com (port 587 with STARTTLS or 465 with SSL/TLS). In Gmail settings (on the web), go to Settings > See all settings > Forwarding and POP/IMAP, then enable IMAP. In Google Workspace Admin, ensure IMAP/POP are allowed for users if you enforce admin policies.

Authentication: If you have 2-Step Verification enabled (you should), you’ll likely need an app password for basic IMAP/SMTP connections. Some tools support Google OAuth - prefer that if available. “Less secure app access” is deprecated, so plan on OAuth or app passwords, not plain passwords.

Common gotcha: Workspace admins sometimes disable IMAP for security. If your login works in Gmail but fails in your CRM, check the admin console policy first.

Microsoft 365 (Exchange Online) and Outlook.com

For Microsoft 365 business: IMAP server is usually outlook.office365.com (port 993, SSL/TLS). SMTP server is smtp.office365.com (port 587, STARTTLS). POP3 is outlook.office365.com (995, SSL/TLS) if enabled. Microsoft has moved most tenants to Modern Auth (OAuth), so basic IMAP authentication may be disabled. Your app should support OAuth for IMAP/SMTP, or you can enable SMTP AUTH per mailbox in the admin center.

For Outlook.com personal accounts, common servers are imap-mail.outlook.com (993, SSL/TLS) and smtp-mail.outlook.com (587, STARTTLS). If you use a custom domain through Microsoft 365 Family/Personal, double-check your plan’s support for IMAP/SMTP clients.

Common gotcha: “535 5.7.3 Authentication unsuccessful” with SMTP. This often means SMTP AUTH is disabled for the mailbox or conditional access blocks legacy auth. Check the Microsoft 365 admin settings and consider OAuth-capable tooling.

Apple iCloud Mail

IMAP: imap.mail.me.com (993, SSL/TLS). SMTP: smtp.mail.me.com (587, STARTTLS). POP3 is generally not recommended. If you use 2FA on your Apple ID (you should), create an app-specific password at appleid.apple.com and use it instead of your main password in clients.

iCloud is strict about app passwords - without one, you’ll loop on “incorrect password.” Generate it, label it for the app (e.g., “CRM IMAP”), and store it securely.

Common gotcha: Some clients auto-fill ports incorrectly. Manually set 993 for IMAP and 587 for SMTP if auto-detect fails.

Yahoo Mail

IMAP: imap.mail.yahoo.com (993, SSL/TLS). SMTP: smtp.mail.yahoo.com (465 SSL/TLS or 587 STARTTLS). Yahoo requires app passwords for third-party clients when 2FA is enabled.

Make sure “Allow apps that use less secure sign-in” settings are not relied on - use app passwords. Also note Yahoo’s IMAP limits on concurrent connections per account; reduce the “maximum connections” setting in your client if you hit throttles.

Common gotcha: “Invalid credentials” after enabling 2FA - this is actually missing app password, not your main password being wrong.

Zoho Mail

IMAP: imap.zoho.com (993, SSL/TLS). SMTP: smtp.zoho.com (465 SSL/TLS or 587 STARTTLS). POP3: pop.zoho.com (995, SSL/TLS) if you must. In Zoho Mail’s web settings, confirm IMAP access is enabled for the user.

If you use Zoho with 2FA, generate and use an app-specific password for IMAP/SMTP. OAuth may be available depending on your tool - prefer it if supported.

Common gotcha: Region-specific domains (e.g., .eu). Use the correct regional server names if your tenant is in the EU or elsewhere.

Proton Mail (via Proton Mail Bridge)

Proton Mail is end-to-end encrypted and doesn’t expose direct IMAP/SMTP servers for standard clients. You’ll need Proton Mail Bridge on your desktop, which creates local IMAP/SMTP endpoints (e.g., 127.0.0.1 ports) that your email client uses. The Bridge decrypts/encrypts locally and talks to Proton’s infrastructure securely.

This works for desktop clients. For headless servers or cloud automation, Proton offers different products (e.g., Proton Mail Gateway) rather than raw IMAP/SMTP.

Common gotcha: Trying to connect a cloud CRM directly to Proton without Bridge - it won’t work. Use native Proton integrations or a supported gateway.

Fastmail

IMAP: imap.fastmail.com (993, SSL/TLS). SMTP: smtp.fastmail.com (465 SSL/TLS or 587 STARTTLS). Create an app password in Fastmail’s Settings for third-party clients and assign appropriate scopes.

Fastmail is straightforward, but mind quotas and connection limits for heavy IMAP use. For team inboxes with many concurrent clients, consider shared folders and client-side limits.

Common gotcha: Using your domain as the server name instead of Fastmail’s hostname. Stick to imap.fastmail.com and smtp.fastmail.com unless Fastmail instructs otherwise.

cPanel, Plesk, and Other Hosting-Provider Mailboxes

Most shared hosting control panels publish IMAP/SMTP details right in “Email Accounts” > “Set Up Mail Client.” The usual pattern is mail.yourdomain.com for both IMAP and SMTP, using 993 and 465/587 respectively with SSL/TLS. If your provider offers “Autodiscover” or “Autoconfig,” modern clients can detect settings automatically.

Watch for self-signed certificates on low-cost hosts. If your TLS certificate doesn’t match the hostname, some clients will warn or fail. Align your client hostname with the certificate’s common name (often the provider’s shared mail server) to avoid trust errors.

Common gotcha: ISPs blocking outbound port 25. Always use 587 or 465 for authenticated SMTP submission.

Self-Hosted (Postfix/Dovecot, On-Prem Exchange)

If you control the server, your settings are whatever you configured - but document them. For Dovecot IMAP, typical is 993 with TLS; for Postfix SMTP submission, 587 with STARTTLS. For on-prem Exchange, you’ll often use your public hostname (e.g., mail.company.com) with proper certificates and 587/993 exposed through your firewall.

Check your MX records to confirm external reachability, and ensure your firewall/NAT and reverse proxy (if any) are configured for TLS offload correctly. Renew certificates automatically with ACME if possible, and test from external networks.

Common gotcha: TLS mismatch after a certificate renewal - clients caching old intermediates. Restart services and confirm the full certificate chain is served.

If you inherited a domain and don’t know who hosts mail, start with MX records. They point to the provider handling inbound email. From that, you can infer the IMAP/SMTP hostnames or find the right docs. Use dig or nslookup on any platform.

Examples:

dig MX yourdomain.com
nslookup -type=MX yourdomain.com

Look for recognizable patterns: Google (aspmx.l.google.com), Microsoft (yourdomain.mail.protection.outlook.com), Zoho (mx.zoho.com), Fastmail (in1-smtp.messagingengine.com), and various hosters. For Microsoft 365, Autodiscover (autodiscover.yourdomain.com) may be set via CNAME/SRV records and helps smart clients configure automatically.

Before wiring a CRM, test the raw connections from your machine. This confirms network reachability and TLS. Use OpenSSL for IMAP 993 and SMTP 587 with STARTTLS.

Examples:

# Test IMAP over SSL/TLS
openssl s_client -connect imap.gmail.com:993 -quiet

# Test SMTP with STARTTLS
openssl s_client -starttls smtp -connect smtp.office365.com:587 -crlf -quiet

You should see a valid certificate chain and a 220 SMTP banner. If the handshake fails or the certificate is invalid, fix that before proceeding. On Windows, Test-NetConnection is handy: Test-NetConnection smtp.office365.com -Port 587.

Most CRMs and helpdesks offer two ways to integrate mail: OAuth-based native connectors (recommended) and generic IMAP/SMTP. If available, OAuth wins because it avoids storing passwords and respects tenant-level security policies. If you must use IMAP/SMTP, create per-user app passwords, keep scopes minimal, and store them in a secrets manager.

When connecting your CRM for “Send as user,” use SMTP submission (587/465) with your mailbox credentials. For shared inboxes, consider a dedicated mailbox and grant the team access in the CRM to reduce connection thrash. For logging inbound mail, IMAP IDLE improves near-real-time sync but consumes connections - scale carefully.

If your CRM is part of a broader revenue stack (marketing automation + outbound), unify the system-of-record. For example, if you’re implementing HubSpot or similar and need reliable mail sync, plan the credential strategy up front, not after the first missed reply. If you’re building or replatforming CRM infrastructure, see our CRM implementation services for a pragmatic approach that covers auth, logging, and governance.

Short context if you’re new here: Anton Chisliuk · AI Marketing Ops is an AI-first outsourced marketing operator. One senior person sets up HubSpot, outbound infrastructure (think 600 daily cold emails across warm domains), AI SEO, and automation - no account-manager buffer. Proof matters: for Cleverence (B2B SaaS), we grew from 0 to 80K organic visits/month and 2K inbound leads/month. If you want the operator alternative to the classic agency-tax retainer, skim how we work on the About page.

IMAP/SMTP is perfect for user-level sending and shared inbox replies. It’s not ideal for bulk campaigns. If you blast sequences or newsletters through your primary mailbox SMTP, you’ll hit rate limits and harm domain reputation. Keep three lanes: user mail (IMAP/SMTP), transactional (dedicated SMTP/API), and marketing (dedicated platform) with domain/subdomain segmentation and proper DNS.

At minimum, publish SPF, DKIM, and DMARC for your domains. Use a dedicated subdomain (e.g., mail.yourbrand.com) for automation tools that send at scale, and warm it up. Separate transactional (e.g., receipts) from marketing (e.g., promotions) to avoid collateral damage.

If deliverability is revenue-critical, design the architecture first - then connect tools. Random IMAP/SMTP hookups after the fact create blind spots and bounces you only notice when the pipeline slows.

Authentication failed: If 2FA is enabled, you likely need an app-specific password. For Microsoft 365, verify whether basic auth is disabled and whether SMTP AUTH is allowed for the mailbox. Prefer OAuth where possible.

Connection timed out or blocked: ISPs often block port 25; use 587 or 465. Corporate firewalls may block 993/587 outbound - ask IT to allow them. Test from a different network to isolate the issue.

TLS/Certificate errors: Ensure the hostname you connect to matches the certificate’s CN/SAN. On shared hosts, use the provider’s hostname (e.g., secureXX.hostingprovider.com) published in their docs, not mail.yourdomain.com, if the cert doesn’t cover your domain.

Too many simultaneous connections: IMAP servers cap concurrent connections per account. Reduce the number of client connections or disable IDLE in some clients. For shared inboxes, limit how many devices poll simultaneously.

“535 5.7.3 Authentication unsuccessful” (Microsoft 365): Check mailbox-specific SMTP AUTH toggle, conditional access, and whether you’re using the right tenant/UPN. Try OAuth in a supported client if available.

“Application-specific password required” messages: Generate an app password (Gmail, iCloud, Yahoo, Fastmail) and use it in your client. Your normal password won’t work once 2FA is on.

If you’re the one fixing this now, do your future self a favor and document the final configuration. When someone joins (or leaves), you’ll avoid credential archaeology and failed logins.

Capture the following for each mailbox and tool that connects via IMAP/SMTP:

• Provider, mailbox address, and mailbox owner
• IMAP server, port, encryption; SMTP server, port, encryption
• Auth method: OAuth vs app password; who can refresh tokens; where credentials are stored
• Connection limits and sync frequency (especially for shared inboxes)
• Deliverability lane: user, transactional, or marketing; DNS in place (SPF/DKIM/DMARC)
• Incident procedure: who to call, how to rotate credentials, where logs live

Store this in a secured, shared location. Add a quarterly reminder to validate tokens and rotate app passwords where policy requires.

Server-side tools (Make, n8n, scripts) bring convenience and risk. They run 24/7, so a single misconfiguration can hammer an inbox, hit rate limits, or trigger lockouts. Use dedicated mailboxes for automations and keep scopes tight. If the tool supports OAuth with your provider, use it to avoid hardcoded secrets.

When you wire actions like “watch IMAP for new messages” or “send via SMTP,” throttle thoughtfully. Add retries with backoff and send guards that respect your provider’s limits. Log everything - outbound IDs, server responses, and errors - so you can debug without guessing.

If you’d rather have a clean, supportable setup done once, our team handles this routinely as part of marketing operations. See how we build reliable workflows in our marketing automation services.

Start by identifying your provider via MX or admin consoles. Confirm IMAP/SMTP are allowed for your use case. Decide on auth (prefer OAuth; if not possible, use per-user app passwords). Establish standard ports and encryption, then test connections with OpenSSL or within a test mailbox in your client.

Next, map your email lanes - user, transactional, marketing - and make sure your intended use aligns with the right SMTP. Configure SPF/DKIM/DMARC and choose subdomains where needed. Don’t plug your CRM into a marketing SMTP that shares reputation with blasts.

Finally, integrate tool by tool. For CRMs or helpdesks, use native connectors when available. For generic apps, use IMAP 993 + SMTP 587/465 with the correct hostnames, and store credentials in a secrets manager. Document everything and set a calendar reminder to review quarterly.

Finding your IMAP/SMTP details isn’t guesswork. Use provider docs and DNS signals, stick to secure ports, prefer OAuth or app passwords, and validate with a quick TLS test. Separate your sending lanes so deliverability stays healthy when you scale.

If you want someone to own the whole email stack - CRM sync, shared inboxes, outbound infrastructure - without agency overhead, we can help. See our approach to email outbound infrastructure and get a practical plan you can run next week. Authored by Anton Chisliuk.

- What are the correct IMAP and SMTP ports?

Use IMAP 993 (SSL/TLS) and SMTP 587 (STARTTLS) or 465 (SSL/TLS). Avoid port 25 for authenticated sending - many networks block it and providers expect 587/465 for submission.

- Do I need an app password for Gmail, iCloud, or Yahoo?

If 2FA is enabled, yes - most providers require app-specific passwords for IMAP/SMTP in third-party clients. Some tools support OAuth; if available, use OAuth and skip app passwords.

- Why does Microsoft 365 IMAP fail with my password?

Microsoft disabled basic auth for IMAP/POP across most tenants. Use OAuth-based connections. For SMTP, enable SMTP AUTH per mailbox if needed, but prefer OAuth when your app supports it.

- Can I send marketing campaigns via my mailbox SMTP?

You can, but you shouldn’t. You’ll hit rate limits and hurt domain reputation. Use a dedicated marketing platform or SMTP designed for volume and sign with SPF/DKIM/DMARC on a suitable subdomain.

- How do I find my email provider if I only know the domain?

Check MX records with dig or nslookup. The MX hostnames usually reveal the provider (Google, Microsoft, Zoho, etc.). From there, use their published IMAP/SMTP settings.

- What’s the difference between SSL/TLS and STARTTLS?

SSL/TLS on ports like 993/465 starts encrypted from the first byte. STARTTLS (commonly on 587) upgrades a plain connection to TLS. Both are secure when implemented correctly - follow your provider’s guidance.

- Why does my client say “too many connections” with IMAP?

IMAP servers limit concurrent connections per account. Reduce the number of clients polling simultaneously, lower the max connections per server in your client, or use shared folders rather than multiple full-account connections.

- Is POP3 still okay to use?

For modern teams, POP3 is rarely appropriate. It’s download-and-delete by default and doesn’t sync state across devices. Use IMAP for multi-device and team workflows.