EmailAddressAttribute isn't validating properly

[PatrykKuniczak]

Description

Related to #65968
And
https://stackoverflow.com/a/71303601

Validation is very weak ...

Reproduction Steps

Let's use in any project

[EmailAddress]
public string Email { get; set; };

And try to use example@com and see it's valid.

That's at least bizzare, that in 2026, there's still a problem, for that big tool like .NET, to create an email validator.

Expected behavior

Work at least like:
https://stackoverflow.com/a/201336

Actual behavior

Pass example@com and more strange emails ...

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-componentmodel-dataannotations
See info in area-owners.md if you want to be subscribed.

[MihuBot]

I'm a bot. Here are possible related and/or duplicate issues (I may be wrong):

• [EmailAddress] DataAnnotations not work correctly with user@example without .com #83451
• Enhance EmailAddressAttribute to validate email address correctly #45670
• The purpose of EmailAddressAttribute? #46580
• EmailAddressAttribute doesn't check email domain #24085
• EmailAddress data annotation should be able to validate emails without needing extra regex. #86392
• System.ComponentModel.DataAnnotations EmailAddressAttribute behaviour differences by framework/execution context #27569
• Better email address attribute #27592

[PatrykKuniczak]

No NO no ...

Don't tell me:
#27592 (comment)

No way, other frameworks like Laravel, NestJS(via class-validator integration):

import { IsEmail } from 'class-validator';

export class CreateUserDto {
  @IsEmail()
  email: string;
}

Can do it, and .NET can't?

That have no sense.

Look for @MihuBot comment, there's a plenty issues about that topic. Why not simply put regexp inside that Attribute class and make it SECURE, because if somebody like me, jump from 1 tech to another, WANT TO have a daily/common validators from tool.

Of course each dev, should test everything(like i've done and that's why i've caught that ...), but in 2026 we're able to deliver better solution for that case.

I HOPE this isssue will be the last issue and after that, this BUG will be solved.

Have a good live(maybe better after that implementation 😆)

[tarekgh]

I think it is time to consider fixing this and file a breaking change as it is persistence ask we keep getting.

@vcsjones I am seeing you are voting against that, does your concern about app compat? or you have other concerns we should consider before fixing it?

[PatrykKuniczak]

@tarekgh Thanks for quick response.

I'm thrilled to see it implemented :)

[vcsjones]

or you have other concerns we should consider before fixing it?

I just generally don't think there is a single shared understanding of what "fixing it" means. example@com is a valid email address depending on what RFC you look at. It's probably not what people want, but it is correct for scenarios like intranet services.

frameworks like Laravel,

There has been plenty of discussion and confusion about how Laravel's email validation works and no one is perfectly happy with it, either. By default it actually works like .NET's.

But the problem is when I send an email address with only a top level domain and no dot like 'xxxxxx@yyyyyy', it accepts it as a valid email address.

https://stackoverflow.com/questions/58725526/validation-of-an-email-address-in-laravel

They have options to make it behave like you expect, like rfc which makes it follow RFC 5322. They also have dns for doing live DNS queries to make sure the DNS record actually exists.

and file a breaking change

Maybe it doesn't need to be a breaking change. Maybe, like Laravel's, it's opt-in if you want an RFC-5322-like validation experience.

public enum EmailValidationProfiles
{
    Default,
    Rfc5322
}

[EmailAddress(ValidationProfile = EmailValidationProfiles.Rfc5322)]
public string EmailAddress { get; }

[PatrykKuniczak]

Maybe it doesn't need to be a breaking change. Maybe, like Laravel's, it's opt-in if you want an RFC-5322-like validation experience.

public enum EmailValidationProfiles
{
    Default,
    Rfc5322
}

[EmailAddress(ValidationProfile = EmailValidationProfiles.Rfc5322)]
public string EmailAddress { get; }

Ok, good point

I like your solutuion, i don't know about intranet emails structure.

Common usage is for "normal"/internet emails, but yeah it's good to have in mind, there's other possibility.

I see we're on the good way to make it work :)