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
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:
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:
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:
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:
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:
# 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:
mailhog |
Same ports, same interface. Same result.
Personally, I’ve set it up as a service and wrote an article about it:
📊 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.
Comments
No approved comments yet.
Sign in with a commenter account to post a comment. Sign in.