5 Ways to Implement Email Validation in C# Data Annotations

Validating emails is a common task when using C# data annotations to maintain data quality. Here, we explore five distinct methods for implementation, providing working code for each. You will see the pitfalls of common techniques and how Abstract API offers a more dependable alternative.

How to Implement Email Validation in Data Annotations

Here are four ways to add email validation to your data models. Each method uses a different C# feature, from built-in attributes to custom validation logic.

Built-in EmailAddressAttribute

You can annotate a property with the [EmailAddress] attribute. At runtime, the validation pipeline calls the EmailAddressAttribute.IsValid method. The behavior of this method depends on the .NET framework version.

In .NET 4.x, it relies on a regular expression inspired by RFC-5322. For .NET 5 and newer versions, the regex was removed, and the check became much looser. It essentially passes any string that contains an "@" symbol. Empty strings are considered invalid unless you also add the [Required] attribute, as there is no AllowEmpty flag.

public class UserDto
{
    [EmailAddress(ErrorMessage = "Bad e-mail")]
    public string? Email { get; set; }
}

RegularExpressionAttribute with a Custom Pattern

This method involves the [RegularExpression] attribute. You attach it to a property and provide a custom pattern that you control. This is a classic way to restore the strictness of pre-.NET 5 frameworks or to enforce specific corporate constraints, such as a "company.com only" rule. The same pattern works on both the server and the client.

private const string EmailPattern =
    @"^[A-Za-z0-9._%+-]+@([A-Za-z0-9-]+\.)+[A-Za-z]{2,24}$";

public class Employee
{
    [RegularExpression(EmailPattern, ErrorMessage = "Corp e-mail only")]
    public string Email { get; set; } = "";
}

Custom ValidationAttribute with System.Net.Mail.MailAddress

You can create a custom validation attribute. This requires you to subclass ValidationAttribute and delegate the validation logic to new MailAddress(email). This constructor tokenizes the email address and normalizes the domain with punycode. This approach catches obvious syntax errors without the need to maintain a complex regular expression. The attribute can be reused across different models.

public sealed class StrictEmailAttribute : ValidationAttribute
{
    protected override ValidationResult? IsValid(
        object? value, ValidationContext ctx)
    {
        if (value is not string s || string.IsNullOrWhiteSpace(s))
            return ValidationResult.Success;

        try
        {
            var addr = new System.Net.Mail.MailAddress(s);
            // optional: reject addresses lacking MX
        }
        catch
        {
            return new ValidationResult(ErrorMessage ??
                $"{ctx.MemberName} is not a valid e-mail.");
        }
        return ValidationResult.Success;
    }
}

Model-Level Validation with IValidatableObject

This technique requires your DTO to implement the IValidatableObject interface. You then add your logic inside the Validate(IEnumerable<ValidationResult>) method. Inside this method, you have access to the full object graph.

This allows for the implementation of complex, cross-field rules. For example, you can check if an email address uses a corporate domain when a IsBusinessContact flag is true. This approach keeps validation attribute noise off the model properties.

public class Contact : IValidatableObject
{
    public string? Email { get; set; }
    public bool IsBusinessContact { get; set; }

    public IEnumerable<ValidationResult> Validate(
        ValidationContext ctx)
    {
        if (string.IsNullOrWhiteSpace(Email))
            yield break;

        if (IsBusinessContact &&
            !Email.EndsWith("@contoso.com",
                StringComparison.OrdinalIgnoreCase))
            yield return new(
                "Business contacts must use a contoso address",
                new[] { nameof(Email) });

        // Delegate to central StrictEmailAttribute or a MX checker
    }
}

Challenges of Implementing Email Validation in Data Annotations

These traditional methods present several validation hurdles. The reliance on regular expressions and inconsistent framework behavior often leads to unreliable outcomes and potential security vulnerabilities for your application.

• RFC compliance is brutally complex. The EmailAddressAttribute uses a simple regex that rejects valid international emails but accepts some malformed inputs, which creates an unreliable filter.
• A spec-valid email does not guarantee deliverability. Mailbox providers have their own rules that differ from the official RFC standard. Syntax checks in data annotations often fail to predict if an email address actually works.
• The behavior of EmailAddressAttribute changes between .NET versions. Older frameworks use a strict regex, while newer ones use a looser check. Identical code can produce different validation results depending on the deployment environment.
• Complex patterns with RegularExpressionAttribute risk catastrophic backtracking, a ReDoS vulnerability. Teams must choose between a fast but unsafe regex or a slow, overly strict one, a difficult trade-off between performance and accuracy.