[hypeatei]

What is your first paragraph referring to? This whole standard is trying to eliminate the context switching that happens when a website wants to verify your email.

Perhaps you mistook the two bullet points outlining what currently happens as goals for the standard?

[Arch-TK]

The new standard relies on some possibly third party (at least that seems somewhat implied here) which has a database of email addresses which it can attest exist and which is tied to some user authentication.

If the email address isn't yet known to this third party (or, you are not logged in), there _will_ be a context switch which in my example case will occur for every registration since I use a per-entity email address.

[nopassrecover]

Agree with you, though potentially easily remediated if that third party provisioned for the “+” convention.

[prmoustache]

+ is not a unique convention. I have dynamic rewrite sets so that all mails with specific prefixe s go to my mailbox:

<my initials>-site-<companyname>@<my domain> go to my personal mailbox

<my partner's initials>-app-<appname>@<her domain> go to my partner's mailbox

<daughter initials>-account-<entity name>@<my domain> go to my daughter's account

Sure you could in theory set up the server side verification mecanism for these pattern too. I am just stating that the +suffix stuff is not the only way used.

[Arch-TK]

They cannot without cooperation of the mail provider as mentioned earlier.