WordPress Welcome Emails Not Sending? Here Is Why

If your WordPress welcome email is not sending, the most likely cause is one of six things: PHP mail() being blocked by your host, a missing or misconfigured SMTP setup, WP-Cron not firing, the email landing in spam, a subscriber stuck in an unconfirmed state, or a broken automation trigger. This guide covers all six in diagnostic order, so you find the real cause instead of guessing.

Most forum threads on this topic are plugin-specific. A thread about MailPoet will not help you if you are using a membership plugin or a custom automation.

This guide is plugin-agnostic. Work through the sections in order, because the causes at the top are more common and cheaper to fix than the ones at the bottom.

Before diving in: if your site sends some WordPress emails fine but the welcome email specifically is broken, start at the section on automation triggers and subscriber status. If no WordPress emails are sending, start at SMTP.

How WordPress Sends Email (And Why It Often Fails)

WordPress uses a PHP function called wp_mail() to send every email the system generates. By default, wp_mail() passes the message to PHP’s built-in mail() function, which relies on the server’s local mail transfer agent. Most shared hosting providers either disable that local MTA or throttle it aggressively to prevent spam abuse.

The result is silent failure. wp_mail() returns false, nothing appears in a log, and the user never receives their welcome email.

No error, no bounce, nothing to investigate. That silence is the first diagnostic clue: if you see no error but no email arrives, the problem is almost certainly at the delivery layer, not the plugin layer.

Silent failure is the most dangerous outcome. A working-looking system that delivers nothing looks identical to a working system until someone complains.

Step 1: Test Whether WordPress Can Send Email at All

Before diagnosing the welcome email specifically, confirm whether WordPress can send anything. Install a free plugin like WP Mail SMTP or Check Email and send a test message to an address you control. This takes under 2 minutes and eliminates a large category of causes immediately.

If the test email arrives, your delivery layer is functional. Skip to Step 3. If it does not arrive, you have confirmed the problem is at the server or SMTP level, and Step 2 is your next stop.

• Test email arrives in inbox: delivery is working. The fault is in the trigger, template or subscriber state.
• Test email arrives in spam: delivery is working but authentication is failing. Jump to the spam and authentication section.
• Test email does not arrive at all: the server cannot send mail. Fix SMTP before anything else.
• Plugin throws an error on send: note the exact error message. SMTP credential failures, connection timeouts and TLS errors each point to different fixes.

Step 2: Fix Your SMTP Configuration

WordPress’s default mail() delivery fails on the majority of shared hosting plans. SMTP is the fix, and it is not optional on any site that depends on transactional email. SMTP authenticates your outgoing messages with a real mail server, which is why they reach inboxes instead of disappearing.

Reliable transactional email providers for WordPress sites include Brevo (formerly Sendinblue), Postmark, Mailgun, Amazon SES and SendGrid. Most of them offer a free tier covering 100 to 300 emails per day, which is enough for a small membership or community site. At volume, Brevo’s free tier covers 300 emails per day and paid plans start around $15 per month for 20,000 sends.

Common SMTP Configuration Errors

• Port blocked by host: Port 25 is blocked on most shared hosting. Use port 587 (STARTTLS) or port 465 (SSL). If your SMTP plugin lets you choose, try 587 first.
• Wrong encryption setting: Mismatching the port and encryption type causes a silent timeout. Port 465 requires SSL. Port 587 requires TLS.
• Credentials copied with whitespace: Paste your username and password into a plain text editor first to strip hidden characters, then copy from there into WordPress.
• From address mismatch: Many SMTP services require the “From” address to match a verified domain or sender identity. A mismatch causes the message to be rejected before it leaves the server.
• App password not used: Gmail and Outlook accounts with two-factor authentication require an app-specific password, not the account password.

After correcting your SMTP settings, send another test email before re-testing your welcome email. Confirm delivery is working in isolation before layering in the plugin logic.

Step 3: Check Spam Placement and Email Authentication

If your test email arrives but lands in the spam or junk folder, delivery is technically working but authentication is failing. Email providers use three authentication standards to decide whether to trust a message. Missing any one of them increases spam scoring significantly.

• SPF (Sender Policy Framework): A DNS record that lists which servers are allowed to send email on behalf of your domain. If you send through Mailgun but your SPF record does not include Mailgun’s servers, receiving mail servers distrust the message.
• DKIM (DomainKeys Identified Mail): A cryptographic signature that proves the message content was not altered in transit. Your SMTP provider generates a DKIM key you add to your DNS.
• DMARC: A policy record that tells receiving servers what to do when SPF or DKIM fails. Without it, the decision is left to the receiver, and it often goes against you.

Check your authentication records at MXToolbox or mail-tester.com before assuming your content is the problem. A score below 8 out of 10 on mail-tester almost always points to a missing or misconfigured DNS record rather than anything in the email body.

Most welcome emails land in spam because of missing DNS records, not because of anything in the message itself. Fix authentication before rewriting your subject line.

Content That Triggers Spam Filters

Once authentication is clean, content can still hurt deliverability. Welcome emails are particularly vulnerable to a few patterns. Keep these out of your welcome email template:

• More than 2 links in a short message (welcome emails are often under 150 words, and 3 links in that space reads as promotional)
• Uppercase words in the subject line
• Phrases like “click here”, “free gift” or “you’ve been selected”
• Images with no alt text, or emails that are mostly image with minimal text
• A mismatch between the “From” name and the sending domain

Step 4: Diagnose WP-Cron and Action Scheduler

If your welcome email is triggered by an automation plugin and it shows as “scheduled” but never sends, WP-Cron is the most likely culprit. WordPress’s built-in cron system fires when a page is loaded, not on a real server clock. On low-traffic sites, no page load means no cron fire, and scheduled emails wait indefinitely.

Symptoms of a broken cron look like: emails that eventually arrive hours late, emails that arrive in batches when someone visits the site, or emails that show as queued in your plugin’s dashboard but never clear.

How to Check WP-Cron Health

Install the WP Crontrol plugin and look at the scheduled events list. Events that were due to run an hour or more ago and are still pending confirm WP-Cron is not firing reliably. The permanent fix is to disable WP-Cron and replace it with a real server cron job.

Add this line to your wp-config.php file:

define( 'DISABLE_WP_CRON', true );

Then add a server cron job (via cPanel or your host’s task scheduler) that calls the WordPress cron endpoint every 5 minutes:

*/5 * * * * wget -q -O - https://yoursite.com/wp-cron.php?doing_wp_cron /dev/null 2>&1

If you cannot access server cron, services like EasyCron or cron-job.org provide external cron triggers for free. A 5-minute interval is enough for welcome emails to feel near-instant to a new user.

Action Scheduler Specifically

Automation plugins that use Action Scheduler (WooCommerce, many others including Krom Automation) rely on it processing its queue consistently. If Action Scheduler’s queue shows a large backlog of failed or pending actions, check your server’s PHP time limit.

Actions timing out at 30 seconds can corrupt the queue. Raising the PHP time limit to 120 seconds in php.ini or via your host’s control panel clears the backlog in most cases.

Step 5: Check Subscriber and User Status

This is the cause most forum threads identify for plugin-specific welcome email failures. Many email and membership plugins gate the welcome email behind a confirmation step. If the user’s status is “unconfirmed”, “pending” or “awaiting approval”, the plugin deliberately withholds the welcome email until confirmation completes.

• Double opt-in enabled: If your list plugin has double opt-in active, the welcome email sends only after the user clicks the confirmation link in a separate email. If that confirmation email is also not arriving, the fix is SMTP, not the welcome email logic.
• User role restriction: Some welcome email plugins send only to specific roles. If a new user registers as “Subscriber” but the trigger is set to fire only for “Customer” or a custom role, they are silently excluded.
• Registration not completing: If your registration form requires admin approval, users sit in a “pending” state. The trigger fires on approval, not on initial registration. If approval is never given, no email ever sends.
• Duplicate email prevention: A “run once per user” guard on your automation means a user who already exists in your database will not receive the welcome email if they create a second account with the same address.

Check the user’s actual record in WordPress under Users All Users. Look at their role, their registration date, and whether the plugin that sends the welcome email has a separate contact or subscriber record for them.

Step 6: Check the Automation Trigger and Template

If delivery works, spam is not the issue, cron is healthy, and the user’s status is correct, the fault is in the automation logic itself. This happens most often after a plugin update changes an event hook name or alters when a trigger fires.

Trigger Timing Mismatch

WordPress fires different hooks at different points in the registration process. Some plugins hook into user_register, which fires immediately when a user is added to the database.

Others hook into wp_login, which fires only when the user actually logs in after registration. If your trigger and your event are on different hooks, the trigger never fires.

If you are building or managing welcome email automations manually, check exactly which WordPress action your plugin listens to. The User Registered trigger in Krom Automation fires on user_register, which means it fires the moment registration completes, before the user has logged in.

That is usually the right timing for a welcome email. See the full free triggers reference for exactly when each trigger fires.

Missing or Overwritten Template

If your welcome email previously worked and stopped after a plugin update, check whether the email template still exists. Some plugins store templates in the database. An update that resets settings or re-installs default templates can silently replace a custom template with the default, or delete the custom one entirely.

Check your plugin’s email template editor and confirm the template is present, active and assigned to the correct trigger event. If you use Krom Automation and want to build a properly formatted welcome email with a visual editor rather than a plain HTML field, the visual email builder documentation shows how to design it without touching code.

Workflow Paused or Disabled

This is embarrassingly easy to miss. If you are using an automation plugin, check whether the workflow or rule containing the welcome email is actually active.

Most plugins show a toggle or status indicator. A workflow sitting in “paused” or “draft” state executes nothing, regardless of how well configured it is.

A paused workflow is not a broken workflow. It is just an off switch. Check the toggle before spending an hour on SMTP logs.

Diagnostic Decision Table: Which Fix Applies to You

Symptom	Most Likely Cause	Where to Start
No WordPress emails send at all	PHP mail() blocked or SMTP not configured	Step 2: SMTP setup
Test email sends, welcome email does not	Trigger not firing or template missing	Step 6: trigger and template
Email arrives in spam	Missing SPF, DKIM or DMARC records	Step 3: authentication
Email shows as scheduled, never sends	WP-Cron not firing or Action Scheduler backlog	Step 4: cron health
Some users get the email, others do not	Subscriber status or role restriction	Step 5: user status
Worked before, broke after update	Plugin conflict or overwritten template	Step 6: template and hook timing
Test mode works, live signup does not	Cron timing or trigger hook mismatch	Step 4 then Step 6

What a Reliable Welcome Email Setup Actually Looks Like

A setup that sends consistently in 2026 has three layers: a real SMTP connection to a transactional provider, a genuine server cron replacing WP-Cron, and a clearly defined trigger tied to the exact moment registration completes. Without all three, you are relying on defaults that fail under normal hosting conditions.

The time cost of getting this right once is roughly 45 to 90 minutes: 20 minutes to configure SMTP and verify authentication records, 15 minutes to set up server cron, and the rest to test the full trigger-to-inbox journey with a real test account. That is a one-time investment. The alternative is debugging failed welcome emails for an hour every time a new user signs up and complains.

Year 1 vs Ongoing Cost Comparison

Approach	Setup Time	Ongoing Cost	Reliability
Default wp_mail() with no SMTP	0 minutes	$0	Unreliable on most shared hosts
Free SMTP tier (Brevo, Mailgun)	20 to 30 minutes	$0 up to ~300 sends/day	High, with proper DNS records
Paid transactional email service	20 to 30 minutes	$10 to $25/month at low volume	High, with SLA and deliverability tools
Automation plugin with built-in email	45 to 90 minutes total	$0 free tier or from $119/year Pro	High when SMTP and cron are also configured

Using Krom Automation for Welcome Emails

If you want a welcome email that goes beyond a plain text message, with conditional logic, delays, merge tags and a visual layout, Krom Automation handles this in the free version with no run caps. The User Registered trigger fires immediately on signup.

The Send Email action accepts merge tags so the email can address the user by name, include their username and include any other data captured at registration. You can see the full build walkthrough in the welcome email automation guide.

If your registration happens through a form plugin rather than the native WordPress signup page, Krom Automation supports triggers from Fluent Forms, Gravity Forms, WPForms and others, so the trigger can fire on form submission rather than on the WordPress user creation event. That matters for sites where registration is gated behind a multi-step form that creates the user only after all steps are complete.

The workflow simulator lets you test the entire sequence with zero side effects before you go live, which is the fastest way to confirm the trigger fires correctly without sending a test email to a real user.

After You Fix It: Prevent the Problem from Coming Back

Most welcome email failures are not one-off events. They are symptoms of a fragile setup that will break again. After fixing the immediate cause, put these three things in place:

• Enable failure notifications: If your automation plugin supports email alerts on failed executions, turn them on. Krom Automation sends failure notifications automatically and retries with configurable backoff, so you learn about a failure within minutes rather than days.
• Monitor your execution log: A log showing success rate per workflow is worth checking weekly. A workflow that was delivering at 100% and drops to 85% is about to fail completely. Catching the dip saves the firefight.
• Test after every plugin update: Automation triggers are the most common casualty of plugin version updates. A 2-minute test send after any update to a plugin involved in your welcome email flow confirms nothing broke.

If you want to understand whether the time you put into automation setup is paying off, the automation ROI guide gives you a concrete way to calculate it.

Verdict: What to Do and In What Order

Most people diagnosing a broken welcome email jump to the wrong layer first. They edit the email template when the real problem is SMTP.

They update their plugin when the real problem is WP-Cron. Following the diagnostic order in this guide saves you from that loop.

Start with the delivery test in Step 1. If that passes, move to spam authentication. If authentication is clean, check cron.

If cron is healthy, look at user status. If user status is correct, the fault is in the trigger or template. That order covers over 95% of cases without needing to guess.

If you are rebuilding your welcome email setup from scratch and want something that is auditable, testable and reliable without depending on a third-party automation platform, download Krom Automation free from the WordPress.org plugin directory and follow the welcome email automation guide. The free version includes everything you need for a trigger, a personalized email and an execution log you can actually read.

For sites that need a more complete automation setup around onboarding, such as a day-3 follow-up, a role change after a specific action, or an email sequence tied to course enrollment, see the full Krom Automation pricing for what the Pro tier adds.

Frequently Asked Questions

Why does my welcome email work in test mode but not on live signups?

Test mode usually triggers the email directly, bypassing the automation queue. Live signups go through WP-Cron or Action Scheduler, which may not be firing reliably. Set up a real server cron job as described in Step 4 and the gap between test and live behaviour closes.

All my other WordPress emails send fine. Why is just the welcome email broken?

Other WordPress emails, like password resets, use different hooks and are often sent synchronously rather than through a scheduler. Welcome emails in automation plugins are queued.

The queue depends on cron. Check cron health in Step 4, then check the trigger event and user status in Steps 5 and 6.

New users are stuck as “Unconfirmed” and never receive the welcome email.

Double opt-in is enabled in your plugin. The welcome email is intentionally withheld until the user confirms their address. Check whether the confirmation email is reaching them.

If that is also not arriving, fix SMTP first. If it is arriving but users are not clicking, review the confirmation email’s subject line and from address.

My welcome email shows as scheduled but never actually sends.

WP-Cron is not firing reliably. Disable it in wp-config.php and replace it with a real server cron that pings the cron endpoint every 5 minutes. If your automation plugin uses Action Scheduler, also check for a large backlog of failed actions in its queue, which often points to a PHP timeout issue.

Do I need an SMTP plugin to send welcome emails reliably?

On any shared hosting plan, yes. PHP’s built-in mail function is disabled or throttled on most shared hosts.

An SMTP plugin connecting to a transactional provider like Brevo, Mailgun or Postmark is the difference between reliable delivery and silent failure. The setup takes under 30 minutes and most providers have a free tier that covers hundreds of sends per day.

Why is WordPress sending the default welcome email instead of my custom one?

A plugin update likely reset your email template settings. Check your plugin’s email template editor and confirm your custom template is still present and set as active for the registration event.

Also confirm the plugin has not created a new default that overrides your customisation. Some plugins require you to explicitly disable the default template separately from enabling the custom one.