WordPress sends email through PHP’s mail function by default, and that is why your contact form replies and order emails keep landing in spam. The fix is authenticated SMTP, and you do not need a plugin for it.
Two small snippets, one in wp-config.php and one in functions.php, route every email your site sends through a real mail server. I will walk you through both, plus the app-password step most guides skip.
Key Takeaways
- WordPress mails through PHP’s mail() by default, unauthenticated, which is why site emails so often land in spam.
- Manual SMTP needs two snippets: connection constants in wp-config.php and a phpmailer_init hook in functions.php.
- For Gmail you must use an app password with 2-step verification; your normal account password will not work.
- Port 587 with TLS is the safe default; keep the From address on the same account you authenticate with.
- SMTP is only half of deliverability; SPF, DKIM, and DMARC records on your domain do the other half.
- Free Gmail caps sending at roughly 500 messages a day, fine for site notifications but not for newsletters.
Why WordPress emails end up in spam
Out of the box, wp_mail() hands your email to the web server’s PHP mail function, which fires it off with no authentication at all. Receiving servers see a message from a random web host claiming to be your domain, and they treat that claim with suspicion, so the email gets filtered or silently dropped.
SMTP fixes the trust problem. Your site logs in to a real mail server with a username and password, and the receiving side sees an authenticated sender instead of an anonymous one. Same email, completely different reception.
Step 1: Add the SMTP constants to wp-config.php
Open wp-config.php in your site root (file manager, FTP, or SSH) and add this block anywhere above the line that says /* That's all, stop editing! Happy blogging. */:
// SMTP email settings
define( 'SMTP_USERNAME', 'you@yourdomain.com' );
define( 'SMTP_PASSWORD', 'your-app-password' );
define( 'SMTP_SERVER', 'smtp.gmail.com' );
define( 'SMTP_FROM', 'you@yourdomain.com' );
define( 'SMTP_NAME', 'Your Site Name' );
define( 'SMTP_PORT', '587' );
define( 'SMTP_SECURE', 'tls' );
define( 'SMTP_AUTH', true );
define( 'SMTP_DEBUG', 0 );Swap in your own mail server, address, and password; the Gmail values here are just the common example. Two details matter more than people think. Keep SMTP_FROM on the same account you authenticate with, because many servers reject mail where the From address does not match the login. And treat this password like the site’s database password, since wp-config.php is exactly as sensitive.
Step 2: Hook PHPMailer in functions.php
The constants alone do nothing; WordPress needs to be told to use them. That is the job of the phpmailer_init hook, which runs just before every email leaves the site. Add this to your active theme’s functions.php, ideally in a child theme so a theme update cannot wipe it:
add_action( 'phpmailer_init', 'wpc_phpmailer_smtp' );
function wpc_phpmailer_smtp( $phpmailer ) {
$phpmailer->isSMTP();
$phpmailer->Host = SMTP_SERVER;
$phpmailer->SMTPAuth = SMTP_AUTH;
$phpmailer->Port = SMTP_PORT;
$phpmailer->Username = SMTP_USERNAME;
$phpmailer->Password = SMTP_PASSWORD;
$phpmailer->SMTPSecure = SMTP_SECURE;
$phpmailer->From = SMTP_FROM;
$phpmailer->FromName = SMTP_NAME;
}From now on, everything that goes through wp_mail(), so password resets, contact form notifications, and WooCommerce order emails, is sent over your authenticated connection. Here is what each constant actually controls:
| Constant | What it controls | Typical value |
|---|---|---|
| SMTP_SERVER | The mail server your site logs in to | smtp.gmail.com, or your host’s server |
| SMTP_PORT / SMTP_SECURE | Connection port and encryption pair | 587 with tls (or 465 with ssl) |
| SMTP_USERNAME / SMTP_PASSWORD | The account the site authenticates as | Your mailbox and its app password |
| SMTP_FROM / SMTP_NAME | The visible sender address and name | Same address as the username |
| SMTP_DEBUG | Connection logging for troubleshooting | 0 in production, 2 while testing |
Using Gmail SMTP: app passwords and sending limits
If you use Gmail as the server, your normal account password will not work; Google requires 2-step verification plus a dedicated app password for connections like this. Generate one in your Google account security settings and paste that 16-character code into SMTP_PASSWORD.
Mind the volume, too. Google’s sending limits cap a free account at roughly 500 messages a day, which is plenty for password resets and order notifications but the wrong tool for newsletters. For anything bulk, use a transactional email service or your host’s mail server instead.
Test your SMTP setup before you trust it
Do not assume the snippets worked; prove it. The quickest no-plugin test is triggering a password-reset email to yourself, then opening the message details in Gmail and checking the mailed-by and signed-by lines, which should now show your mail server rather than the web host.
If nothing arrives, set SMTP_DEBUG to 2 temporarily and trigger the email again; the connection log usually names the problem outright, most often a wrong password or a blocked port. Remember that emails WordPress schedules (like WooCommerce renewals) also depend on cron firing, a separate failure point I covered in fixing missing WooCommerce emails with a real cron job.
SMTP is only half of email deliverability
Authentication gets you through the door, but mailbox providers also check whether your domain vouches for the sender. That is done with three DNS records: SPF lists the servers allowed to send for your domain, DKIM signs each message so tampering is detectable, and DMARC tells receivers what to do when the first two fail.
If you send from your own domain, spend the extra twenty minutes adding them at your DNS host, because Gmail and the other big providers weigh these records heavily now. A perfectly authenticated SMTP connection from a domain with no SPF or DKIM still looks half-dressed to a spam filter.
Manual SMTP setup, start to finish
- Add the SMTP constants to wp-config.php
- Hook PHPMailer in functions.php
- Create the app password for your mail account
- Send a test email and check the headers
- Add SPF, DKIM, and DMARC at your DNS host
When an SMTP plugin is the better choice
The manual route is not always the right one, and it would be dishonest to pretend otherwise. If you manage the site with non-technical staff, want OAuth instead of app passwords, or need an email log you can show a client, a dedicated SMTP plugin earns its place. The two snippets above do the same core job with zero plugin overhead, which is why I prefer them on lean sites.
So is manual SMTP setup worth it over a plugin?
In my view, yes for most single-site owners, because the manual setup is two snippets you write once and never touch again, with no extra plugin to update or have abandoned on you. The plugin route wins when you need logging, OAuth, or a UI someone else can operate.
Either way, do not stop at SMTP. The sites whose emails reliably hit the inbox are the ones that also set up SPF, DKIM, and DMARC, and that part has nothing to do with which method you picked.
Still fighting emails that land in spam?
If your WordPress emails are vanishing or the SMTP connection refuses to work, contact us or email me and I will help you trace it. Reliable email is one of those things a site only gets credit for when it breaks.
Update Logs
05 Jul 2026
- Reworked the guide with the Gmail app-password requirement, a no-plugin way to test the connection, and the SPF, DKIM, and DMARC records that finish the deliverability job.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
