Sending-email-in-dev

PHP / WEB DEV – Sending Emails Without SMTP

0 comment(s)

When developing a web application, you may sometimes need to simulate email sends: validating email addresses, notifications, password recovery, etc.

In a development environment, sending real emails is pointless: it’s slow, often filtered out, and can quickly turn into spam (especially if you use test addresses or an improperly configured fake SMTP).

Even though setting up a real SMTP server for production is necessary, in local environments, it's best to keep things simple and effective.

The trick I'm sharing today concerns Symfony, specifically version 6.4, which is nearing its end of life but is still widely used. The Mailer component is well-designed and offers several solutions that can also be adapted for other frameworks or web projects.

Here’s a quick overview of the methods I’ve tested, and especially those that have convinced me the most.

🧪 1. Method 1 – null://null


This is a minimalist approach, perfect for just one or two emails, without blocking your project.

In the .env file

Text
MAILER_DSN=null://null

Symfony’s mailer does nothing with this transport. No sending, no logging, no trace. It's completely silent: your code runs, but no email is sent or visible.

👉 Useful for validating that the flow works, but totally useless if you want to see the content of your emails or visualize their HTML.

If you really need to see something, you can cobble together a listener that logs messages (such as MessageLoggerListener), but let's be honest: it’s messy, it works in a pinch, but it’s not clean.

🌐 Method 2 – Using Mailtrap for Local Development


Mailtrap is a service designed to capture emails sent during development, allowing you to view them without actually sending them. It's an ideal solution for testing email delivery without any risk.

🔧 2.1. Configuration with Symfony


  • Sign up on Mailtrap
  • Create an account and set up an inbox for your project.
  • Retrieve connection details
  • Once the inbox is created, get the necessary information: user, password, host, and port.
  • Update the .env file
  • In your .env file, configure Symfony Mailer's DSN as follows:
Text
MAILER_DSN=smtp://<user>:<password>@smtp.mailtrap.io:2525

Replace "user" and "password" with the details provided by Mailtrap.

✅ Advantages

  • Email visualization: Access a web interface to view sent emails.
  • Security: No actual emails are sent, preventing production errors.
  • Easy integration: Compatible with Symfony and other PHP frameworks.

⚠️ Note

While Mailtrap is a powerful solution, it’s important to note that it's an external service. Ensure you don't use it in production to avoid accidentally sending real emails.

🪐 3. Method 3 – MailHog, my other favorite


The serious stuff!

MailHog is a fake SMTP server that captures all your emails and allows you to view them in a clean web interface.

It’s an excellent way to simulate a production environment without any risk, while staying local. This lets you test email sending without disturbing real mailboxes.

Simply launch MailHog, point Symfony towards it, and that's it—all your emails are intercepted and readable in your browser.

🐳 3.1. Option 1 – Run MailHog via Docker


If you're familiar with Docker, this is by far the fastest, cleanest, and most portable method. The command to launch MailHog in a Docker container is:

Bash
docker run -d \
--name mailhog \
-p 1025:1025 \
-p 8025:8025 \
mailhog/mailhog

This exposes an SMTP server on localhost:1025 and a web interface for viewing emails at http://localhost:8025.

In your .env file, you simply specify:

Text
MAILER_DSN=smtp://localhost:1025

That’s it! When you send an email from Symfony, you can see it immediately in MailHog's web interface.

🔧 3.2. Option 2 – Native installation (Debian, Linux)


If you're not a fan of Docker or prefer a native installation, you can run MailHog directly on your machine. Since MailHog is written in Go, the installation process is ultra simple.

Here’s how to install MailHog natively:

Bash
wget https://github.com/mailhog/MailHog/releases/download/v1.0.1/MailHog_linux_amd64
chmod +x MailHog_linux_amd64
sudo mv MailHog_linux_amd64 /usr/local/bin/mailhog

If you already have go installed, you can use this command to install it:

Bash
# Install the binary
go install mailhog
# Update $PATH so the binary is available without a full path
echo 'export PATH="$HOME/go/bin:$PATH"' >> ~/.bashrc
# ou
echo 'export PATH="$HOME/go/bin:$PATH"' >> ~/.zshrc

Then, launch MailHog with:

Bash
mailhog

Same ports, same interface. Same result.

Personally, I’ve set it up as a service and wrote an article about it:

Running MailHog on Debian 12

📊 And in Symfony?

It’s important to note that MailHog is captured by the Web Profiler in Symfony. You can view your emails directly from the Symfony debugging interface, under the 'Mails' tab of your profiler. This can be very handy for quickly checking the emails sent during development.

🧠 4. Too long; Didn’t Read


Method Real Send? View Content? Ideal For
null://null ❌ ❌ Dummy calls
Mailtrap ✅ / ❌ ✅ (file) Realistic simulation
MailHog ❌ ✅ (web UI) Realistic simulation

💬 5. Conclusion


When working with emails in a development environment, there’s no need to waste time using real SMTP servers.

MailHog excels by providing a local solution that is efficient and hassle-free, most importantly without the risk of accidentally sending an email through production SMTP due to a configuration error. Personally, I always run a small MailHog container alongside my Symfony projects. It’s simple, effective, and really pleasant to use.

You may also like:

Comments

No approved comments yet.

Sign in with a commenter account to post a comment. Sign in.