How to Spool Emails

Edit this page

Warning: You are browsing the documentation for Symfony 4.2, which is no longer maintained.

Read the updated version of this page for Symfony 6.2 (the current stable version).

How to Spool Emails

The default behavior of the Symfony mailer is to send the email messages immediately. You may, however, want to avoid the performance hit of the communication to the email server, which could cause the user to wait for the next page to load while the email is sending. This can be avoided by choosing to "spool" the emails instead of sending them directly.

This makes the mailer to not attempt to send the email message but instead save it somewhere such as a file. Another process can then read from the spool and take care of sending the emails in the spool. Currently only spooling to file or memory is supported.

Spool Using Memory

When you use spooling to store the emails to memory, they will get sent right before the kernel terminates. This means the email only gets sent if the whole request got executed without any unhandled exception or any errors. To configure this spool, use the following configuration:

  • YAML
  • XML
  • PHP 
1
2
3
4
# config/packages/swiftmailer.yaml
swiftmailer:
    # ...
    spool: { type: memory }

Spool Using Files

When you use the filesystem for spooling, Symfony creates a folder in the given path for each mail service (e.g. "default" for the default service). This folder will contain files for each email in the spool. So make sure this directory is writable by Symfony (or your webserver/php)!

In order to use the spool with files, use the following configuration:

  • YAML
  • XML
  • PHP 
1
2
3
4
5
6
# config/packages/swiftmailer.yaml
swiftmailer:
    # ...
    spool:
        type: file
        path: /path/to/spooldir

Tip

If you want to store the spool somewhere with your project directory, remember that you can use the %kernel.project_dir% parameter to reference the project's root:

1
path: '%kernel.project_dir%/var/spool'

Now, when your app sends an email, it will not actually be sent but instead added to the spool. Sending the messages from the spool is done separately. There is a console command to send the messages in the spool:

1
$ APP_ENV=prod php bin/console swiftmailer:spool:send

It has an option to limit the number of messages to be sent:

1
$ APP_ENV=prod php bin/console swiftmailer:spool:send --message-limit=10

You can also set the time limit in seconds:

1
$ APP_ENV=prod php bin/console swiftmailer:spool:send --time-limit=10

In practice you will not want to run this manually. Instead, the console command should be triggered by a cron job or scheduled task and run at a regular interval.

Caution

When you create a message with SwiftMailer, it generates a Swift_Message class. If the swiftmailer service is lazy loaded, it generates instead a proxy class named Swift_Message_<someRandomCharacters>.

If you use the memory spool, this change is transparent and has no impact. But when using the filesystem spool, the message class is serialized in a file with the randomized class name. The problem is that this random class name changes on every cache clear. So if you send a mail and then you clear the cache, the message will not be unserializable.

On the next execution of swiftmailer:spool:send an error will raise because the class Swift_Message_<someRandomCharacters> doesn't exist (anymore).

The solutions are either to use the memory spool or to load the swiftmailer service without the lazy option (see Lazy Services).

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version
    Version:
    Show your Symfony expertise

    Show your Symfony expertise

    Symfony Code Performance Profiling

    Symfony Code Performance Profiling