You are browsing the Symfony 4 documentation, which changes significantly from Symfony 3.x. If your app doesn't use Symfony 4 yet, browse the Symfony 3.4 documentation.

Email

4.2 version

Maintained

3.4 4.3 master

Unmaintained

2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.0 3.1 3.2 3.3 4.0 4.1

edit this page

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
Options	mode message checkMX checkHost payload
Class	`Email`
Validator	`EmailValidator`

Basic Usage¶

Annotations

// 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;
}

YAML

# config/validator/validation.yaml
App\Entity\Author:
    properties:
        email:
            - Email:
                message: The email "{{ value }}" is not a valid email.
                checkMX: true

XML

<!-- 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 http://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>

PHP

// src/Entity/Author.php
namespace App\Entity;

use Symfony\Component\Validator\Mapping\ClassMetadata;
use Symfony\Component\Validator\Constraints as Assert;

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¶

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¶

Uses the egulias/email-validator library to perform an RFC compliant validation. You will need to install that library to use this mode.

html5¶

This matches the pattern used for the HTML5 email input element.

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

checkMX¶

type: boolean default: false

New in version 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.

checkHost¶

type: boolean default: false

New in version 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.

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.