Symfony vs Zend Framework – PHP Framework comparison Part III: Mailers

3 min


The issue of sending and managing emails is one of the most common challenges in PHP web development. Symfony and Zend Framework both have their own solutions to help developers take care of it. In the 3rd part of my Symfony vs Zend Framework comparison, I am taking a look at their email components and create both simple and more complex email messages.

In the previous parts of my Symfony vs Zend Framework series, I talked about the issue of serialization and documentation. This time, I will be tackling what is perhaps an even more common aspect of web development: sending emails.

Some of the most typical types of email we include are “welcome” messages, emails with reset links for passwords, order confirmations and notifications. Frameworks can indeed be very helpful in doing all that and then some. But how do the Zend Mail and the recently released (May 2019 with Symfony 4.3) Symfony Mailer components compare in this aspect?

Zend Mail

Let’s start with Zend Framework’s email component – the Zend Mail. It consists of two concepts – the Message represents a single message and the Transport handles the process of sending it (e.g. via SMTP or PHP’s mail() function). Should it be necessary, one can always implement a custom version of Transport to handle other delivery services.

Zend Mail can be installed with Composer, but if one wants to use SMTP for message delivery, Service Manager is also required.

$ composer require zendframework/zend-mail
$ composer require zendframework/zend-servicemanager

In order to send a simple email message, the example code from the documentation will suffice.

I’m now running a local MailHog instance in the Docker container so I can see the results.

A screenshot of a plain text message in Zend.

As you can see, it takes fewer than 20 lines of code to send a really simple message. However, since HTML-based emails are now more common, I am now going to make a more complex email, which includes both plain text and HTML body as well as an attachment.

This time, we need a lot more lines of code to create an email. Separate objects need to be made:

  • one that represents the plain text message,
  • one that represents the HTML message,
  • one that integrates the two above,
  • one for image attachment,
  • one for integrating the image with the rest of the content.

Only then, we can create a Message instance similar to the one in the previous example and then send via Transport.

The result can be seen below – a message that includes both text and HTML content.

An example of a text and html email in Zend.

An example of a multipart email in Zend.

Symfony Mailer

As I said before, the Mailer is one of the latest additions to the Symfony framework. Before, the recommended method of sending emails in Symfony applications was Swift Mailer. With the new addition, the whole process was significantly simplified.

Much like in Zend Mail, Symfony Mailer introduces the Transport and Email concepts. The latter is a part of the Mime component, which serves as a dependency of Symfony Mailer. The package allows us to use Transport to send emails via Sendmail or SMTP, but there are also additional packages, which makes it possible to use other delivery services such as Mailgun, SendGrid or Amazon SES.

Let’s start by installing the dependency via Composer.

$ composer require symfony/mailer

Now we can initialize Transport and send a simple message.

Let’s now use MailHog to catch the emails.

A screenshot of a plain text message in Symfony.

Sending a simple plain text message again required fewer than 20 lines of code. Now, let’s try to send one with plain text, HTML content and an attachment.

The resulting message that includes both plain text and HTML can be seen below.

An example of a text and html email in Symfony.

An example of a multipart email in Symfony.

Creating a message like this with Symfony Mailer required only two additional method calls – one for HTML content and one for the attachment.


Our little test showed that while sending simple emails takes about an equal amount of code and effort in both Symfony and Zend Framework, sending complex messages is significantly easier with Symfony Mailer. It also provides support for more delivery services as separate packages. Out of the two, Zend Mail is much older so it may have been more fair to compare it with Swift Mailer. Still, when it comes to complex and numerous email messages, Swift Mailer was also superior.

However, there is one aspect of the process in which it is Zend Mail that has the upper hand – reading emails. Zend Mail provides special classes for fetching messages from mailboxes via POP3 or IMAP protocols. It’s a very important argument for using it when it comes to building a mail client in PHP.

And that’s it for the topic of mailers. Expect the next part of my comparison in which I’m going to take a look at Cache components. Stay tuned!

What do you want to achieve?

You can upload a file (optional)

Upload file

File should be .pdf, .doc, .docx, .rtf, .jpg, .jpeg, .png format, max size 5 MB

0 % of

or contact us directly at [email protected]

This site is protected by reCAPTCHA and the Google
Privacy Policy and Terms of Service apply.


Thank you!

Your message has been sent. We’ll get back to you in 24 hours.

Back to page

We’ll get back to you in 24 hours

to get to know each other and address your needs as quick as possible.


We'll work together on possible scenarios

for the software development strategy in sync with your goals.


We’ll turn the strategy into an actionable plan

and provide you with experienced development teams to execute it.

Our work was featured in:

Tech Crunch
Business Insider

Aplikujesz do

The Software House

CopiedTekst skopiowany!

Nie zapomnij dodać klauzuli:

Kopiuj do schowka

Jakie będą kolejne kroki?


Rozmowa telefoniczna

Krótka rozmowa o twoim doświadczeniu,
umiejętnościach i oczekiwaniach.

Test task

Zadanie testowe

Praktyczne zadanie sprawdzające dokładnie
poziom twoich umiejętności.


Spotkanie w biurze

Rozmowa w biurze The Software House,
pozwalająca nam się lepiej poznać.

Response 200

Response 200

Ostateczna odpowiedź i propozycja
finansowa (w ciągu kilku dni od spotkania).


Webinar for CTOs: How to update your company’s legacy software

Sign up