QUICK ANSWER

For a basic Google Workspace email integration, provide the integration team with the SMTP server smtp.gmail.com, port 587, STARTTLS encryption, your complete Google Workspace email address, and the required sender address. Authentication should preferably use Google OAuth. If the application does not support OAuth, a dedicated Google App Password may work when 2-Step Verification is enabled and organizational policy permits it.

Do not provide your normal Google account password. For servers, business applications, printers, monitoring systems, and higher-volume organizational use, ask your Google Workspace administrator to configure Google’s recommended SMTP relay service at smtp-relay.gmail.com.

Google Workspace SMTP Details for Email Integration: Complete Setup Guide

What Is Google Workspace SMTP Integration?

SMTP, or Simple Mail Transfer Protocol, allows an application, website, server, printer, or business system to send email.

A Google Workspace SMTP integration can be used for:

• Website contact-form messages
• Password-reset emails
• System alerts and monitoring notifications
• Invoices and order confirmations
• Help-desk notifications
• Printer and scanner emails
• Application reports
• Internal workflow notifications

SMTP integration normally provides outgoing email only. Receiving or reading messages requires another method, such as IMAP, POP, or the Gmail API.

What Information Should You Give the Integration Team?

Before sharing credentials, ask whether the application supports Google OAuth or requires traditional SMTP authentication.

For a basic authenticated SMTP integration, provide the following information:

A typical configuration looks like this:

SMTP Server: smtp.gmail.com
Port: 587
Encryption: STARTTLS
Authentication: Required
Username: notifications@example.com
Password: Google App Password
From Email: notifications@example.com
From Name: Example Company Notifications

Replace the sample domain and address with your actual information.

Additional Information the Integration Team May Need

Depending on the application and authentication method, they may also request:

• Whether OAuth is supported
• Expected daily message and recipient volume
• Application or server public IP address
• Development and production server IP addresses
• Allowed sender addresses
• Reply-to address
• Whether external recipients must be supported
• Whether the public IP address is static
• Error logs from an unsuccessful test
• Google OAuth client information, if OAuth is being implemented

Do not automatically send sensitive credentials just because someone asks for “SMTP details.” First confirm the application, responsible team, authentication method, and secure credential-delivery process.

Choose the Correct Google Workspace Sending Method

Google documents three ways to send email from a device or application.

Option 1: Google Workspace SMTP Relay

Google recommends its SMTP relay service for applications and devices within an organization.

Standard relay details include:

SMTP Server: smtp-relay.gmail.com
Recommended TLS Port: 587
Encryption: TLS

Google also lists ports 25, 465, and 587 as configuration options. Port 587 with TLS is generally the appropriate choice when the sending application supports it.

SMTP relay offers several benefits:

• Centralized control through the Google Admin console
• Support for automated systems and devices
• IP-based authentication options
• Reduced dependence on an individual user’s credentials
• Organization-level sender restrictions
• Better separation between employee accounts and application mail
• Higher documented relay limits than mailbox-based Gmail SMTP

SMTP relay is not ready for use merely by entering its server address. A Google Workspace administrator must first create and configure an SMTP relay rule in the Admin console. The administrator decides:

• Which senders are permitted
• Whether only domain users can send
• Which public IP addresses are allowed
• Whether SMTP authentication is accepted
• Whether TLS is required

If IP-based authentication is selected, give the administrator the application server’s public outbound IP address—not its private address such as 192.168.x.x or 10.x.x.x.

Option 2: Gmail SMTP Server

The Gmail SMTP server is suitable when an application sends through a specific Google Workspace mailbox.

Use either:

SMTP Server: smtp.gmail.com
Port: 587
Encryption: STARTTLS

or:

SMTP Server: smtp.gmail.com
Port: 465
Encryption: SSL/TLS

The username must be the complete email address, such as:

notifications@example.com

The normal account password should not be used. Use OAuth when the application supports it. For an older application without OAuth, an App Password may be possible if the account and administrator policies allow it.

Option 3: Restricted Gmail SMTP Server

The restricted server uses:

SMTP Server: aspmx.l.google.com
Port: 25
Authentication: Not required

This method can send only to Gmail or Google Workspace recipients. It cannot be treated as a general-purpose unauthenticated relay for arbitrary external addresses.

Administrator involvement is required. Google instructs administrators to allowlist the device or application IP address and configure SPF appropriately. Because port 25 may be blocked by an ISP, firewall, or cloud provider, connectivity must also be verified.

Google OAuth, App Passwords, and Normal Passwords

OAuth Is the Preferred Authentication Method

Google Workspace no longer supports applications classified as “less secure apps” signing in with only the account’s normal username and password. Use Google OAuth when the application supports it.

OAuth provides important security benefits:

• The normal account password is not stored in the application
• Access can be authorized and revoked
• Administrators can apply application-access policies
• Authentication is compatible with modern Google security requirements
• Compromise of one application does not necessarily expose the account password

OAuth integration may require a Google Cloud project, OAuth consent configuration, suitable scopes, and administrator approval. Exact requirements depend on the application.

When an App Password Can Be Used

A Google App Password is a separate 16-digit passcode intended for an application or device that cannot use “Sign in with Google.”

An App Password requires 2-Step Verification. The option may be unavailable when:

• 2-Step Verification is not enabled
• The organization’s administrator blocks App Passwords
• The account is enrolled in Advanced Protection
• 2-Step Verification is configured only with security keys
• The account or authentication policy does not permit the feature

Google may revoke App Passwords after the main Google account password is changed. A new App Password would then be required.

Never Share the Normal Account Password

Do not provide:

• The employee’s normal Google password
• A super administrator’s password
• Backup verification codes
• Security-key information
• Browser session cookies
• An App Password in an ordinary ticket or group email

If an App Password is necessary, create one specifically for the integration and deliver it through an approved secure channel. Store it in a protected secrets manager where possible.

Recommended Account Design

Avoid using an employee’s personal business mailbox for a permanent application integration.

A better design is a dedicated sender identity, such as:

notifications@example.com
no-reply@example.com
support-system@example.com

The exact design depends on licensing, reply handling, audit requirements, and Google Workspace configuration. An alias or Google Group is not automatically a login-capable mailbox and may not work as an SMTP username.

The sender account should:

• Have only the access needed for its purpose
• Use 2-Step Verification where interactive authentication applies
• Have a recovery and ownership process
• Be documented as a service dependency
• Be monitored for suspicious activity
• Not hold unrelated confidential email
• Have its credentials rotated or revoked when the integration is retired

If recipients may reply, use a monitored reply-to mailbox. Do not use a no-reply address when customer responses are expected.

How Google Workspace SMTP Email Delivery Works

The application creates an email containing the sender, recipients, subject, body, and attachments. It then connects to the configured Google SMTP server.

For smtp.gmail.com on port 587, the usual flow is:

1. The application connects to the SMTP server.
2. The client requests STARTTLS.
3. The connection becomes encrypted.
4. The application authenticates using an approved method.
5. Google accepts or rejects the message.
6. Google applies security, spam, policy, and sending-limit checks.
7. The message is delivered or routed to the receiving mail server.

An SMTP success response means Google accepted the message for processing. It does not guarantee that the recipient read it or that the destination server placed it in the inbox.

Prerequisites and Pre-Integration Checklist

Confirm the following before giving details to the developer or vendor:

• The sending domain is active in Google Workspace.
• The selected account or relay sender is permitted to send.
• The application supports TLS.
• The application supports OAuth, an App Password, or the configured relay method.
• 2-Step Verification is enabled if an App Password will be used.
• A Workspace administrator has approved the integration.
• The From address is authorized.
• The Reply-to address is correct.
• The expected sending volume is within Google’s limits.
• The application can securely store secrets.
• Network firewalls permit the selected outbound SMTP port.
• SPF, DKIM, and DMARC are reviewed for the domain.
• Test and production environments are identified separately.

Safe Information-Sharing Template

Send the following non-secret information first:

Google Workspace Email Integration

Sending method: Gmail SMTP
SMTP server: smtp.gmail.com
Port: 587
Encryption: STARTTLS
Authentication: Required
Username: notifications@example.com
From address: notifications@example.com
From name: Example Company Notifications
Reply-to address: support@example.com

Authentication credential will be supplied separately through an approved
secure channel after the configuration and recipient have been verified.

For SMTP relay, use:

Google Workspace SMTP Relay Integration

SMTP server: smtp-relay.gmail.com
Port: 587
Encryption: TLS required
Authentication method: As configured by the Google Workspace administrator
Approved sender: notifications@example.com
Authorized public IP: [application server public IP]

Do not include a password or App Password in the first message.

How to Configure and Test Gmail SMTP

Step 1: Confirm Application Support

Verify that the application supports at least one approved authentication method:

• Google OAuth
• Google App Password
• Google Workspace SMTP relay

If the vendor supports only a normal username and password with no OAuth or App Password capability, the integration is outdated and should not be approved as designed.

Step 2: Select the Sender

Choose a dedicated and recognizable sender address. Confirm whether recipients should be able to reply.

Step 3: Configure Encryption

For STARTTLS:

Server: smtp.gmail.com
Port: 587
Security: STARTTLS

For implicit SSL/TLS:

Server: smtp.gmail.com
Port: 465
Security: SSL/TLS

Do not select “None” for encryption when using authenticated Gmail SMTP.

Step 4: Configure Authentication

Use the complete Google Workspace email address as the username.

Use OAuth if supported. Otherwise, enter a dedicated App Password if the account and organizational policy permit it.

Do not add spaces when copying an App Password into an application, even if Google displays it in grouped characters.

Step 5: Send a Controlled Test

Send a test message to:

• One internal Google Workspace recipient
• One approved external recipient, if external delivery is required

Verify:

• The message arrives
• The From name and address are correct
• Replies go to the correct mailbox
• TLS is used
• The message is not placed in spam
• Application logs show successful submission
• Links and attachments work as expected

Step 6: Monitor the Integration

After deployment, monitor:

• Authentication failures
• SMTP rejection codes
• Bounces
• Unusual sending patterns
• Spam complaints
• Delivery delays
• Google Workspace email logs
• Credential ownership and expiry events

Sending Limits and Appropriate Usage

Google applies sending and recipient limits. Limits can vary by sending method, account type, trial status, payment status, and sending behavior.

Google’s documentation states that:

• Gmail SMTP sending through smtp.gmail.com has a documented limit of up to 2,000 messages per day for a Google Workspace account.
• SMTP relay has separate limits, including documented per-user and per-transaction restrictions.
• Trial accounts may have lower limits.
• Suspicious messages can be delayed, filtered, or rejected even when the numeric limit has not been reached.
• Google may apply restrictions based on sending practices.

SMTP quotas should not be interpreted as permission to send unsolicited bulk email. For newsletters, marketing campaigns, or large transactional workloads, use an appropriate email delivery platform that supports consent management, unsubscribe handling, bounce processing, reputation monitoring, and required authentication.

SPF, DKIM, and DMARC

SMTP credentials alone do not provide a complete email-security configuration.

SPF

SPF identifies systems authorized to send mail for the domain. If all mail is sent through Google Workspace, follow Google’s official SPF guidance. If other services also send for the domain, include them correctly in a single SPF record.

Do not create multiple independent SPF TXT records for the same domain because this can cause SPF evaluation errors.

DKIM

DKIM adds a cryptographic signature to outgoing messages. Google Workspace administrators can generate a DKIM record in the Admin console, publish it in DNS, and then enable signing.

DMARC

DMARC defines how receiving systems should handle messages that fail authentication and provides reporting options. Deploy DMARC carefully, preferably beginning with monitoring and reviewing legitimate senders before applying a strict rejection policy.

Correct SPF, DKIM, and DMARC configuration improves domain protection and delivery trust, but it does not guarantee inbox placement.

Security Best Practices

• Prefer OAuth or administrator-managed SMTP relay.
• Never use a Google super administrator account for application email.
• Use a dedicated sender account or controlled relay identity.
• Require TLS wherever supported.
• Store secrets outside source code and configuration files committed to version control.
• Restrict access to production credentials.
• Use separate credentials or controls for development and production.
• Rotate or revoke compromised credentials immediately.
• Do not log passwords, App Passwords, OAuth tokens, or complete SMTP connection strings.
• Review third-party vendor security before providing credentials.
• Remove access when the application is retired.
• Do not use SMTP integration for unsolicited mail.

Common Problems and Troubleshooting

Authentication Failed

Possible causes include:

• The normal account password was used
• The username is not the complete email address
• The App Password was copied incorrectly
• 2-Step Verification is not enabled
• App Passwords are blocked
• The App Password was revoked
• OAuth authorization was denied or expired
• The account is suspended
• The selected SMTP authentication method is unsupported

Verify the account status and authentication policy. Generate a new App Password only if this method is permitted and genuinely required.

Connection Timeout or Connection Refused

Check:

• SMTP hostname spelling
• Selected port
• Outbound firewall rules
• Hosting-provider SMTP restrictions
• Proxy or security appliance rules
• DNS resolution
• Whether the application expects STARTTLS or implicit SSL/TLS

Port 587 requires STARTTLS. Port 465 uses implicit SSL/TLS. Selecting the wrong encryption type can prevent the connection.

SMTP Relay Access Denied

For smtp-relay.gmail.com, verify:

• An SMTP relay rule exists in the Admin console
• The server’s actual public outbound IP is authorized
• NAT has not changed the outbound IP
• The sender is allowed by the relay rule
• TLS and authentication match the configured policy
• Changes have had time to propagate

Private IP addresses are not useful for Google’s internet-facing IP allowlist.

Email Is Accepted but Not Received

Check:

• The recipient address
• Spam and quarantine folders
• Google Workspace email logs
• Application logs
• Bounce messages
• Recipient-server rejection messages
• Domain SPF, DKIM, and DMARC configuration
• Attachment type and size
• Google and recipient filtering policies

SMTP acceptance does not guarantee final inbox delivery.

From Address Is Rejected or Rewritten

The application may be trying to send as an unauthorized address. Use an approved Workspace address or configure the required sender permissions and relay policy.

Do not assume that successful authentication as one mailbox permits unrestricted sending from every address in the domain.

App Password Option Is Missing

Possible explanations include:

• 2-Step Verification is not enabled
• The administrator disabled App Passwords
• The account uses Advanced Protection
• The account uses security-key-only 2-Step Verification
• Organizational authentication policy prevents it

Use OAuth or an administrator-configured SMTP relay instead of attempting to bypass the restriction.

What to Expect After Successful Setup

After successful configuration, the application should be able to submit outgoing messages through Google Workspace using the authorized sender.

Continue monitoring delivery because successful setup does not remove:

• Sending limits
• Spam filtering
• Recipient-server policies
• Authentication-policy changes
• Credential revocation
• Vendor outages
• Domain reputation requirements
• SPF, DKIM, and DMARC responsibilities

Document the integration owner, sender identity, authentication method, authorized systems, expected volume, and credential-recovery process.

FAQ

Frequently Asked Questions

What exact SMTP details should I give a developer?

For a basic mailbox-based integration, provide smtp.gmail.com, port 587, STARTTLS, authentication required, the complete Google Workspace email address, and the approved From address. Provide an OAuth authorization or App Password separately through a secure process.

Can I give them my normal Google Workspace password?

No. Google Workspace does not support less-secure application access using only the normal username and password. Use OAuth, an App Password where permitted, or Google Workspace SMTP relay.

Is port 587 or 465 better?

Port 587 with STARTTLS is generally the preferred submission configuration. Port 465 with SSL/TLS is a supported alternative when required by the application. The encryption setting must match the selected port.

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

smtp.gmail.com sends through a particular mailbox and requires account authentication. smtp-relay.gmail.com is an administrator-configured organizational relay intended for servers, devices, and applications. Google recommends SMTP relay for organizational device and application sending.

Do I need a Google Workspace administrator?

Administrator involvement is required for SMTP relay, restricted SMTP, policy changes, sender authorization, and some OAuth configurations. A user may be able to create an App Password only when 2-Step Verification is enabled and organizational policy allows it.

Can I use an email alias as the SMTP username?

Not normally. An alias does not have its own password and is not automatically a login-capable account. Authenticate with a permitted Workspace account or use an administrator-configured relay, and ensure the alias is authorized as a sender.

Can Google Workspace SMTP send bulk marketing email?

Google Workspace SMTP has sending limits and is not a substitute for a dedicated bulk-email platform. Use an appropriate marketing or transactional email service for large-volume campaigns, consent management, unsubscribes, bounce handling, and reputation management.

Why did the integration stop after the account password changed?

Google states that App Passwords are revoked when the Google account password changes. If an App Password was used, create a new one where permitted and update the application securely.

Does a successful SMTP response guarantee delivery?

No. It normally means the SMTP server accepted the message for processing. Spam filters, domain authentication, recipient policies, sending limits, and later delivery failures can still affect the outcome.

FINAL RECOMMENDATION / CONCLUSION

For a small integration tied to one mailbox, use smtp.gmail.com on port 587 with STARTTLS and Google OAuth. If OAuth is unavailable and policy permits it, use a dedicated App Password—never the normal Google account password.

For business applications, servers, monitoring systems, printers, scanners, or centrally managed integrations, use smtp-relay.gmail.com with an administrator-configured relay rule. Share non-secret settings first, deliver credentials separately through a secure channel, use a dedicated sender identity, and verify SPF, DKIM, DMARC, delivery logs, and sending limits before production deployment.

SOURCES

• Google Workspace Admin Help: Send email from a printer, scanner, or app
• Google Workspace Admin Help: Route outgoing SMTP relay messages through Google
• Google Account Help: Sign in with App Passwords
• Google Workspace Admin Help: Gmail sending limits