Sending emails from Laravel is straightforward.

You configure a mail driver, provide SMTP credentials, and call the Mail API.

But testing email workflows safely is a different challenge.

You probably don't want a test registration email reaching a real customer. You also don't want to depend on production SMTP credentials just to inspect an HTML template.

In this tutorial, we'll configure Laravel to send emails to NotifyTrap, a local-first notification testing workbench.

We'll capture an email, inspect its content, and discuss how this workflow can become part of your development and testing process.

What is NotifyTrap?

NotifyTrap is an open-source desktop application for capturing and inspecting application notifications locally.

It supports four main channels:

  • Email through SMTP.
  • SMS.
  • Push notifications.
  • Webhooks.

For email development, NotifyTrap provides an SMTP endpoint that your Laravel application can use just like a regular SMTP server.

The difference is that messages are captured locally for inspection instead of being delivered to real recipients.

1. Install and start NotifyTrap

First, download the appropriate release for your operating system:

NotifyTrap Releases

Follow the Getting Started guide to install the application and create your workspace and project.

Once your project is ready, create an SMTP channel and obtain its generated credentials.

NotifyTrap's local SMTP endpoint uses:

Setting Value
Host 127.0.0.1
Port 1025
Username Your generated channel username
Password Your generated channel password

Keep the generated credentials available. We'll use them in Laravel.

2. Configure Laravel

Open your Laravel application's .env file.

Configure the mail settings:

MAIL_MAILER=smtp MAIL_HOST=127.0.0.1 MAIL_PORT=1025 MAIL_USERNAME=YOUR_NOTIFYTRAP_CHANNEL_USERNAME MAIL_PASSWORD=YOUR_NOTIFYTRAP_CHANNEL_PASSWORD MAIL_ENCRYPTION=null MAIL_FROM_ADDRESS="noreply@local.test" MAIL_FROM_NAME="My Application"

Replace the username and password placeholders with the actual credentials generated for your SMTP channel in NotifyTrap.

The important settings are:

  • MAIL_HOST: points Laravel to the local SMTP service.
  • MAIL_PORT: uses NotifyTrap's SMTP port.
  • MAIL_USERNAME and MAIL_PASSWORD: authenticate against your configured channel.

After updating the environment, clear Laravel's cached configuration:

php artisan config:clear

Your application should now use NotifyTrap as its SMTP destination.

3. Send a test email

Let's use Laravel Tinker to send a quick test message.

Run:

php artisan tinker

Then execute:

use Illuminate\Support\Facades\Mail; Mail::raw( 'This is a test email captured by NotifyTrap.', function ($message) { $message ->to('developer@example.test') ->subject('Hello from Laravel'); } );

The address is only a sample recipient value. NotifyTrap captures the message locally; it does not deliver it to that address.

Open NotifyTrap and navigate to your email channel.

You should see the captured message.

That's it. Your Laravel application is using its normal SMTP workflow, but the message is being captured in your local development environment.

4. Inspect the captured email

Capturing an email is only the first step.

When debugging email functionality, you often need to inspect more than the subject and body.

NotifyTrap provides tools for examining:

  • HTML and plain-text email content.
  • Raw MIME data.
  • Headers.
  • Attachments.
  • Inline CID images.
  • Responsive email previews.
  • Dark email client simulations.

This is particularly useful when developing:

  • Password reset emails.
  • Account verification messages.
  • Order confirmations.
  • Transactional notifications.
  • Marketing templates.

Instead of guessing what Laravel generated, you can inspect the actual captured message.

5. Test OTP and magic-link emails

Authentication emails introduce another challenge.

Imagine you're testing a passwordless login flow:

  1. Your application generates a one-time password.
  2. Laravel sends an email.
  3. Your test needs to retrieve the OTP.
  4. The test submits the OTP to your verification endpoint.

Manually opening an inbox and copying the code is not a reliable automated testing strategy.

NotifyTrap includes OTP and magic-link extraction capabilities, along with APIs that can help automate notification-related workflows.

It also provides a wait API, so automation can wait for a notification instead of relying entirely on arbitrary sleep durations.

Consult the Channels and API documentation for the current API routes and response formats.

6. Go beyond the happy path

Email delivery is not always successful.

Even if your application generates a valid message, an SMTP dependency can fail or respond slowly.

Your tests should consider questions such as:

  • What happens when the SMTP service is unavailable?
  • Does your application retry?
  • Does a background job fail correctly?
  • Are failed notifications logged?
  • Does the application recover when the dependency becomes available again?

NotifyTrap includes SMTP and HTTP Chaos Rules to help simulate failure conditions and latency.

This lets you investigate failure behavior without intentionally disrupting a real notification provider.

7. Automate your workflow

NotifyTrap is not limited to its desktop interface.

It also includes:

  • A local HTTP API.
  • A standalone notifytrap-cli binary.
  • Notification waiting and retrieval commands.
  • OTP extraction.
  • Export capabilities.
  • An MCP endpoint and stdio bridge.

These features make it possible to integrate notification inspection into developer workflows and automated testing tools.

For example, instead of manually checking whether a notification arrived, a test workflow can wait for a matching notification and inspect its details.

Check the documentation for the exact command syntax and API contracts for your installed version.

A note about safety

A local testing tool should have clear boundaries.

NotifyTrap is designed to capture and inspect notifications locally, not deliver them to real recipients.

Its webhook replay functionality is restricted to loopback destinations such as 127.0.0.1, localhost, and [::1].

As always, avoid putting production credentials or real customer data into development environments.

Final thoughts

Testing Laravel emails should not require production SMTP credentials or a collection of unrelated tools.

A local SMTP capture workflow gives you a safer way to inspect the messages your application generates.

With NotifyTrap, you can start with email and expand the same local testing workflow to SMS, Push, and Webhooks.

Try it:

NotifyTrap is open source under the MIT License.

If you try this workflow, I'd love to hear how you currently test Laravel notifications and what you'd improve in a local notification testing tool.