Skip to content

How to Spool Emails

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

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

When you are using the SwiftmailerBundle to send an email from a Symfony application, it will default to sending the email immediately. You may, however, want to avoid the performance hit of the communication between Swift Mailer and the email transport, 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 means that Swift Mailer does not attempt to send the email but instead saves the message to 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 by Swift Mailer.

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 swiftmailer with the memory option, use the following configuration:

1
2
3
4
# app/config/config.yml
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:

1
2
3
4
5
6
# app/config/config.yml
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.root_dir% parameter to reference the project's root:

1
path: '%kernel.root_dir%/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
$ php app/console swiftmailer:spool:send --env=prod

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

1
$ php app/console swiftmailer:spool:send --message-limit=10 --env=prod

You can also set the time limit in seconds:

1
$ php app/console swiftmailer:spool:send --time-limit=10 --env=prod

Of course you will not want to run this manually in reality. 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