How to Test WordPress Emails on Laravel Valet

How to Test WordPress Emails on Laravel Valet? This was a question asked from your side! So we’re going to answer this with this article. Here is the actual question:

I have a Valet local setup for my WordPress projects, and sometimes I need to test the email functionality. Still, locally, the emails are not being sent. How can I fix this issue locally without installing any WP plugin on each individual website?

When you’re building WordPress sites on a local Laravel Valet setup, everything is great… until you need to test emails.

• Password reset links?
• Contact form submissions?
• WooCommerce order notifications?

By default, those emails never arrive locally. PHP’s mail() function has nowhere real to send them, so WordPress thinks everything worked, but your inbox stays empty.

The good news: you can solve this once globally using a mail catcher called Mailpit, without installing a single plugin on your individual WordPress sites.

In this post, you’ll learn:

• Why emails don’t work on Valet out of the box
• How to install and run Mailpit
• How to wire PHP (and therefore WordPress) to send all mail to Mailpit
• How to test emails using wp eval and other WP-CLI commands

---

Why WordPress Emails Don’t Work on Valet

WordPress sends mail using the wp_mail() function, which by default calls PHP’s built-in mail() function under the hood.

On a typical server, PHP is connected to:

• an actual mail transfer agent (MTA) like Postfix/Exim, or
• an SMTP server via configuration or plugin.

On a local Valet setup, you usually don’t have an MTA or SMTP server configured, so when mail() is called, nothing meaningful happens. WordPress happily reports true, but there’s nowhere for the email to go.

The fix: instead of trying to send real mail, we install a local mail catcher that:

• listens on a local SMTP port
• captures any outgoing emails
• shows them in a browser UI

We’ll use Mailpit for that.

---

Step 1 – Install Mailpit

On macOS with Homebrew:

brew install mailpit
brew services start mailpit

This installs Mailpit and runs it as a background service.

By default, Mailpit uses:

• Web UI: http://localhost:8025
• SMTP: localhost:1025

Open http://localhost:8025 in your browser. You should see the Mailpit interface with an empty inbox.

If you prefer MailHog, the idea is almost identical: you install MailHog, point PHP to its sendmail wrapper, and use its web UI (often also on port 8025).

---

Step 2 – Route PHP’s mail() to Mailpit (Global for Valet)

Now we want all PHP mail on your Valet PHP version to go through Mailpit, so WordPress doesn’t need plugins or custom code.

Mailpit provides a sendmail-compatible wrapper you can point PHP at via the sendmail_path configuration.

The basic idea is:

sendmail_path = /path/to/mailpit sendmail

On a typical Homebrew + Apple Silicon setup, Mailpit will be here:

/opt/homebrew/bin/mailpit

2.1 Find your Valet PHP config

List your PHP versions:

ls /opt/homebrew/etc/php
# e.g. 8.2, 8.3, etc.

Let’s assume you’re using PHP 8.3 with Valet.

2.2 Create a Mailpit config for PHP

Create a custom .ini file:

vim /opt/homebrew/etc/php/8.3/conf.d/zz-mailpit.ini

Add this content:

; Route all PHP mail() calls to Mailpit
sendmail_path = /opt/homebrew/bin/mailpit sendmail

Save and exit.

2.3 Restart Valet / PHP

Restart Valet so PHP picks up the new config:

valet restart
# or, if you prefer:
brew services restart php@8.3

At this point:

• Any mail() call from PHP under Valet
• Including all wp_mail() calls from any WordPress site

…will be routed into Mailpit.

---

Step 3 – Test with Raw PHP

Before bringing WordPress into the mix, test from the command line:

php -r 'mail("test@example.com", "Mailpit test", "Hello from Valet + Mailpit");'

Now refresh http://localhost:8025 and you should see the new email in Mailpit’s inbox.

If it appears there, your PHP → Mailpit wiring is working.

---

Step 4 – Test with WordPress via WP-CLI (wp eval)

Now let’s confirm that WordPress email is also flowing correctly.

Go to your WordPress project directory (the one with wp-config.php):

cd ~/Sites/my-project   # adjust to your actual path

Run this:

wp eval 'var_dump( wp_mail(
    "test@example.com",
    "Mailpit test via wp_mail()",
    "Hello from WordPress + WP-CLI + Mailpit!"
) );'

And you will see the email in Mailpit like the following:

What’s happening here:

• wp eval runs arbitrary PHP code in the context of your WordPress install.
• wp_mail() uses whatever mail transport PHP is configured for. Since we pointed sendmail_path to Mailpit, the email goes straight there.

In your terminal you should see something like:

bool(true)

And in Mailpit (http://localhost:8025) you should see the message in the inbox.

HTML email example

To verify HTML + headers:

wp eval 'var_dump( wp_mail(
    "test@example.com",
    "Mailpit HTML test",
    "<h1>Hello from WordPress</h1><p>Sent via <code>wp eval</code>.</p>",
    ["Content-Type: text/html; charset=UTF-8"]
) );'

Mailpit’s UI lets you view the HTML rendering, raw source, headers, etc.

Multisite or specific URL

If you have multiple sites in one WordPress installation (multisite) or want to be explicit, you can pass --url:

wp --url=my-site.test eval 'var_dump( wp_mail(
    "test@example.com",
    "Mailpit URL-specific test",
    "Hello from a specific site URL"
) );'

---

Step 5 – Trigger “Real” WordPress Emails from CLI

Testing wp_mail() directly is great, but sometimes you want to simulate actual flows.

Here are a couple of handy WP-CLI commands:

5.1 Password reset email

For a user (e.g. admin):

wp user reset-password admin

This command resets the user’s password and sends the standard password reset email, which will show up in Mailpit.

5.2 New user notification (depending on your WP version/settings)

You can create a new user and have WordPress send the new user notification:

wp user create demo demo@example.com --role=subscriber --send-email

Again, check Mailpit and you’ll see the onboarding emails.

---

Optional: Using MailHog Instead

If you already use MailHog or prefer it, the pattern is nearly identical:

1. Install & start MailHog: brew install mailhog brew services start mailhog
2. Set sendmail_path to the MailHog binary: sendmail_path = /opt/homebrew/bin/mailhog sendmail
3. Restart Valet / PHP and test with both php -r 'mail(...)' and wp eval.

MailHog also has a browser UI (commonly on http://localhost:8025 or another mapped port, depending on your setup).

---

Troubleshooting Tips

If emails don’t show up in Mailpit:

1. Check that Mailpit is running brew services list | grep mailpit If it isn’t running: brew services start mailpit
2. Confirm the sendmail_path is active Create a quick PHP info file in any Valet site: <?php phpinfo(); Open it in the browser and search for sendmail_path. It should show your Mailpit configuration.
3. Make sure you edited the correct PHP version Valet might be using a different PHP version than you expect. Run: php -v which php And ensure you updated the matching /opt/homebrew/etc/php/X.Y/conf.d/ directory.
4. Use Mailpit’s raw view for debugging In Mailpit, open any email and check the raw source to debug headers, from addresses, etc.

---

The Payoff: Zero Per-Site Plugins

With this setup:

• You don’t need to install an SMTP plugin on each WordPress site.
• Every project under Valet—WordPress, Laravel, custom PHP— automatically sends all mail into Mailpit.
• You can safely test contact forms, transactional emails, password resets, and more without spamming real inboxes.

Set it up once, forget about it, and just keep an eye on http://localhost:8025 whenever you’re working with email features.