Email is being sent outbound without any SMTP configuration at all

Support
1

What issue or error are you experiencing?

Email is being sent outbound without any SMTP configuration at all.

No SMTP, no other email related plugin. Emails are being sent tomy email at google workspace directly by my macbook instead of being discarted or show up in mailhog as they laways did.

This syarted yesterday and it’s driving me crazy.

image
image1166×372 34.2 KB

image
image1956×1260 213 KB

What steps can be taken to replicate the issue? Feel free to include screenshots, videos, etc

I have no clue!

System Details

  • Local Version: Version 10.1.2+7004

  • Operating System (OS) and OS version: MacOS 26.5.1 (25F80)

Local Logs

Nothing in the logs mention email. Only mysql related messages.

2

Hi @marcoalmeida! One thing you could try is changing to Localhost and see if it still happens. Preferences>Advanced>Router Mode>Localhost. That might cut off whatever service is running.

You could also try checking your system for any local mail transport agents running in terminal with: ps aux | grep sendmail

3

@Nick-B

What’s the rationale behind the router mode change? I need HTTPS on my dev installs.

4

I was just offering it as a way to potentially prevent the emails from happening, but if HTTPS is required, you can disregard.

Is the email traffic coming from one specitic install or across all of your installs?

5

AFAIK, a single install - but I’ve been working on that install for a few days.

Again: no SMTP or any other kind of email plugins activated on that install.

6

Have you tried checking your system for any mail agents?

What about disabling all plugins? If you disable them do the mails persist?

7

Take a look at the mail headers for the message. You should be able to see the hops the email took in transit, which may provide clues. Also, there may be an indication of what tool was used to send it – WP core uses PHPMailer, but maybe something else will be listed.

8

Root cause found, marking this resolved.

Confirmed via packet capture (tcpdump on ports 25/587/465) that the emails were genuinely reaching my Mac’s real system Postfix, headers showed Received: by MBPMarceida2026.webdados (Postfix, from userid 501) with X-Mailer: PHPMailer 7.1.1.

Turns out this wasn’t a Local bug. The actual cause: I had an AI coding assistant (Claude Code) running wp-cli commands against the site in a separate terminal session, outside Local’s own site shell. Because of that, wp/php resolved to my system’s Homebrew PHP install instead of Local’s bundled PHP.

Every check I ran inside Local’s site shell (wp eval 'var_dump(ini_get("sendmail_path"))') correctly showed Mailpit’s wrapper, which is why this was so confusing for a while. But that override only applies to Local’s own bundled PHP and its own php.ini. Homebrew’s separate PHP install has its own php.ini, with sendmail_path commented out:

ini

;sendmail_path =

A commented-out sendmail_path makes PHP fall back to its compiled-in default on macOS, /usr/sbin/sendmail -t -i, real system sendmail, completely bypassing Mailpit. So any wp-cli/PHP command run outside Local’s shell context was silently handing mail straight to system Postfix, which then delivered it directly to Google (hitting our own real inbox and triggering G Suite rate-limit alerts on hundreds of stale WooCommerce test emails).

Fix: set an explicit sendmail_path in Homebrew PHP’s ini (/opt/homebrew/etc/php/8.5/php.ini):

ini

sendmail_path = /usr/bin/true

This makes any tool using system PHP no-op on mail instead of falling back to real sendmail, regardless of which shell or tool invokes it.

Takeaway for anyone else hitting this: Local’s Mailpit interception is scoped to Local’s own PHP/shell environment. If you (or any automation/AI tooling) run wp-cli or PHP scripts against a Local site from outside Local’s site shell, you’re using your system’s PHP, and its own mail config, not Local’s. Worth checking which php / php -i | grep sendmail_path for your system PHP install if you ever see mail escaping unexpectedly.

Thanks for the pointers earlier, checking the mail headers and testing with plugins/tools isolated is what eventually led to this.

9

Thanks for the follow-up @marcoalmeida.

You could also explore solving this by using direnv (available in Local 10.1.1 or higher). Your agent sessions should then use Local’s PHP as long as they run from the site root.

10

@nickc That’s cool. Is there an installation/configuration guide for direnv specifically for Local?

11

@marcoalmeida Just install direnv as instructed here: https://direnv.net/docs/installation.html

Then complete the shell hook setup:

https://direnv.net/docs/hook.html

After you restart your shell (or when your agent starts a new shell session), it should auto-load the env vars to use Local’s PHP and WP-CLI when you CD to the site root.

The full guide here for Local is worth reading:

https://community.localwp.com/t/using-direnv-with-local/52246

For others following along, note that direnv is macOS/Linux only.