Gmail SMTP settings: ports, auth, and alignment

Which setup method should I use?

Use authenticated submission at smtp.gmail.com when one application sends as one mailbox and can use the account's permitted credentials. Use Google Workspace SMTP relay when an administrator needs policy around devices, applications, IP addresses, or allowed senders. Do not swap the two endpoints while leaving the surrounding authentication assumptions unchanged.

Google's current documentation separates the choices and their values.

Choose the method from the account and sending pattern, not the port alone.

If the software supports a current Google OAuth flow, use the product's official Google integration instructions rather than translating an app-password example into OAuth parameters. OAuth clients, scopes, consent, and tokens are account-specific and are outside a generic host-and-port table.

How do I configure Gmail SMTP?

1. Fix the test identity and scope

Use one controlled mailbox and one visible From address. For a worked example, suppose the application sends from alerts@example.com, authenticates as alerts@example.com, sends fewer than 300 transactional notices per day, and will deliver one test to a Gmail recipient and one mailbox the organization controls. Do not start with a production mailing list.

2. Enter the endpoint and transport values

For authenticated submission, enter host smtp.gmail.com, port 587, and STARTTLS or the client's equivalent TLS-upgrade setting. If the client specifically requires implicit SSL, use port 465. Require authentication and enter the full account address as the username. Do not use port 25 for this worked authenticated-submission example.

3. Use an approved account credential

Follow the account's current authentication policy. If Google and the application explicitly support an app password, create it for that application after 2-Step Verification is enabled and store it as a secret. Never paste a normal Google password into an unsupported device, commit an app password to a repository, or include it in a screenshot. If policy blocks the method, stop and select a supported integration or relay design.

4. Authorize the visible sender

Keep the authenticated mailbox and visible From address the same for the first test. A different From identity may require a verified alias, delegation, relay policy, or application-specific authorization. A 235 authentication success or SMTP 250 acceptance does not grant Send As permission for an arbitrary domain.

5. Send one traceable message

Use a subject such as SMTP validation 2026-08-25 14:30 UTC and include a non-secret run identifier such as gmail-smtp-630184. Record the application time, endpoint, port, From, recipient, and server response. Do not include credentials or customer data in the record.

How does this setup affect DMARC?

SMTP authentication answers whether the application may use Google's submission service. DMARC answers whether an authenticated domain aligns with the domain in the visible From address. They are different controls.

If Google Workspace is the only sender for example.com, Google's SPF instructions give v=spf1 include:_spf.google.com ~all as the starting record (Google Workspace SPF setup). A domain with other senders must build one combined SPF policy within the lookup budget instead of publishing a second SPF record.

Google Workspace DKIM uses a tenant-generated TXT value. Google's setup flow offers a 2048-bit key by default and documents selector google as the default. Copy the account-generated hostname and value from your Admin console. Never reuse the example value or another account's key. Google notes that a newly activated Gmail tenant may need 24 to 72 hours before a DKIM key can be generated (Google Workspace DKIM setup).

The current vendor-published workflow shows where the tenant generates the record.

Use account-generated values. Do not copy the schematic's sample record.

RFC 9989 defines relaxed and strict alignment for DKIM and SPF. DMARC passes when at least one supported mechanism authenticates and its identifier aligns with the RFC5322 From domain (RFC 9989, Section 4.4). A Google-signed message can therefore be accepted by SMTP yet fail DMARC for example.com if neither the DKIM signing domain nor the SPF-authenticated domain aligns.

How do I validate the setup?

Check DNS values

Query the SPF, DKIM selector, and _dmarc.example.com records from more than one public resolver. Compare the exact tenant-generated DKIM hostname and value. DNS presence alone does not prove Google is signing the test message.

Check vendor status

In the Google Admin console, confirm that the intended domain shows DKIM authentication enabled after DNS is published. Google's instructions say to use Start authentication and describe the status Authenticating email with DKIM (Google DKIM validation). Labels can change, so use current tenant guidance rather than a remembered screenshot.

Check the delivered message headers

Open the raw source of the controlled message and locate the receiver-added Authentication-Results. RFC 8601 Section 1.2 explains why a field added outside the receiver's trust boundary is not authoritative (RFC 8601, Section 1.2). Confirm spf=pass, dkim=pass, and dmarc=pass, then compare smtp.mailfrom, header.d, and header.from rather than reading pass tokens alone. Use Palisade's Email Header Analyzer to parse headers you supply; it cannot test the credential or guarantee placement.

Check DMARC reporting and delivery

Confirm that the authorized Google source appears in aggregate DMARC data for the From domain and that unexpected sources do not increase after launch. Then compare Gmail delivery and placement for the intended traffic. Google requires SPF or DKIM for all senders to personal Gmail accounts and SPF, DKIM, and DMARC for senders over 5,000 messages per day to Gmail accounts under its current guidelines (Google email sender guidelines).

If the one-message test passes but the team still cannot see every production source, Palisade's DMARC Agent can organize aggregate DMARC evidence across the domain. Smart DNS Deployment can write only DNS changes a human has approved. It does not configure Google credentials, test an unsent application, or guarantee placement. Start with Palisade after the controlled header test establishes that ongoing visibility is the remaining problem.

Troubleshooting

Authentication is rejected

Confirm the full account address, approved credential type, 2-Step Verification and app-password eligibility, and any Workspace policy. Do not repeatedly retry a locked or policy-blocked credential.

TLS negotiation fails

Match port 587 with STARTTLS and port 465 with implicit SSL. Update a client that cannot support the required transport security rather than disabling certificate or TLS verification.

The message sends but DMARC fails

Compare the visible From domain with header.d and smtp.mailfrom. Repair signing, alias authorization, or sender configuration at the actual source. The Gmail authentication guide covers DNS controls.

The server accepts mail but delivery degrades

Check rate and daily limits, complaints, sending changes, and Google Postmaster evidence. Server acceptance is not a placement promise. Do not rotate ports or rewrite content randomly while leaving the sending source unexplained.

When does this setup not apply?

This guide does not cover inbound Gmail settings, unauthenticated direct-to-MX delivery, high-volume marketing architecture, or consumer account recovery. A multifunction device that cannot meet current authentication or TLS policy may need an administrator-controlled relay or replacement, not a weaker Gmail account.

Evidence

Sources and further reading

• Google device and app SMTP options
• Google Workspace SPF setup
• Google Workspace DKIM setup
• Google email sender guidelines
• RFC 9989, DMARC
• RFC 8601, Authentication-Results