Warning: You are browsing the documentation for Symfony 4.x, which is no longer maintained.
Read the updated version of this page for Symfony 7.1 (the current stable version).
Validates that a value is a valid email address. The underlying value is cast to a string before being validated.
Applies to | property or method |
Class | |
Validator | EmailValidator |
Basic Usage
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
// src/Entity/Author.php
namespace App\Entity;
use Symfony\Component\Validator\Constraints as Assert;
class Author
{
/**
* @Assert\Email(
* message = "The email '{{ value }}' is not a valid email.",
* checkMX = true
* )
*/
protected $email;
}
1 2 3 4 5 6 7
# config/validator/validation.yaml
App\Entity\Author:
properties:
email:
- Email:
message: The email "{{ value }}" is not a valid email.
checkMX: true
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
<!-- config/validator/validation.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<constraint-mapping xmlns="http://symfony.com/schema/dic/constraint-mapping"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/constraint-mapping https://symfony.com/schema/dic/constraint-mapping/constraint-mapping-1.0.xsd">
<class name="App\Entity\Author">
<property name="email">
<constraint name="Email">
<option name="message">The email "{{ value }}" is not a valid email.</option>
<option name="checkMX">true</option>
</constraint>
</property>
</class>
</constraint-mapping>
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
// src/Entity/Author.php
namespace App\Entity;
use Symfony\Component\Validator\Constraints as Assert;
use Symfony\Component\Validator\Mapping\ClassMetadata;
class Author
{
public static function loadValidatorMetadata(ClassMetadata $metadata)
{
$metadata->addPropertyConstraint('email', new Assert\Email([
'message' => 'The email "{{ value }}" is not a valid email.',
'checkMX' => true,
]));
}
}
Note
As with most of the other constraints, null
and empty strings are
considered valid values. This is to allow them to be optional values.
If the value is mandatory, a common solution is to combine this constraint
with NotBlank.
Options
checkHost
type: boolean
default: false
4.2
This option was deprecated in Symfony 4.2.
If true, then the checkdnsrr PHP function will be used to check the validity of the MX or the A or the AAAA record of the host of the given email.
checkMX
type: boolean
default: false
4.2
This option was deprecated in Symfony 4.2.
If true, then the checkdnsrr PHP function will be used to check the validity of the MX record of the host of the given email.
Caution
This option is not reliable because it depends on the network conditions and some valid servers refuse to respond to those requests.
groups
type: array
| string
It defines the validation group or groups of this constraint. Read more about validation groups.
message
type: string
default: This value is not a valid email address.
This message is shown if the underlying data is not a valid email address.
You can use the following parameters in this message:
Parameter | Description |
---|---|
{{ value }} |
The current (invalid) value |
mode
type: string
default: loose
This option is optional and defines the pattern the email address is validated against. Valid values are:
loose
strict
html5
loose
A simple regular expression. Allows all values with an "@" symbol in, and a "." in the second host part of the email address.
strict
Performs an RFC compliant validation using the egulias/email-validator library. It's recommended to set this mode when using Symfony Mailer because the library is already installed and ready to use. Otherwise, you need to install the library separately to use this mode.
html5
This matches the pattern used for the HTML5 email input element.
normalizer
type: a PHP callable default: null
This option allows to define the PHP callable applied to the given value before checking if it is valid.
For example, you may want to pass the 'trim'
string to apply the
trim PHP function in order to ignore leading and trailing
whitespace during validation.
payload
type: mixed
default: null
This option can be used to attach arbitrary domain-specific data to a constraint. The configured payload is not used by the Validator component, but its processing is completely up to you.
For example, you may want to use several error levels to present failed constraints differently in the front-end depending on the severity of the error.