Gmail SMTP test — ports, App Passwords, troubleshooting

Gmail's SMTP submission servers are at smtp.gmail.com, available on port 587 (STARTTLS) and port 465 (implicit TLS). Both are equally secure: 587 upgrades the connection after EHLO while 465 negotiates TLS immediately on connect. Gmail does not accept unencrypted submission on port 25, so that port is not an option for testing.

Use your full @gmail.com (or Google Workspace) email address as the SMTP username. The "From" address must match the authenticated account or an alias configured in Gmail settings, otherwise Gmail rejects the message.

Recommended settings

If you want a broader primer on how these handshake tests work before you run one, the guide on what an SMTP test is covers the stages in detail.

Setting up an App Password

Google blocks basic password authentication for accounts with 2-Step Verification enabled. You must generate an App Password instead:

1. Go to myaccount.google.com and sign in.
2. Open Security and, if you have not already, enable 2-Step Verification. App Passwords only appear once it is on.
3. On the Security page, find App passwords (search "App passwords" in the account settings search box if you cannot spot it).
4. Give the password a name (the name has no technical effect) and click Create.
5. Google shows a 16-character password grouped in fours. Copy it exactly: you will not see it again.
6. Paste it (without spaces) as the SMTP password in SMTP Tester.

Two things block people here. First, 2-Step Verification must be active before the App Passwords option exists at all. Second, Google Workspace admins can disable App Passwords for the whole organization, in which case the option never appears for managed accounts even with 2FA on. Ask your admin before trying workarounds.

A note on the old "Less secure apps" toggle: it no longer exists. Google retired it in 2024 and now requires app passwords or OAuth2 for any external SMTP client. If a tutorial still tells you to flip that switch, the instructions are out of date.

Testing with SMTP Tester

1. Enter smtp.gmail.com as the host and select port 587.
2. Security auto-sets to STARTTLS (or choose 465 with TLS).
3. Enter your Gmail address as both the username and the "From" address.
4. Paste your App Password into the password field.
5. Set the "To" address: use the same address to send to yourself.
6. Click Run. The live transcript shows every SMTP line: EHLO, STARTTLS upgrade, AUTH LOGIN, and the server's 235 response on success.

A 235 2.7.0 Accepted response means authentication passed. If you send a message, a 250 2.0.0 OK with a queue ID confirms Gmail accepted it for delivery.

What each transcript stage means

Reading the transcript makes failures obvious fast:

• Connect + TLS: the TCP connection opens and either TLS is negotiated immediately (465) or Gmail advertises STARTTLS in the EHLO response and the client upgrades. If this stage stalls, a firewall is usually the cause, not Google.
• EHLO → 250: the client greets the server and Gmail replies with its capabilities (AUTH PLAIN LOGIN XOAUTH2, SIZE limit, pipelining). A 250 here confirms routing to Gmail works.
• AUTH → 235: credentials accepted. 235 2.7.0 Accepted is the line you want; 535 or 534 means the App Password is wrong or missing.
• MAIL FROM / RCPT TO → 250: Gmail accepted the envelope. Rejections here point at a mismatched From address or a non-existent recipient.
• DATA → 354 → 250: the server accepts the message body after a 354 go-ahead, then returns 250 2.0.0 OK with a queue ID. Gmail accepted the message and will deliver it asynchronously.

Common errors

535 5.7.8 "Username and Password not accepted"

This is the most common Gmail SMTP error. Causes:

• Using your regular Google password instead of an App Password when 2FA is enabled.
• The App Password was copied with extra spaces or truncated.
• The account is suspended or locked.
• A Workspace admin policy blocks app password access for the organization.

Fix: generate a fresh App Password, copy all 16 characters without spaces, and try again. The deeper walkthrough lives in fixing SMTP authentication error 535.

534 5.7.9 "Application-specific password required"

Same root cause as 535: the account has 2-Step Verification but you provided the account password rather than an App Password.

550 5.4.5 "Daily user sending quota exceeded"

This is Gmail's daily quota error, not an authentication failure. You have hit the per-account sending cap and Gmail will keep rejecting outgoing messages until the rolling window resets, typically within 24 hours. SMTP Tester's handshake-only mode (no message sent) will still pass while this error is active, which is a useful way to confirm credentials are fine.

421 rate-limit responses

421 4.7.0 with text about "try again later" or too many connections is a temporary throttling signal. Google also applies automatic throttling before you hit the hard cap: bursts of very rapid sends, a sudden spike from a normally quiet account, or too many concurrent SMTP sessions can all trigger slower acceptance or temporary rejections. The remedy is the same either way: stop sending, wait, and spread volume out. Retrying aggressively makes throttling worse, not better.

Connection timeout

If the transcript shows no server greeting:

• Port 25 is blocked for Gmail (and most residential and cloud networks). Switch to 587 or 465.
• A corporate firewall may block outbound 587. Try port 465 instead, or ask IT to allow smtp.gmail.com on 587/465.

550 5.7.0 "Mail relay denied" or "Recipient address rejected"

Gmail SMTP is not an open relay. The authenticated account must be allowed to send to the chosen recipient. If you see relay errors, confirm the "From" address matches the authenticated account (or an alias) and that the recipient exists.

Message size: the 16 MB limit

Gmail caps outgoing messages at roughly 25 MB in the web interface, but SMTP submission has a stricter effective ceiling: messages around 16 MB (about 16,000,000 bytes after encoding) get rejected during the DATA stage. This limit also applies to messages you receive and try to forward or reply to with large inline attachments. There is no setting that raises it.

When you exceed it, the session typically fails mid-DATA with a size-related rejection rather than a clean SMTP code. Practical fixes:

• Compress attachments or move files to Drive/Cloud Storage and send links.
• Let your mail client split large attachments.
• Move bulk or automated sending to a transactional provider such as SendGrid, which supports larger payloads and higher volume.

If you are testing with SMTP Tester, the built-in test templates are tiny, so the 16 MB limit will never be the thing that fails your test.

Google Workspace vs personal @gmail.com

The hostname is the same, but the behavior differs:

Workspace accounts have an additional server-side option: smtp-relay.gmail.com on port 587 with STARTTLS, authenticated by whitelisted IP addresses or TLS certificates instead of usernames and passwords. The admin configures this in the Google Admin console under Gmail routing settings. For application-to-application sending from a fixed server, SMTP relay is usually the cleaner path than app passwords.

Sending limits and throttling

Gmail applies two layers of control: automatic throttling and daily sending caps. Exact caps vary per account type and are not published as a single number: they depend on whether the account is free Gmail or Workspace, account age, and Google's internal abuse signals. The commonly cited figures (a few hundred messages per day for free accounts, more for Workspace) are directional, not contractual.

What is consistent:

• Limits count across all send paths: SMTP, the Gmail web UI, and the API share one quota.
• Exceeding a cap produces 550 5.4.5 (quota) or 421 (temporary) errors.
• Locked accounts can be temporarily blocked from sending entirely after suspicious activity, such as a volume spike or connections from an unusual location.

For production volume beyond a handful of messages, use a dedicated transactional provider instead of smtp.gmail.com. Gmail is designed for human mailboxes, not application sending.

OAuth2 as the modern alternative

App Passwords work today, but XOAUTH2 (OAuth 2.0 SASL mechanism) is where Google is pushing everything. With OAuth2, your application obtains a short-lived access token from Google and authenticates with the XOAUTH2 mechanism instead of a static password. Gmail advertises AUTH XOAUTH2 in its EHLO response.

Why it matters:

• No long-lived credential to leak or rotate manually.
• Scoped access: the token grants mail-send permission, not the whole account.
• Workspace admins increasingly mandate it.

The trade-off is setup complexity: you need a Google Cloud project, an OAuth client, and a token refresh flow. For a quick connectivity test, an App Password is faster. For a long-lived integration, OAuth2 is worth the initial work.

Testing with Nodemailer

The fastest way to confirm Gmail works from your own code is a short Nodemailer script:

const nodemailer = require("nodemailer");

const transporter = nodemailer.createTransport({
  host: "smtp.gmail.com",
  port: 465, // or 587 with secure: false
  secure: true, // true for 465, false (with STARTTLS) for 587
  auth: {
    user: "you@gmail.com",
    pass: process.env.GMAIL_APP_PASSWORD, // 16-character App Password
  },
});

transporter.verify().then(() => {
  console.log("SMTP connection and auth OK");
}).catch((err) => {
  console.error("SMTP test failed:", err.message);
});

transporter.verify() opens the connection, negotiates TLS, and authenticates without sending a message, which mirrors SMTP Tester's handshake-only mode. Keep the App Password in an environment variable, never in source control. If the script throws EAUTH, the credentials are the problem; if it throws ETIMEDOUT or ECONNREFUSED, look at the network path first.

Security notes

• Always use STARTTLS (587) or implicit TLS (465). Never disable encryption.
• SMTP Tester redacts your password from the live transcript, so the output is safe to share or screenshot.
• Do not store App Passwords in plain text in codebases. Use environment variables or a secrets manager.
• Revoke app passwords you no longer use from the same Google Account settings page where you created them.

Frequently asked questions

Why is my Google account locked after testing SMTP?

Sudden bursts of SMTP connections or sends from an unfamiliar IP can trigger Google's abuse detection. The account usually gets a temporary sending block rather than a full suspension. Stop automated attempts, wait 24 hours, and resume at a normal pace. Repeated triggers can escalate to a full lockout that requires account recovery.

My Workspace admin disabled App Passwords. What now?

Managed accounts follow admin policy. Ask your admin to either allow app passwords for your organizational unit or issue you an alternative, such as SMTP relay access or an OAuth2-based integration. There is no user-side workaround, and trying to bypass admin policy violates Workspace terms.

Port 587 or 465 for Gmail: which should I pick?

Both are encrypted and both work. Choose 587 with STARTTLS if your client or library supports it explicitly; choose 465 if your network blocks STARTTLS upgrades or your framework expects implicit TLS. Gmail treats them identically for authentication and quotas. The detailed comparison is in SMTP port 587 vs 465.

Can I use my normal Google password for SMTP?

No, unless the account has 2-Step Verification disabled, which Google strongly discourages. With 2FA on, the account password always fails at AUTH and you need an App Password or OAuth2.

Does the 16 MB limit apply to the whole message?

Yes. The limit covers headers, body, and all attachments after MIME encoding, which inflates binary attachments by roughly a third. A 12 MB attachment can push the encoded message past the ceiling.

What is the difference between testing smtp.gmail.com and smtp-relay.gmail.com?

smtp.gmail.com authenticates a user mailbox with a password or OAuth token. smtp-relay.gmail.com authenticates by source IP or certificate and is configured by a Workspace admin for server-side sending. Your SMTP test tool needs different credentials for each, so test the one your application will actually use.

Related guides

• What is an SMTP test?
• SMTP authentication failed: fixing error 535
• SMTP Tester vs smtper.net
• Outlook / Microsoft 365 SMTP test