To send email through Gmail's SMTP server, use host smtp.gmail.com, port 587 with STARTTLS (or 465 with SSL), and authenticate with a Google account plus an app password, not your regular login password. This works for contact forms, WordPress plugins, cron scripts, or any app that needs to hand off outgoing mail to a real mailbox instead of your server's local mail queue.
Gmail SMTP settings
Use these values in your mail client, plugin, or script:
- Host:
smtp.gmail.com - Port:
587(STARTTLS) or465(SSL/TLS) - Username: your full Gmail address, including
@gmail.comor your Workspace domain - Password: an app password, not your account password
Google requires an app password for SMTP when two-factor authentication is on. Generate one from your Google Account security settings, under App passwords. Regular account passwords are rejected by SMTP even if they're correct, since Google treats third-party SMTP the same as any other app signing in outside the normal browser login flow.
Common auth errors
A "Username and password not accepted" or 535 error usually means: your login password was used instead of an app password, 2FA isn't enabled on the account (app passwords require it), or the app password was copied with a typo or extra space. Regenerate the app password if you're not sure it's correct, since Google doesn't let you view an existing one again after creation.
Why route through Gmail instead of your server's mail
Your hosting account can already send mail directly using its own hostname and IP, and for a domain with SPF and DKIM configured that's usually the simpler path. Routing through Gmail instead makes sense when you want deliverability backed by Google's sending reputation, when a script or app only supports SMTP relay and not local sendmail, or when you want a single Gmail inbox to receive replies regardless of which server sent the original message.
The tradeoff: mail sent through Gmail SMTP shows Gmail's infrastructure in the headers, and you're bound by Gmail's sending limits, which are built for personal or small-business volume, not bulk mail. For a contact form or occasional transactional email, this is rarely a problem. For anything higher volume, a dedicated transactional email service is a better fit than either Gmail SMTP or your host's local mail queue.
Keeping SPF and DMARC consistent
If your domain's outgoing mail sometimes goes through Gmail and sometimes through your own hosting, make sure your SPF record authorizes both. On most hosting accounts SPF and DKIM are already configured for you, so if you add Gmail as another sending source you need to extend that SPF record rather than replace it. Edit it in Services > your hosting > DNS Zone Editor by adding Google's include to your existing record, for example:
v=spf1 +mx +a ip4:YOUR_SERVER_IP include:_spf.google.com ~all
Don't publish a second, separate SPF TXT record for the same domain. Mail servers only look at one SPF record per domain, and having two is treated as a failure by most receivers. Combine every source into one record with multiple include: entries.
If you've set up a DMARC policy, keep in mind DMARC checks for alignment between the visible From address and the domain that passed SPF or DKIM. Mail relayed through Gmail SMTP using your own domain in the From header will pass SPF if you've added Google's include, but won't carry your domain's DKIM signature since Gmail signs with its own key. SPF passing and aligned is enough to satisfy DMARC, but check your DMARC aggregate reports after making this change to confirm the Gmail-relayed mail is passing as expected.
If mail still lands in spam
A newly configured SMTP relay path can trigger spam filtering even with correct authentication, especially if you're sending a batch of mail right after setting it up. If that happens, see why emails go to spam for the full checklist, and if you're sending any real volume through this new path, follow a gradual send ramp as described in warming up a new sending domain rather than sending everything at once.