Chapters
Scroll down to the script below, click on any sentence (including terminal blocks) to jump to that spot in the video!
Alrighty, it's finally time send real emails in production!
Mailer Transports
Mailer comes with various ways to send emails, called "transports". This smtp
one is what we're using for our Mailtrap testing. We could set up our own SMTP server to send emails... but... that's complex, and you need to do a lot of things to make sure your emails don't get marked as spam. Boo.
3rd-Party Transports
I highly, highly recommend using a 3rd-party email service. These handle all these complexities for you and Mailer provides bridges to many of these to make setup a breeze.
Mailtrap Bridge
We're using Mailtrap for testing but Mailtrap also has production sending capabilities! Fantabulous! It even has an official bridge!
At your terminal, install it with:
composer require symfony/mailtrap-mailer
After this is installed, check your IDE. In .env
, the recipe added some MAILER_DSN
stubs. We can get the real DSN values from Mailtrap, but first, we need to do some setup.
Sending Domain
Over in Mailtrap, we need to set up a "sending domain". This configures a domain you own to allow Mailtrap to properly send emails on its behalf.
Our lawyers are still negotiating the purchase of universal-travel.com
, so for now, I'm using a personal domain I own: zenstruck.com
. Add your domain here.
Once added, you'll be on this "Domain Verification" page. This is super important but Mailtrap makes it easy. Just follow the instructions until you get this green checkmark. Basically, you'll need to add a bunch of specific DNS records to your domain. DKIM, which verifies emails sent from your domain, and SPF, which authorizes Mailtrap to send emails on your domain's behalf are the most important. Mailtrap provides great documentation on these if you want to dig deeper on how exactly these work. But basically, we're telling the world that Mailtrap is allowed to send emails on our behalf.
Production MAILER_DSN
Once you have the green checkmark, click "Integrations" then "Integrate" under the "Transaction Stream" section.
We can now decide between using SMTP or API. I'll use the API, but either works. And hey! This looks familiar: like with Mailtrap testing, choose PHP, then Symfony. This is the MAILER_DSN
we need! Copy it and jump over to your editor.
This is a sensitive environment variable, so add it to .env.local
to avoid committing it to git. Comment out the Mailtrap testing DSN and paste below. I'll remove this comment because we like to keep life tidy.
Almost ready! Remember, we can only send emails in production from the domain we configured. In my case, zenstruck.com
. Open config/services.yaml
and update the global_from_email
to your domain.
Let's see if this works! In your app, book a trip. This time use a real email address. I'll set the name to Kevin
and I'll use my personal email: kevin@symfonycasts.com
. As much as I love you and space travel, put your own email here to avoid spamming me. Choose a date and book!
We're on the booking confirmation page, that's a good sign! Now, check your personal email. I'll go to mine and wait... refresh... here it is! If I click it, this is exactly what we expect! The image, attachment, everything is here!
Next, let's see how we can track sent emails with Mailtrap plus add tags and metadata to improve that tracking!
9 Comments
Hey @giorgiocba,
By "incoming" do you mean sending messages to a special email, parsing and sending to a webhook? Doesn't look like Mailtrap supports this.
for example, from a request form we have on our website
The typical pattern for this is: when the form is filled out, send an email to yourself with the form details (ie hello@mycompany.com). This would be a standard "outgoing" email.
Hope this helps,
Kevin


Hello SfCasts team!
Could you please advise why do I see 2 emails in the debug tool?
I have started with the initial configuration for the clean new SF project with --webapp option, which gave me the messenger, mailer and development smtp (webmail) components installed.
Then I have adjusted the SendEmailMessage to be transported via the sync transport.
Next, I have configured the MAILER_DSN to work with my SMTP service provider. After that I encountered the first problem: the real emails have not been delivered.
In the debug toolbar it was showing that there are 2 messages and 2 emails: The first e-mail was queued with [main] transport and second is sent with the local development smtp server. And no signs of the real DSN I have configured earlier. I thought it was the problem with my DSN string, but after some digging, I decided to disable webmail stuff at compose.override.yaml. That helped. Finally, I saw again 2 emails, but second email is sent via the proper smtp transport and the email has hit my mailbox. But still it is not clear why there were 2 emails and 2 messages in the debug toolbar?
Finally I have set the framework.mailer.message_bus option to false. Now all works just fine, but I am wondering if the described is a normal behaviour or it was some misconfiguration, or something else?
Hey @Maxim-M,
For the MAILER_DSN
problem: as I think you've figured out, when using Symfony CLI + Docker, the MAILER_DSN
is intercepted and changed to point to the mailer
container.
The double emails but only when using messenger... this one has me stumped. This is not normal behaviour and could be a misconfiguration but can't figure out what that could be. Question: is the Message-ID
header of the two emails the same?
Let's try and figure this out!
Kevin


Hey Kevin,
No, the Message-ID
is different.
I have just tried one more thing - switched the transport back to async
and, surprise! One e-mail is queued, and delivered after message consumption. I did not try this at the beginning, as there is no need in asynchronous delivery during development, so I just switched the routing to sync: 'sync://'
.
Seems like the issue is localized to synchronous transport.
Any idea where could we dig further?
Ok, I think I've replicated what your seeing. Here's a summary of what I'm seeing when SendEmailMessage
is routed to sync
:
- In profiler, 2 emails shown as sent:
- 1 to
[main]
transport - 1 to configured
MAILER_DSN
transport - Both of these have different
Message-ID
headers
- 1 to
- In profiler, 2
SendEmailMessage
shown as dispatched - Only 1 email actually sent to the configured
MAILER_DSN
but has a differentMessage-ID
from the two emails shown in the profiler...
The fact that only 1 email is actually being sent leads me to believe this is purely a profiler issue but, can you confirm this is also the case for you (despite what the profiler says, only a single email is actually being sent)?
--Kevin
I found this issue, which talks about the same thing we found. The conclusion seemed to be this is behaving correctly but still, it's a bit confusing until you understand why.


Yes, only the one e-mail is being sent.
As for the explanation on the GitHub... It could be the reason. Here is my guess: in case of the sync
transport, the profiler takes the snapshot of the request, during which the message is queued and instantly consumed, which leads to e-mail sending, also being logged. Thus we see 2 e-mails logged: first for the queuing and second for sending. And this explains why for the async
transport we see just one email and message. By the request finish time there is log for only the queued e-mail. However, it is not very clear why the e-mails have different Message-ID
. I can only guess it is due to serialize / deserialize process. And why it shows 2 messages? I think, profiler could be more clear :)
Thank you very much for your help!
No problem, I'm happy we figured this out!

"Houston: no signs of life"
Start the conversation!
What PHP libraries does this tutorial use?
// composer.json
{
"require": {
"php": ">=8.2",
"ext-ctype": "*",
"ext-iconv": "*",
"doctrine/dbal": "^3", // 3.9.4
"doctrine/doctrine-bundle": "^2.13", // 2.13.2
"doctrine/doctrine-fixtures-bundle": "^3.6", // 3.7.1
"doctrine/orm": "^3.3", // 3.3.1
"dragonmantank/cron-expression": "^3.4", // v3.4.0
"knplabs/knp-time-bundle": "^2.4", // v2.4.0
"league/html-to-markdown": "^5.1", // 5.1.1
"symfony/asset": "7.2.*", // v7.2.0
"symfony/asset-mapper": "7.2.*", // v7.2.0
"symfony/console": "7.2.*", // v7.2.1
"symfony/doctrine-messenger": "7.2.*", // v7.2.3
"symfony/dotenv": "7.2.*", // v7.2.0
"symfony/flex": "^2", // v2.4.7
"symfony/form": "7.2.*", // v7.2.0
"symfony/framework-bundle": "7.2.*", // v7.2.2
"symfony/mailer": "7.2.*", // v7.2.0
"symfony/mailtrap-mailer": "7.2.*", // v7.2.0
"symfony/messenger": "7.2.*", // v7.2.3
"symfony/monolog-bundle": "^3.10", // v3.10.0
"symfony/remote-event": "7.2.*", // v7.2.0
"symfony/runtime": "7.2.*", // v7.2.0
"symfony/scheduler": "7.2.*", // v7.2.3
"symfony/security-csrf": "7.2.*", // v7.2.2
"symfony/stimulus-bundle": "^2.21", // v2.22.1
"symfony/twig-bundle": "7.2.*", // v7.2.0
"symfony/validator": "7.2.*", // v7.2.2
"symfony/webhook": "7.2.*", // v7.2.0
"symfony/yaml": "7.2.*", // v7.2.0
"symfonycasts/tailwind-bundle": "^0.7.1", // v0.7.1
"twig/cssinliner-extra": "^3.18", // v3.18.0
"twig/extra-bundle": "^3.0", // v3.18.0
"twig/inky-extra": "^3.19", // v3.19.0
"twig/twig": "^3.0", // v3.18.0
"zenstruck/messenger-monitor-bundle": "^0.5.1" // v0.5.1
},
"require-dev": {
"phpunit/phpunit": "^9.5", // 9.6.22
"symfony/browser-kit": "7.2.*", // v7.2.0
"symfony/css-selector": "7.2.*", // v7.2.0
"symfony/debug-bundle": "7.2.*", // v7.2.0
"symfony/maker-bundle": "^1.61", // v1.62.1
"symfony/phpunit-bridge": "^7.1", // v7.2.0
"symfony/stopwatch": "7.2.*", // v7.2.2
"symfony/web-profiler-bundle": "7.2.*", // v7.2.2
"zenstruck/browser": "^1.9", // v1.9.1
"zenstruck/console-test": "^1.7", // v1.7.0
"zenstruck/foundry": "^2.2", // v2.3.0
"zenstruck/mailer-test": "^1.4" // v1.4.2
}
}
Hello. We're using Mailtrap as a tool for outgoing email, but I'm not sure what happens with incoming email. Can Mailtrap also be used to handle incoming email, for example, from a request form we have on our website?