Email

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	Email
Validator	EmailValidator

Basic Usage

        1
2
3
4
5
6
7
8
9
10
11
12
        // 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.',
    )]
    protected string $email;
}
    

        1
2
3
4
5
6
        # config/validator/validation.yaml
App\Entity\Author:
    properties:
        email:
            - Email:
                message: The email "{{ value }}" is not a valid email.
    

        1
2
3
4
5
6
7
8
9
10
11
12
13
14
        <!-- 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>
            </constraint>
        </property>
    </class>
</constraint-mapping>
    

        1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
        // 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): void
    {
        $metadata->addPropertyConstraint('email', new Assert\Email([
            'message' => 'The email "{{ value }}" is not a valid email.',
        ]));
    }
}
    

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

`groups`

type: array | string default: null

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
`{{ label }}`	Corresponding form field label

`mode`

type: string default: (see below)

This option defines the pattern used to validate the email address. Valid values are:

loose uses a simple regular expression (just checks that at least one @ character is present, etc.). This validation is too simple and it's recommended to use one of the other modes instead;
html5 uses the regular expression of the HTML5 email input element, except it enforces a tld to be present.
html5-allow-no-tld uses exactly the same regular expression as the HTML5 email input element, making the backend validation consistent with the one provided by browsers.
strict validates the address according to RFC 5322 using the egulias/email-validator library (which is already installed when using Symfony Mailer; otherwise, you must install it separately).

6.2

The html5-allow-no-tld mode was introduced in 6.2.

Tip

The possible values of this option are also defined as PHP constants of Email (e.g. Email::VALIDATION_MODE_STRICT).

The default value used by this option is set in the framework.validation.email_validation_mode configuration option.

6.2

The loose value is deprecated since Symfony 6.2. Starting from Symfony 7.0, the default value of this option will be html5.

`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.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.

TOC

Version