Send WordPress emails through SMTP without a plugin

Your WordPress emails are silently failing

You built a contact form. A customer fills it out. You never get the email. Six months later, you check your spam folder and find 47 missed inquiries, customers you never responded to, leads you never converted.

This is what happens when WordPress uses PHP's mail() function by default. Most shared hosts either don't have proper SPF/DKIM records, or major providers treat server-generated email as suspicious. Your password reset emails, order confirmations, and contact forms all arrive in the spam folder, if they arrive at all.

The fix is to route WordPress email through a proper SMTP server. Every WordPress admin needs this. Almost nobody has it configured correctly.

What most people do instead

The standard WordPress-SMTP playbook ends in one of three places. None is ideal.

How to set up SMTP in WordPress without a plugin

You can wire SMTP in by hand. The cleanest no-plugin route is a must-use plugin, a single PHP file in wp-content/mu-plugins/, that hooks WordPress's phpmailer_init action and points it at your SMTP server:

// wp-content/mu-plugins/smtp-mailer.php
add_action( 'phpmailer_init', function ( $phpmailer ) {
    $phpmailer->isSMTP();
    $phpmailer->Host       = 'smtp.gmail.com';
    $phpmailer->Port       = 587;
    $phpmailer->SMTPSecure = 'tls';
    $phpmailer->SMTPAuth   = true;
    $phpmailer->Username   = 'you@yourdomain.com';
    $phpmailer->Password   = 'your-app-password';
} );

Drop that file in place and WordPress routes mail through your SMTP server. Using the mu-plugins folder, it even survives theme switches. But the trade-offs are real:

• Your SMTP password sits in plaintext in a file, a problem the moment it lands in version control.
• There is no interface to update or rotate credentials, you edit the file every time.
• No send log and no test button, so a typo fails silently, the exact problem you were trying to fix.
• If you use functions.php instead, the snippet vanishes the day you change themes.

It is a fine option if you live in code. If you would rather not store a password in a file or babysit a snippet, the next section does the same thing from one command.

A better way: one command, persistent config

Open the TrueCommander navigator. Type enable smtp. Fill in host, port, username, password. Hit Enter.

The command stores your SMTP credentials in the database, and the plugin applies them to every outgoing email automatically. WordPress now routes all mail through your SMTP server. Re-run the command anytime to update credentials.

Shown in advanced mode, where commands start with tp. In easy mode you type the same command without the tp prefix.

How it works

The command saves your credentials, then hooks WordPress's phpmailer_init action with them so the configuration applies on every page request automatically.

Real example

You're running a WooCommerce store on a shared host. Order confirmation emails are arriving in customer spam folders. Support tickets about "never got the email" pile up.

You open TrueCommander and type enable smtp. Fill in SendGrid credentials (free tier covers 100 emails/day). Run. The command saves the configuration, so from this moment forward every WordPress-generated email, order confirmations, password resets, contact form submissions, WooCommerce notifications, routes through SendGrid with proper SPF/DKIM authentication.

Customers start receiving emails in their inbox. Support tickets drop. You never think about SMTP again.

Goes further with TrueCommander

Once SMTP is working, the Email Template Builder and macros unlock a new layer.

Frequently asked questions