Open main menu
SOS I Land in SPAM

Gmail IMAP Settings: Ports, Login and Errors

Gmail IMAP settings: imap.gmail.com, port 993, SSL/TLS, plus the SMTP pair. Covers app passwords, Workspace admin limits and fixes for common login errors.

Published on

•

Updated

•

Gmail IMAP Settings: Ports, Login and Errors

Table of Contents

Do not index
Do not index
Incoming mail uses imap.gmail.com on port 993 with SSL/TLS, outgoing mail uses smtp.gmail.com on port 465 with SSL or port 587 with TLS/STARTTLS, and both require authentication. Whether an IMAP toggle or an app password is needed depends on the account type and administrator policy.
That distinction matters when a desktop client, phone, script, or help desk tool keeps rejecting a login that works in the browser. The hostnames are usually right in the screenshot the user sends. The failure is more often the encryption pairing, the sign-in method, or a Google Workspace rule that never appears in the client at all.
Table of Contents
Gmail IMAP Settings at a GlanceWhy the Port and Encryption Pair Cannot Be MixedHow the Fields Map in a Typical ClientHow to Enable IMAP in Gmail SettingsWhy the Enable IMAP Toggle May Be MissingHow to Verify ItChoosing App Passwords or OAuth for Gmail IMAPWhat OAuth Does DifferentlyWhen an App Password Is the Right ToolHow to Verify ItGoogle Workspace Admin Controls for IMAP AccessThree Layers That Get ConfusedQuestions to Bring to a Google Workspace AdministratorHow Gmail Labels Appear as IMAP FoldersWhat Deleting From a Label Folder Actually DoesWhy Folder Counts Can Stop Short of the Full MailboxTroubleshooting Gmail IMAP Login and Encryption ErrorsWeb Login RequiredToo Many Simultaneous ConnectionsEncryption and Port MismatchHow to Verify ItCommon Gmail IMAP Mistakes to AvoidCredential MistakesServer Field MistakesPolicy and Account MistakesFrequently Asked Gmail IMAP QuestionsDoes One Client Need Both IMAP and SMTP ConfiguredIs OAuth or an App Password the Better ChoiceWhy Does a Google Workspace Account Show No IMAP ToggleCan the IMAP Connection Test Run From the ChatGPT App

Gmail IMAP Settings at a Glance

Gmail IMAP settings split into two independent pairs. IMAP synchronizes messages and folders from Gmail to the client. SMTP submits outbound messages from the client to Gmail. A client that receives correctly can still fail to send, and the reverse is also true, because each side has its own host, port, encryption mode, and authentication check.
Purpose
Host
Port
Encryption
Authentication
Incoming IMAP
imap.gmail.com
993
SSL/TLS
Required
Outgoing SMTP
smtp.gmail.com
465
SSL
Required
Outgoing SMTP
smtp.gmail.com
587
TLS/STARTTLS
Required
Google's official configuration specifies these values, with Google's Gmail server configuration for IMAP and SMTP listing imap.gmail.com over encrypted port 993 and smtp.gmail.com on port 465 for SSL or port 587 for TLS or STARTTLS. Both SMTP options require authentication. Values can depend on region, plan, or a recent change, so a reader setting up a production integration should confirm them in Google's official Gmail help before relying on them.

Why the Port and Encryption Pair Cannot Be Mixed

A port number alone doesn't describe the connection. Port 993 without SSL doesn't match Google's documented configuration, even though the hostname and port look correct in isolation. The client opens a connection expecting one handshake, Gmail expects another, and the session fails before authentication is even attempted. The error in the client often says only that the server disconnected or that the connection timed out, which sends people toward passwords when the real fault is the transport.
The same logic applies on the sending side. Port 465 uses implicit SSL, where encryption starts as soon as the connection opens. Port 587 uses TLS or STARTTLS, where the client connects and then upgrades to an encrypted session. They're not interchangeable in every client, because the encryption dropdown and the port field have to agree. Selecting 587 with an SSL-only mode, or 465 with STARTTLS, produces a sending failure that has nothing to do with the username.

How the Fields Map in a Typical Client

Most clients ask for an incoming server and an outgoing server on separate screens or tabs. The incoming screen takes imap.gmail.com, 993, and SSL/TLS. The outgoing screen takes smtp.gmail.com, then either 465 with SSL or 587 with TLS/STARTTLS, with the option that the outgoing server requires authentication turned on.
Readers who aren't sure which values a provider publishes can look them up with the mailX IMAP finder, which returns the host, ports with encryption, and the provider's setup guide without asking for credentials. For the sending half, the outgoing pair can be tested separately with an SMTP connection check, so a receiving problem and a sending problem don't get debugged as if they were one fault.

How to Enable IMAP in Gmail Settings

Setup starts in the Gmail web interface, not in the client. A client configured perfectly still can't synchronize a mailbox where IMAP access isn't available, so the account side gets checked first.
  1. Open Gmail Settings. Sign in to Gmail in a browser and open the settings panel.
  1. Click See all settings. The quick settings panel doesn't contain the IMAP controls.
  1. Open Forwarding and POP/IMAP. This tab holds the incoming access options.
  1. Select Enable IMAP and save. The change doesn't take effect until it's saved.
notion image

Why the Enable IMAP Toggle May Be Missing

Older guides treat that toggle as a universal step. It isn't anymore. Google's current documentation describes a transition by account type, and Google Workspace administrator help on IMAP and OAuth access states that Google Workspace accounts must use OAuth for third-party access beginning May 1, 2025, while Gmail's consumer help says the Enable/Disable IMAP option is being removed, with IMAP access always enabled for affected accounts.
A missing toggle can therefore be expected behavior rather than evidence of a broken mailbox. Diagnosis starts with a different question. Is the account consumer Gmail, or is it Google Workspace under an administrator? For consumer Gmail, an absent toggle usually means there's nothing to switch on and the client configuration is the place to look. For Google Workspace, an absent or ineffective toggle points to administrator policy, which sits outside the user's own settings screen.
That branch saves real time. Without it, a user on a managed account can spend an hour reinstalling a client and resetting a password for a restriction that only an administrator can change. Confirming the account type takes a minute and tells the reader whose settings control the outcome.

How to Verify It

Run an IMAP connection test with the mailX IMAP checker using imap.gmail.com, port 993, and SSL/TLS for a mailbox the reader controls. The checker only works when the user explicitly asks to test a login for a mail account they control and provides its credentials. The password is used only to run the test and is redacted before the request is saved.
A passing result shows connection, encryption, and authentication all succeeding, which means IMAP is reachable and the client can be configured with the same values. A failure at connection or encryption points back to the port and encryption pair. A failure at authentication, after connection and encryption pass, points to the sign-in method or to administrator policy, and that's the fork the next two sections resolve.

Choosing App Passwords or OAuth for Gmail IMAP

Once IMAP is available, the client still has to prove who's signing in. Gmail IMAP settings cover where to connect. Authentication decides whether that connection is allowed to open the mailbox, and there are two working patterns.

What OAuth Does Differently

OAuth 2.0 through the SASL XOAUTH2 mechanism sends an access token with the IMAP AUTHENTICATE XOAUTH2 command rather than a stored account password. The mailbox scope is https://mail.google.com/. The client obtains the token through a Google sign-in flow, presents it to Gmail, and refreshes it before it expires. No long-lived account password sits in the client's settings file.
Google documents OAuth as the supported authorization model for Gmail IMAP access, and app passwords are generally unnecessary when OAuth is available. For Google Workspace, OAuth isn't a preference after the date covered earlier. It's the required route for third-party access, and administrators can further restrict which OAuth clients are approved.
An implementation validates the TLS certificate and hostname, refreshes access tokens before expiry, and treats an AUTHENTICATE failure as distinct from a network failure. It also avoids logging tokens or credentials, because a token in a log file is as useful to an attacker as a password in one.

When an App Password Is the Right Tool

An app password is a separate credential generated for one client that can't use Google's sign-in flow. It requires 2-Step Verification on the Google account. Without 2-Step Verification enabled, the app password option isn't available, which is why some readers go looking for a menu that their account doesn't show.
Method
Requirement
Best fit
OAuth 2.0 XOAUTH2
Client supports Google sign-in
Modern desktop, mobile, and application clients
App password
2-Step Verification enabled
Older or limited third-party clients without OAuth
The decision rule is short. Prefer OAuth when the client supports it. Use an app password, with 2-Step Verification enabled, only when the client doesn't. Entering the regular account password into a client that expects one of these two methods is the single most common reason a correct hostname and port still produce a login rejection.
One limit deserves emphasis. An app password doesn't override a Google Workspace administrator restriction. If an administrator has disabled IMAP or limited access to approved OAuth clients, a freshly generated app password fails the same way the account password did.

How to Verify It

Run the mailX IMAP checker with the chosen method's credential for a mailbox the reader controls. A passing authentication step confirms the method works against imap.gmail.com and the same credential can go into the client. An authentication failure alongside a passing connection and encryption result points to the credential or the method itself, not to the port, so the fix is to switch method or regenerate the credential rather than edit server fields.

Google Workspace Admin Controls for IMAP Access

A Google Workspace account can reject a login when every client field is correct. That's not a contradiction. It means a layer above the client is making the decision.
notion image
Google Workspace administrators can enable or restrict IMAP at the organizational unit level. They can allow only approved OAuth mail clients, and they can allowlist specific OAuth client IDs. When an administrator disables IMAP or third-party access for a user, the client fails to log in even though imap.gmail.com, port 993, and SSL/TLS are exactly right.

Three Layers That Get Confused

Separating the layers keeps the diagnosis honest.
  • The mailbox interface. What the user sees in Gmail settings, including whether an IMAP toggle appears at all.
  • Administrator policy. What the Google Workspace administrator allows for the user's organizational unit, including OAuth-only access and approved client lists.
  • The client configuration. Host, port, encryption, and the credential the client presents.
A failure can originate in any one layer and look identical in the client, which usually reports only that the login was rejected. Changing settings in the third layer can't fix a restriction in the second. That mismatch explains the familiar loop where a user re-enters the same correct values, gets the same rejection, and concludes the password must be wrong.

Questions to Bring to a Google Workspace Administrator

A short, specific request gets resolved faster than a screenshot of a generic error.
  • Is IMAP enabled for the organizational unit this account belongs to?
  • Must the client be approved on an OAuth allowlist, and is this client on it?
  • Is OAuth required for third-party access on this account, and are app passwords permitted at all?
  • Has anything changed recently in the policy for this organizational unit?
Menu names in the administrator console can differ by edition and change over time, so this guide doesn't name a single menu path as permanent. Readers should confirm current names and locations in Google's Workspace administrator documentation. Google also exposes IMAP configuration through the Gmail API's ImapSettings resource, including whether IMAP is enabled, which gives administrators a diagnostic route that doesn't depend on the end user's client.
Once an administrator confirms IMAP is permitted and the client is approved, a remaining failure belongs to the client layer. At that point the port, encryption, and credential checks in the surrounding sections are the right tools.

How Gmail Labels Appear as IMAP Folders

A successful connection often raises a second confusion. The folder list in the client doesn't look like the label list in Gmail, and message counts don't match the web view. Both are normal consequences of how Gmail maps its own model onto IMAP.
Gmail organizes mail with labels, not folders. Over IMAP, each label appears as a folder. A message carrying three labels appears in three IMAP folders, because each folder is a view of messages with that label rather than a separate stored copy. The client shows what looks like duplication. Gmail holds one message with three labels attached.

What Deleting From a Label Folder Actually Does

Deleting a message from a label folder removes that label. It doesn't necessarily delete the message. The message remains in Gmail under its other labels and in All Mail, which surprises readers who empty a client folder and then find the same messages still present in the browser. Deletion of the message itself happens through the Trash, not by clearing every label view one at a time.
Gmail's system areas appear over IMAP with these names.
  • [Gmail]/All Mail holds every message in the mailbox, archived or not.
  • [Gmail]/Sent Mail holds messages Gmail has sent.
  • [Gmail]/Trash holds deleted messages.
Production clients need to tolerate these names rather than assume a conventional folder tree. They should also avoid duplicating Sent messages. Gmail already stores a server-side copy of a sent message, so a client configured to save its own copy to a sent folder produces two copies of everything. Turning off the client's save-to-sent behavior for Gmail accounts removes the duplicate.

Why Folder Counts Can Stop Short of the Full Mailbox

Google provides a folder-size limit option that caps IMAP synchronization at no more than 10,000 messages per folder. The cap reduces initial-sync load and client timeouts on large mailboxes. It also means a capped folder doesn't represent the complete mailbox, so a client count that falls short of the Gmail web view isn't necessarily an error.
Applications syncing Gmail should use incremental synchronization and persist the last-known UID or synchronization state per folder. Fetching an entire large folder on every run is slow, fragile, and a reliable way to hit timeouts that look like server faults. Reading only what changed since the last state keeps the sync proportional to new activity instead of total mailbox size.

Troubleshooting Gmail IMAP Login and Encryption Errors

Client logs give exact strings, and exact strings are worth matching before any setting changes. Three patterns account for most Gmail IMAP failures, and each has a different cause, so each has a different fix.
notion image

Web Login Required

Cause. The error Web login required means the client can't complete the browser sign-in Gmail expects. The connection reaches Gmail, but the authentication method doesn't satisfy the account's requirements.
Check. Confirm whether the client supports Google sign-in, and whether the account is consumer Gmail or Google Workspace. For managed accounts, the related guidance on how to fix mailbox quota sync problems helps separate a sign-in block from a synchronization stall that produces similar user complaints.
Fix. Switch to OAuth where the client supports it, or to an app password with 2-Step Verification enabled where it doesn't. On a Google Workspace account, confirm administrator policy first, because neither method helps if IMAP or the client itself isn't approved. Readers tightening account access after a lockout may also find account security advice for small businesses useful context for why sign-in controls have become stricter.

Too Many Simultaneous Connections

Cause. Gmail limits an account to as many as 15 email clients at one time, and many simultaneous connections can trigger the error Too many simultaneous connections, as documented in Google's Gmail help on simultaneous IMAP connections. Phones, laptops, tablets, background workers, and stale sessions all count against the same allowance.
Check. Count every device and application signed in to the mailbox, including retired phones and test scripts that were never shut down. An integration that opens a fresh connection per task without closing the previous one consumes the allowance on its own.
Fix. Close or sign out of unused clients, which is the remedy Google recommends. This limit also explains why an IMAP test succeeds in isolation while a production application fails intermittently under load.

Encryption and Port Mismatch

Cause. The port and encryption pair doesn't match, such as port 993 with no SSL, or 587 paired with an implicit SSL mode. The session fails during the handshake, before credentials are evaluated.
Check. Read the client's encryption dropdown next to the port field, not just the port. The two fields are often on different parts of the same screen, and changing one doesn't always update the other.
Fix. Use port 993 with SSL/TLS for incoming mail, and port 465 with SSL or port 587 with TLS or STARTTLS for outgoing mail, matching the table in the opening section.

How to Verify It

After each single change, run the mailX IMAP checker again before retesting the full client. Confirm that connection and encryption succeed first, then look at authentication. Changing one variable at a time keeps the result interpretable. Changing the port, the password, and the client in one step leaves no way to know which change fixed the fault, or introduced a new one.

Common Gmail IMAP Mistakes to Avoid

The assumption underneath most failed setups is that the account password always works. It doesn't, and several other assumptions fail alongside it. Each mistake below pairs a symptom with a one-line correction.

Credential Mistakes

  • Regular password in the client. The symptom is a clean connection followed by a rejected login. The correction is to use OAuth or an app password, per the comparison above.
  • 2-Step Verification left off. The symptom is that no app password option exists in the account. The correction is to enable 2-Step Verification first, then generate the app password.
  • Stale saved password. The symptom is a login that worked for months and then stopped after a password change. The correction is to replace or revoke the saved credential in every client, not just the one in front of the user.

Server Field Mistakes

  • SMTP host in the IMAP field. Entering smtp.gmail.com as the incoming server, or imap.gmail.com as the outgoing server, produces a connection to the wrong service. The correction is to put each host in its own field, since IMAP synchronizes incoming mail and SMTP submits outgoing mail.
  • Wrong port and encryption pair. The symptom is a handshake failure that looks like a network outage. The correction is to align port and encryption as a pair rather than editing the port alone.
  • Missing SMTP authentication. Receiving works, sending is refused. The correction is to enable authentication on the outgoing server, since both Gmail SMTP options require it.

Policy and Account Mistakes

  • Expecting a client setting to override an administrator. On Google Workspace, no client-side change lifts an organizational unit restriction or adds a client to an OAuth allowlist. The correction is an administrator request, not a reinstall.
  • Hunting for a toggle that no longer exists. On affected consumer accounts the Enable/Disable IMAP option has been removed and IMAP is always enabled. The correction is to move on to the client fields.
  • Leaving too many clients signed in. The symptom is intermittent rejection under load. The correction is to sign out unused clients so active ones stay within Gmail's allowance.
Detection splits cleanly by direction. The mailX IMAP checker covers incoming connection, encryption, and authentication. The mailX SMTP test covers outgoing submission. Running the check that matches the failing direction avoids the common detour of re-entering a working incoming configuration while the outgoing pair stays broken.

Frequently Asked Gmail IMAP Questions

Does One Client Need Both IMAP and SMTP Configured

Yes. IMAP handles incoming synchronization through imap.gmail.com, while SMTP submits outgoing messages through smtp.gmail.com. Configuring only IMAP produces a client that receives and cannot send. Configuring only SMTP produces the reverse. Readers who need the sending side in depth can follow mailX's Gmail SMTP settings guide for the outgoing values and their authentication requirements.

Is OAuth or an App Password the Better Choice

OAuth is the better choice whenever the client supports Google sign-in, because the client presents an access token instead of storing an account password. An app password, which requires 2-Step Verification, suits clients that cannot use that flow. On Google Workspace accounts, administrator policy may remove the choice entirely by requiring OAuth for third-party access.

Why Does a Google Workspace Account Show No IMAP Toggle

A Google Workspace account may show no IMAP toggle because access is controlled by the administrator for the user's organizational unit rather than by the user. Consumer Gmail is also removing the Enable/Disable IMAP option, with IMAP always enabled for affected accounts. A missing toggle therefore calls for an account-type check, not a mailbox repair.

Can the IMAP Connection Test Run From the ChatGPT App

No. The SMTP and IMAP connection tests are not offered in the ChatGPT app, because those tests take mailbox credentials. Readers can run them through the mailX web tools, the REST API, or the MCP server instead. The mailX IMAP finder is separate and never asks for credentials, since it only returns published host and port settings.
Run the mailX IMAP checker on a mailbox under the reader's control to confirm that connection, encryption, and authentication succeed against imap.gmail.com on port 993, free with no signup, and credentials aren't stored. Teams working through AI agents can reach the same check through the REST API or MCP server from Claude or Cursor. Start at mailX and fix the one failing step the result names.

Most senders lose 30–70% of their emails to spam without knowing it.

Get a free expert audit of your domain, email authentication, and infrastructure. Identify hidden issues and fix them fast.

Book Your Free Deliverability Audit