How to Fix WordPress Not Sending Emails (SMTP Setup for Gmail, Outlook, and Custom Domains)
Table of Contents
Nothing makes a WordPress site feel “broken” faster than missing emails. A contact form gets submissions, but you never see them. WooCommerce takes orders, but customers don’t get receipts. Password resets vanish into thin air.
When this happens on my own sites, it’s almost never the form plugin’s fault. It’s usually the way WordPress sends mail by default. The fix is simple once you do it once: switch to wordpress smtp, then lock down your sender settings so your messages look legit to modern inboxes.
Below is the same process I follow when a site stops sending reliably, with Gmail (OAuth2), Outlook/Microsoft 365, and custom domain email.
Why WordPress emails fail (and why SMTP fixes it)
WordPress sends email through wp_mail(), which often relies on the server’s basic mail setup (PHP mail). That method doesn’t prove who you are. As a result, receiving servers treat messages like anonymous postcards with no return address.
In contrast, SMTP sends mail through an authenticated account (or an email API). That gives you:
- A real login or token (so mail servers trust the sender more)
- Clear “From” alignment (so replies and bounces behave)
- Better logs and error messages when something breaks
I also see these common causes show up again and again:
- Your host blocks outbound SMTP ports (587 or 465)
- Your “From Email” doesn’t match the mailbox you authenticated with
- Gmail or Microsoft blocks basic password logins (very common in 2026)
- Your domain lacks SPF/DKIM/DMARC, so messages land in spam
If the emails you’re missing are WordPress admin alerts, you might also want to reduce noise, for example by turning off admin emails for new user signups after you confirm delivery works.
Quick checks I do before changing anything
I like to confirm the problem first, because “not receiving” and “not sending” are different.
- Check the spam folder (both the site admin inbox and the recipient inbox).
- Confirm the recipient address. Typos happen more than we admit.
- Send a test email from an SMTP plugin (most have a one-click test tool).
- Fix Reply-To for contact forms. Even when sending works, replies can go to the wrong place. For Contact Form 7, I use this guide to set up Reply-To in Contact Form 7.
- Ask your host about blocked ports. If port 587 is blocked, SMTP will fail no matter what plugin you use.
If the SMTP test email fails, don’t keep tweaking your form settings. Fix transport first, then revisit the form.
My go-to WordPress SMTP setup (fields to fill in)
You can do this with several plugins. The ones I see most are WP Mail SMTP, Post SMTP, Easy WP SMTP, and FluentSMTP. The steps below are generic, but the fields are basically the same everywhere.
Step 1: Set the sender identity (this prevents “From mismatch”)
In your SMTP plugin settings, I set:
- From Name: Your site or brand name (example:
SmartWP) - From Email: A real mailbox you control on your domain (example:
[email protected]) - Enable Force From Email (or similar)
- Enable Force From Name (optional, but I usually do it)
- Return-Path: Set to match the From Email if the plugin offers it
That “From Email” choice matters. If you authenticate as [email protected] but your From Email is [email protected], many providers will reject or spam it.
Step 2: Choose the provider and enter SMTP basics
Here’s a quick settings table I keep coming back to:
| Provider | SMTP host | Port (TLS/STARTTLS) | Port (SSL) | Auth | Notes |
|---|---|---|---|---|---|
| Gmail / Google Workspace | smtp.gmail.com | 587 | 465 | On | OAuth2 is best in 2026, app passwords only as a fallback |
| Outlook / Microsoft 365 | smtp.office365.com | 587 | (rare) | On | Many tenants block basic SMTP AUTH, OAuth2 is safer |
| Outlook.com (personal) | smtp-mail.outlook.com | 587 | 465 | On | Can work, but security settings can block logins |
| Custom domain mailbox | (from your provider) | 587 | 465 | On | Use the SMTP host your email provider gives you |
Now I plug the values into these fields:
- SMTP Host
- Encryption: TLS (use SSL only if your provider requires 465)
- SMTP Port
- Authentication: On
- Username: Usually the full email address
- Password: Your mailbox password, app password, or OAuth token flow (depends on provider)
Gmail setup in 2026 (OAuth2 first, app password only if needed)
For Gmail, I avoid the old “basic SMTP password login” approach. Google has tightened this over the years, and OAuth2 is the stable option.
In plugins that support it, I pick a Gmail or Google Workspace mailer and follow the OAuth2 connection wizard (client ID/secret, redirect URL, consent screen, then authorize the account). If you want a provider-specific walkthrough, the official plugin docs are usually the fastest, for example Post SMTP documentation.
If OAuth2 isn’t possible and you have 2-step verification enabled, I use an app password (not my normal login). Then my Gmail SMTP fields are:
- Host:
smtp.gmail.com - Port:
587 - Encryption:
TLS - Username: my full Gmail address
- Password: my 16-character app password
Outlook and Microsoft 365 (watch for SMTP AUTH being disabled)
Microsoft 365 is tricky because many orgs disable SMTP AUTH at the tenant or mailbox level. When I see repeated auth failures, that’s usually why.
If your SMTP plugin supports Microsoft OAuth2, I use that. If you’re using WP Mail SMTP, their Microsoft 365 / Outlook mailer documentation calls out the exact connection flow and requirements.
For basic SMTP (when it’s allowed), I use:
- Host:
smtp.office365.com - Port:
587 - Encryption:
TLS - Authentication: On
- Username:
[email protected] - Password: mailbox password (or app password if your org requires it)
If you just need the raw server details as a double-check, this Outlook SMTP settings guide is a handy reference.
Don’t skip SPF, DKIM, and DMARC (they decide inbox vs spam)
SMTP gets mail out the door. Authentication gets it into the inbox.
Here are practical DNS examples I use as a starting point (always adjust to match your actual senders):
- SPF example (Google + Microsoft in one domain):
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all - DKIM: Your provider will give you records, often with a selector like
google._domainkeyorselector1._domainkey. Add exactly what they provide. - DMARC (monitor first):
v=DMARC1; p=none; rua=mailto:[email protected]; fo=1
I start DMARC with p=none so I can watch reports without blocking anything. After a week or two, I move to p=quarantine, then p=reject once I’m confident.
To verify what’s live, I run a domain check using a tool like this guide and checker at DmarcDkim.com, then confirm the records match what my sender expects.
Troubleshooting WordPress SMTP errors I see most
When my test email fails, the error text usually points to the fix.
| Error or symptom | What it usually means | What I do |
|---|---|---|
535 auth failed | Wrong password, or basic auth blocked | Re-enter creds, use app password, or switch to OAuth2 |
534 or policy block | Gmail sign-in blocked | Use OAuth2, or generate an app password with 2FA |
unauthorized_client (Gmail) | OAuth client misconfigured | Re-check redirect URL and consent screen settings |
| “Could not connect to SMTP host” | Port blocked, wrong host, firewall | Try 587 TLS, ask host about outbound blocks |
| “SMTP AUTH disabled” (Microsoft) | Tenant/mailbox blocks basic auth | Enable SMTP AUTH (if allowed) or use OAuth2 mailer |
| Emails send, but go to spam | SPF/DKIM missing, DMARC misaligned | Fix DNS records, match From address to domain |
Two settings help me diagnose faster on real sites:
- Email logging: I can see exactly what WordPress tried to send and when.
- Alerts and retries: Some plugins can notify me on failures and re-try important mail.
Provider SMTP vs transactional email (SendGrid, Mailgun, SES)
For low volume sites, provider SMTP (Gmail or Microsoft) can be fine. For stores, memberships, or busy sites, I switch to a transactional sender because limits and spam filtering get painful.
Here’s how I decide:
| Situation | Stick with Gmail/Microsoft/custom SMTP | Use a transactional service |
|---|---|---|
| Contact form, small site | Yes | Not required |
| WooCommerce receipts | Sometimes | Usually yes |
| Membership or LMS emails | Sometimes | Yes |
| High volume or bursts | No | Yes |
| You need the best deliverability | Maybe | Yes |
Transactional services like SendGrid, Mailgun, or Amazon SES also make it easier to separate marketing email from site-critical messages.
Conclusion
When WordPress stops sending mail, I treat it like a plumbing issue, not a mystery. First I route messages through wordpress smtp, then I match the From address to the authenticated account, and finally I lock in SPF, DKIM, and DMARC so inboxes trust what I send. Once that’s done, form and order emails start showing up like they should. If you’re still stuck after the SMTP test, the next best move is checking logs and asking your host about blocked ports.