Mailer Configuration Reference (SwiftmailerBundle)
Warning: You are browsing the documentation for Symfony 4.x, which is no longer maintained.
Consider upgrading your projects to Symfony 7.2.
The SwiftmailerBundle integrates the Swiftmailer library in Symfony applications
to send emails. All these options are configured under the
swiftmailer
key in your application configuration.
1 2 3 4 5
# displays the default config values defined by Symfony
$ php bin/console config:dump-reference swiftmailer
# displays the actual config values used by your application
$ php bin/console debug:config swiftmailer
Note
When using XML, you must use the http://symfony.com/schema/dic/swiftmailer
namespace and the related XSD schema is available at:
https://symfony.com/schema/dic/swiftmailer/swiftmailer-1.0.xsd
Configuration
url
type: string
The entire SwiftMailer configuration using a DSN-like URL format.
Example: smtp://user:pass@host:port/?timeout=60&encryption=ssl&auth_mode=login&...
transport
type: string
default: smtp
The exact transport method to use to deliver emails. Valid values are:
- smtp
- gmail (see Swift Mailer)
- mail (deprecated in SwiftMailer since version 5.4.5)
- sendmail
- null (same as setting disable_delivery to
true
)
port
type: string
default: 25 or 465 (depending on encryption)
The port when using smtp
as the transport. This defaults to 465 if encryption
is ssl
and 25 otherwise.
local_domain
type: string
2.4.0
The local_domain
option was introduced in SwiftMailerBundle 2.4.0.
The domain name to use in the HELO
command.
encryption
type: string
The encryption mode to use when using smtp
as the transport. Valid values
are tls
, ssl
, or null
(indicating no encryption).
auth_mode
type: string
The authentication mode to use when using smtp
as the transport. Valid
values are plain
, login
, cram-md5
, ntlm
or null
.
spool
For details on email spooling, see Sending Emails with Mailer.
type
type: string
default: file
The method used to store spooled messages. Valid values are memory
and
file
. A custom spool should be possible by creating a service called
swiftmailer.spool.myspool
and setting this value to myspool
.
path
type: string
default: %kernel.cache_dir%/swiftmailer/spool
When using the file
spool, this is the path where the spooled messages
will be stored.
sender_address
type: string
If set, all messages will be delivered with this address as the "return
path" address, which is where bounced messages should go. This is handled
internally by Swift Mailer's Swift_Plugins_ImpersonatePlugin
class.
antiflood
threshold
type: integer
default: 99
Used with Swift_Plugins_AntiFloodPlugin
. This is the number of emails
to send before restarting the transport.
sleep
type: integer
default: 0
Used with Swift_Plugins_AntiFloodPlugin
. This is the number of seconds
to sleep during a transport restart.
delivery_addresses
type: array
Note
In previous versions, this option was called delivery_address
.
If set, all email messages will be sent to these addresses instead of being sent
to their actual recipients. This is often useful when developing. For example,
by setting this in the config/packages/dev/swiftmailer.yaml
file, you can
guarantee that all emails sent during development go to one or more some
specific accounts.
This uses Swift_Plugins_RedirectingPlugin
. Original recipients are available
on the X-Swift-To
, X-Swift-Cc
and X-Swift-Bcc
headers.
delivery_whitelist
type: array
Used in combination with delivery_address
or delivery_addresses
. If set, emails matching any
of these patterns will be delivered like normal, as well as being sent to
delivery_address
or delivery_addresses
. For details, see the
How to Work with Emails during Development
article.
disable_delivery
type: boolean
default: false
If true, the transport
will automatically be set to null
and no
emails will actually be delivered.
logging
type: boolean
default: %kernel.debug%
If true, Symfony's data collector will be activated for Swift Mailer and the information will be available in the profiler.
Tip
The following options can be set via environment variables: url
,
transport
, username
, password
, host
, port
, timeout
,
source_ip
, local_domain
, encryption
, auth_mode
. For details,
see: Configuring Symfony.
Using Multiple Mailers
You can configure multiple mailers by grouping them under the mailers
key (the default mailer is identified by the default_mailer
option):
1 2 3 4 5 6 7
swiftmailer:
default_mailer: second_mailer
mailers:
first_mailer:
# ...
second_mailer:
# ...
Each mailer is registered automatically as a service with these IDs:
1 2 3 4 5 6 7 8 9 10
// ...
// returns the first mailer
$container->get('swiftmailer.mailer.first_mailer');
// also returns the second mailer since it is the default mailer
$container->get('swiftmailer.mailer');
// returns the second mailer
$container->get('swiftmailer.mailer.second_mailer');
Caution
When configuring multiple mailers, options must be placed under the
appropriate mailer key of the configuration instead of directly under the
swiftmailer
key.
When using autowiring only the default mailer is
injected when type-hinting some argument with the \Swift_Mailer
class. If
you need to inject a different mailer in some service, use any of these
alternatives based on the service binding feature:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
# config/services.yaml
services:
_defaults:
bind:
# this injects the second mailer when type-hinting constructor arguments with \Swift_Mailer
\Swift_Mailer: '@swiftmailer.mailer.second_mailer'
# this injects the second mailer when a service constructor argument is called $specialMailer
$specialMailer: '@swiftmailer.mailer.second_mailer'
App\Some\Service:
# this injects the second mailer only for this argument of this service
$differentMailer: '@swiftmailer.mailer.second_mailer'
# ...