Google Workspace supports several ways for devices and applications to send email, but the correct choice depends on authentication, sender identity, recipient type, network location, security requirements, and expected message volume.
Why SMTP Configuration Matters
Business systems often need to send email without a person opening Gmail. Examples include website contact forms, accounting applications, scanners, printers, monitoring systems, customer relationship management platforms, ticketing systems, and automated reports.
A poorly configured mail sender can expose credentials, create spoofed messages, fail SPF or DMARC checks, trigger sending limits, or become an unauthorized relay. Administrators should select one supported sending method and document every system that uses it.
Understand the Main Sending Options
Google Workspace commonly supports three broad approaches for devices and applications:
- The Google Workspace SMTP relay service
- The Gmail SMTP server using an authenticated Google account
- The restricted Gmail SMTP server for limited delivery scenarios
The best option depends on whether the system can authenticate, whether it has a stable internet address, whether it sends only to Google recipients, and whether it needs to send as multiple approved addresses.
Choose the method before entering server settings
Do not copy a server name and port from an old device without confirming that the authentication and sender model still match the business requirement.
Google Workspace SMTP Relay Service
The SMTP relay service is usually the best option for business applications, servers, printers, and systems that send organizational mail. It is configured in the Google Admin console under Gmail routing settings.
The service uses the server name smtp-relay.gmail.com. Google currently documents supported SMTP ports that include 25, 465, and 587, depending on the encryption and authentication design. TLS should be required whenever the sending system supports it.
Define Allowed Senders
The relay configuration controls which envelope senders are permitted. Administrators can limit sending to registered Google Workspace users, addresses in approved domains, or another supported sender scope.
Use the narrowest setting that supports the application. Allowing arbitrary sender addresses can create spoofing, reputation, and accountability problems.
Choose an Authentication Method
The SMTP relay service can identify approved systems through one or more controls such as internet address restrictions and SMTP authentication. The available design should follow Google's current documentation and the capabilities of the sending device.
A fixed office or server internet address can be useful for printers and applications that cannot store modern credentials. SMTP authentication can support systems that move between networks, but credentials must be protected and rotated.
Require TLS
Transport Layer Security protects messages while they travel between the sending system and Google's mail servers. Require TLS when supported and verify that the device trusts current certificate authorities.
Older printers and applications may claim to support encryption but fail modern certificate or protocol requirements. Replace or update outdated systems rather than permanently disabling secure transport.
Do not disable TLS only to make an obsolete device work
Assign an owner, replacement plan, deadline, and compensating control when a legacy system cannot meet current transport-security requirements.
Gmail SMTP Server
The Gmail SMTP server uses smtp.gmail.com and authenticates as a specific Google account. Google commonly documents port 465 for SSL and port 587 for TLS.
This option may fit a single application that sends as one licensed user. The application must support Google's current authentication requirements. A normal account password should not be placed in an application.
Account Authentication and App Passwords
When an older application cannot use OAuth, an app password may be available for an account protected with 2-Step Verification, subject to Google policy and account settings.
App passwords are still long-lived credentials. Limit their use, name them clearly, store them securely, review them regularly, and revoke them when the system is replaced or the owner leaves.
Restricted Gmail SMTP Server
The restricted SMTP service can support devices that send only to Gmail or Google Workspace recipients. It does not provide the same general external-delivery use case as the relay service.
Use it only after confirming the recipient limitations and the device's business requirement. It is not a substitute for a properly configured relay when messages must reach customers, vendors, or other external domains.
Use a Dedicated Sending Identity
Do not configure an application with a senior employee's normal Gmail account. Use a dedicated approved identity or relay design that makes ownership and purpose clear.
Record the sender address, display name, owner, system, recipients, expected volume, authentication, and recovery procedure.
Configure SPF, DKIM, and DMARC
Messages sent through Google should align with the organization's domain-authentication design. Review the SPF record, enable DKIM for sending domains, and monitor DMARC alignment.
Third-party systems that send directly rather than through Google must also be included in the domain-authentication plan. Do not add broad SPF mechanisms without reviewing every authorized sender.
Review From, Envelope Sender, and Return Path
Email contains more than one sender identity. The visible From address, SMTP envelope sender, and return-path behavior can differ.
Verify how the application constructs each address and whether Google rewrites or authenticates it. Misalignment can cause DMARC failure, delivery problems, or confusing bounce messages.
Set Reasonable Message Volume
Google applies sending limits and abuse controls. Automated systems should send expected business messages rather than unsolicited marketing or bulk mail that belongs on a specialized platform.
Document normal daily volume, peaks, recipient count, attachment size, and failure handling. Investigate sudden increases because they can indicate a compromised application.
Restrict Network Access
When using internet-address authentication, allow only the exact approved public addresses. Do not add broad address ranges without a documented reason.
Review firewall egress, network address translation, cloud-hosting changes, internet-provider changes, and backup connections. The address Google sees may differ from the device's internal address.
Test Before Production
Send controlled messages to internal and external recipients. Verify delivery, sender identity, SPF, DKIM, DMARC, TLS, reply behavior, bounce handling, and message formatting.
Use Email Log Search and receiving-message headers to confirm the actual route. Test failure conditions, including invalid recipients and an unavailable application credential.
Common SMTP Errors
Authentication failures can result from the wrong server, unsupported sign-in method, incorrect username, expired credential, or disabled app password. Relay-denied errors can result from an unapproved internet address, sender, or recipient.
TLS errors can result from old firmware, incorrect ports, certificate validation, or unsupported protocols. Rate and quota errors can result from unexpected volume or application loops.
Troubleshooting Process
- Confirm the selected sending method.
- Verify the server name and port.
- Confirm TLS or SSL selection.
- Review authentication and allowed internet addresses.
- Verify the envelope and visible sender.
- Check Google Admin routing configuration.
- Review Email Log Search and application logs.
- Inspect the full error code and response.
- Test with one approved recipient.
- Document the correction.
Review SMTP Systems Quarterly
Inventory every device and application that sends through Google Workspace. Confirm ownership, business need, authentication, credentials, internet addresses, sender addresses, volume, and recent use.
Remove retired printers, old websites, former vendors, abandoned applications, and unknown internet addresses.
SMTP Relay Checklist
- Choose relay, authenticated Gmail SMTP, or restricted SMTP deliberately.
- Use the correct server name and supported port.
- Require TLS whenever supported.
- Limit allowed senders and internet addresses.
- Protect app passwords and SMTP credentials.
- Use a dedicated approved sender identity.
- Verify SPF, DKIM, and DMARC alignment.
- Document expected message volume.
- Test internal and external delivery.
- Review Email Log Search and error responses.
- Assign an owner and recovery procedure.
- Complete quarterly sender cleanup.
Frequently Asked Questions
Which Google SMTP server should a business application use?
The Google Workspace SMTP relay service is usually the preferred option for organizational applications and devices, but the final choice depends on authentication, network, sender, recipient, and volume requirements.
Should a printer store an employee's password?
No. Use an approved relay or dedicated identity design rather than a person's daily account credentials.
Why does SMTP work internally but fail externally?
The selected service may allow only Google recipients, the sender may not be approved, or domain authentication and relay settings may not support external delivery.
When Professional Support Helps
Professional support can select the correct sending method, configure SMTP relay, secure authentication, validate domain alignment, troubleshoot errors, and document every automated sender.
Need help applying this?
Manage Google Workspace Gmail with confidence.
J3 Systems Group LLC can configure SMTP relay, Gmail routing, forwarding, delegation, recipient mappings, secure transport, encryption, and supporting mail-flow documentation.