Gmail SMTP in 2026: App Passwords, OAuth 2.0 and Google Workspace Relay for Web Apps

How should a web application, CMS or business system send email through Google in 2026? The old “less secure apps” setting is gone, but that does not mean SMTP itself has disappeared. This comprehensive, provider-neutral guide explains app passwords, OAuth 2.0, Google Workspace SMTP relay, security considerations, actual SMTP settings and common authentication failures, with examples suitable for PHP, Laravel and other stacks.

1. What changed: Google retired less secure app access

Historically, software could send through Gmail SMTP using the same username and password a person used to sign in. This legacy basic-authentication approach was retired for Workspace in 2025. There is no modern “Allow less secure apps” switch to restore it. A 16-character app password is a separate compatibility mechanism and OAuth 2.0 is a different, more modern authorization approach. Normal browser access to Gmail is not what was removed.

2. Four different approaches to email delivery

3. App passwords: eligibility and limitations

Google supports app passwords for accounts with two-step verification enabled. They are generally not available for accounts in Advanced Protection, accounts configured exclusively with security keys, or some organizational accounts. Workspace administrators can restrict options. An app password is not the preferred security model for a new integration; Google explicitly recommends Sign in with Google if supported. A compromised app password must be revoked, just like any other secret.

4. Step-by-step configuration for a CMS

1. Sign in to the Google Account authorized to send the mail.
2. Enable and confirm two-step verification in the account's security settings.
3. Open Google App Passwords; if the option is unavailable, investigate eligibility rather than lowering account security.
4. Generate a separate password labeled for the CMS or application and copy its 16-character value directly into a protected configuration field. Google only displays it once.
5. In your CMS admin, find outbound mail settings. Menu names differ between software products.
6. Use the host, port and security settings below. Save the secret securely without exposing it in logs or screenshots.
7. Send a test message to an authorized inbox; inspect the From header, replies and delivery status.
8. Revoke the credential when access is no longer needed or compromise is suspected.

Gmail SMTP settings

Port 587 starts in an SMTP connection that is upgraded using STARTTLS; port 465 begins with TLS immediately. Matching the port and the CMS security-mode selector is essential. Do not disable certificate checks to work around network failures.

5. Framework integration: PHP, Laravel, Node.js and multi-tenant CMS platforms

A Laravel mailer may use MAIL_HOST=smtp.gmail.com, MAIL_PORT=587 and an authorized account as username. A secret manager or protected environment configuration should supply the app password at runtime. The precise encryption scheme and mailer configuration depend on framework version and its mail transport, so validate against version-specific docs. In a multi-tenant CMS, each tenant should have properly segregated secrets, permissions, limits and sender identities. Never expose one tenant's credentials through another tenant's administrative screens or exports.

Protect backups, avoid printing SMTP credentials to logs, and account for cached configuration and long-running queue workers during credential changes.

6. Sender identity and Reply-To

Authenticating as [email protected] does not authorize arbitrary From headers. Gmail may reject or rewrite an unverified sender. Use the authenticated account, or a specifically configured and verified Google Send mail as address. Reply-To changes where responses go, not who authenticated the message or which domain authorized it.

7. Daily sending limits and spam protection

Google documents roughly 500 outbound messages per day for a standard personal Gmail account. Workspace quotas vary by subscription, connection method, and administrative settings. These limits are not reserved capacity; suspicious bursts, bounces and policy violations can throttle or temporarily block a sender. Gmail's reputation is not a guarantee that each delivered message avoids spam filtering.

8. Troubleshooting common failures

9. Securing SMTP credentials

Create distinct app passwords for each application; do not reuse credentials across unrelated systems or tenants. Store them in a secret manager or restricted encrypted configuration and never send them through chat or tickets. Google can revoke app passwords when the main account password changes. Limit who can view or edit the mail settings and test a revocation process in a non-production environment.

10. OAuth and Workspace SMTP relay alternatives

OAuth 2.0 should be preferred for supported applications. A custom integration can require a Google Cloud project, approved consent flow and token handling; an off-the-shelf solution may already provide its own integration. For organizations, Google also recommends smtp-relay.gmail.com, which must be configured in Workspace Admin with appropriate sender restrictions, authentication or authorized IPs. Switching from Gmail SMTP to relay requires more than swapping one hostname.

11. Final production checklist

1. Ensure the sending account is controlled and two-step verification is active.
2. Choose app password only if eligible and OAuth is unavailable.
3. Confirm SMTP hostname, port, TLS and certificate validation.
4. Validate the sender identity and any aliases.
5. Keep credentials encrypted, access controlled and excluded from logs.
6. Perform delivery tests and monitor failures and volume.
7. Document credential rotation and revocation.
8. Assess whether Gmail limits and policies fit the intended workload.

12. WordPress: configure Gmail using an SMTP plugin

WordPress normally routes mail through wp_mail(). An SMTP plugin can configure how that mail is delivered without rewriting every contact form or notification plugin. Popular choices include WP Mail SMTP and other established mailer plugins. Exact menu labels depend on plugin version.

1. Install an actively maintained SMTP plugin from the official WordPress repository, check permissions and updates, then open its mailer settings.
2. If the plugin supports Google's OAuth integration and your use case permits it, prefer that method. Some plugins provide a guided connection; others require Google Cloud credentials.
3. For the generic SMTP option, use smtp.gmail.com, port 587 with STARTTLS (or 465 with implicit TLS), authentication enabled, the full Gmail address as username and an eligible Google app password as the secret.
4. Set the From address to the authenticated Gmail address or an authorized Google Send mail as alias; check whether the plugin's Force From option would override other legitimate mailers.
5. Send a test email, verify received headers and replies, and check contact-form, registration and password-reset messages.

A plugin does not increase Gmail's sending limits or guarantee inbox placement. For personal Gmail accounts Google documents a limit around 500 outgoing messages a day, with additional recipient and anti-abuse restrictions; Workspace limits depend on plan and method. Google's official limits apply whether a CMS or a user initiates the messages.

13. CMS with built-in SMTP settings: no extra plugin required

Some CMS platforms include outgoing mail configuration directly in their administrative interface, so an SMTP plugin is unnecessary. A relevant example is MuseDock CMS, whose evolving CMS configuration can provide mail transport settings as a built-in feature. This is an illustrative product mention, not a claim that every version has identical menus or that app-password support has been verified in every deployment. Confirm the installed build's supported encryption modes and test-email behavior.

The general workflow remains: open the authorized administrator's mail settings; select SMTP; set Gmail's host, port and STARTTLS; provide a dedicated app password if eligible; enter an authorized From identity; save securely and send a controlled test. For multi-tenant applications, credentials and sending quotas must be isolated between organizations. The 500/day personal Gmail guideline is an account constraint, not a per-tenant or per-plugin allowance.

Never share an app password with a developer through chat, disable two-step verification, or bypass TLS validation to make a connection work. If high-volume or business-critical mail is required, move toward Google Workspace relay or a dedicated transactional sender with appropriate monitoring.

WordPress SMTP plugin and Gmail limits

WordPress can deliver mail using a maintained SMTP plugin such as WP Mail SMTP. Configure Google's OAuth integration when supported, or generic SMTP using smtp.gmail.com, port 587 with STARTTLS (alternatively 465 with implicit TLS), full Gmail username and an eligible app password. The authorized From identity, test email, form notices and password recovery flows should all be checked. A plugin cannot bypass Google's personal Gmail limit of approximately 500 outgoing messages daily; Google Workspace limits vary. Google limits.

Built-in SMTP configuration without plugins

CMS platforms may integrate mail transport settings in their core administration. The new MuseDock CMS, under development, includes an integrated approach to outgoing mail instead of requiring an SMTP plugin. Confirm the settings supported by the installed release; do not assume availability in every version. Configure a protected credential, TLS and an authorized sender, test delivery, and isolate credentials between organizations. The Google account limit applies across applications sharing that account.

Primary sources

• Google Account Help: app passwords
• Google Workspace: less secure apps transition
• Google Developers: SMTP and OAuth support
• Google Workspace: send email from apps and devices
• Gmail: sending limits
• Google: Advanced Protection

Example CMS admin URL and practical mail-settings walkthrough

A CMS with built-in email transport may expose a settings page such as https://example.com/admin/settings/email. This is a fictional illustrative path, not a verified URL for every CMS release. Sign in with an authorized administrator account. If a “Use global mail server” checkbox is available, disable it only if the site or tenant should use its own SMTP account rather than the shared global configuration.

Enable account security and test

1. Open Google Account Security and enable two-step verification.
2. Visit App Passwords if eligible, label the credential “Web CMS”, and copy it directly into the protected administration field.
3. Save the CMS mail settings, then use its built-in test function when available.
4. Verify delivery, sender identity, form notifications and password-reset emails; examine redacted SMTP errors if necessary.

SMTP app-password authentication does not require a Google Cloud project. A custom OAuth flow may. If the app-password menu is missing, investigate account eligibility, two-step verification, Advanced Protection, security-key-only settings and Google Workspace policies; do not assume an administrator can always enable app passwords. Ordinary Gmail personal-account sending limits are around 500 messages per day, subject to Google's other restrictions and changes.

Applicable beyond one CMS

The same configuration pattern applies to WordPress with an SMTP plugin, CMS platforms with built-in outgoing email, and custom software. The navigation labels differ. MuseDock CMS is an example of a new CMS under development with an integrated outgoing-mail configuration concept, without a separate mail plugin. Confirm the actual settings supported by the installed release.