Is it a valid email if the email has a dash (-) at the end of local part of an email? For example,


Or to generalize, can any of these characters (Characters !#$%&'*+-/=?^_``{|}~ (ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126)), which are valid to be in local part of the email at the beginning and/or end of the email id?

Google says it is invalid, so for the time being I assume it as invalid too, though RFC excludes only [dot] character from starting with and/or ending local part.

GMail Error for the above case

Note: I'm not concerned about the domain part, because that become more involved due to the way DNS, which complicates the question and answers.


  • Good question. Have you looked at this Stack Overflow question and answer thread? Lots of info—much of it out of date at this point—but still good starting point/ Jun 18 '18 at 14:56
  • good reference link, it seems google treat that email as invalid, while Microsoft don't have any problem. Jun 18 '18 at 15:00
  • 1
    Sharing this since you brought up Google: Gmail ignores any periods in an email address, so if your email was "anunusualemail@gmail.com", you would also receive mail sent to "an.unusual.email@gmail.com". It also ignores pluses at the end of the email address: "anunusualemail+something@gmail.com".
    – mowwwalker
    Jun 19 '18 at 19:12
  • 2
    On my own mail service I can ban the letter "u" from usernames. Just because.
    – Agent_L
    Jun 20 '18 at 8:49
  • @mowwwalker: My daughter told me about gmail ignoring the periods in user names, and I thought I knew everything! What's interesting about gmail ignoring anything after the "+" is you can use that to make your own labels for your incoming email to write inbox processing scripts to process certain labels. Jul 26 at 14:25

Is it a valid email if the email has a dash (-) at the end of local part of an email? [...] Google says it is invalid, so for the time being I assume it as invalid too, though RFC excludes only [dot] character from starting with and/or ending local part.

It's valid. You're only seeing it rejected by Google because it performs a completely different check – they have their own policies on what the local-part can be, as do many other providers.

Google, or anyone else, would be obligated to accept all possibly valid email addresses only if the form was actually asking for an existing, valid email address (possibly from provider). For example, it would be an error if Gmail's To:/Cc: field rejected a valid address.

But the field you highlighted doesn't ask you for an existing email address; it asks for an account name on Google systems, which will be the basis for an email address only once the account has been created. There is nothing that would forbid Google, or anyone else, from limiting the set of valid account names (or, really, even mailbox names) on their own system.

Or, in other words, defining the allowed characters for 'local-part' only means that mail applications SMTP servers must accept such addresses in RFC 822 headers and SMTP commands – but it doesn't say anything about being able to create such mailboxes. (Indeed, back when the early email RFCs were written and most mailboxes were still tied to OS-level accounts, their names had similar or even stricter limits.)

For example, this part of RFC 5321 (section 4.1.2, below ABNFs) explicitly says that a receiving host is allowed to and indeed should have much stricter limits on how its own mailboxes are named:

While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case-sensitive.

So, although anunusualemail-@gmail.com is valid syntactically, that alone doesn't mean that Google must allow you to create it.

  • 6
    As an interesting side note, google ignores periods in email addresses (gmail.googleblog.com/2008/03/…) , which also isn't specified in the RFC. So, myname@gmail.com goes to the same place as my.name@gmail.com or m.y.n.a.m.e@gmail.com. Jun 18 '18 at 19:17
  • 4
    @JimsonKannantharaJames In general, if you want to check if an email is valid, you should actually send an email to that address and force the user to take action. Any checks just based on the syntax of the address should really just be to catch the user making typos. Jun 18 '18 at 23:13
  • 1
    @grawity Oh I know - I was commenting to give an example of another thing that's not specified in the RFC but is allowed. Jun 19 '18 at 17:37
  • 1
    @user71659 If you're not properly escaping control characters where necessary, you have a bigger problem. Ultimately the email was input by the user and user input should always be deemed dangerous. Assuming some field in your database is safe because of some validation rules can be pretty dangerous. What happens when a few months later someone else populates that field from another form which doesn't have the same validation? Jun 20 '18 at 0:54
  • 2
    @user71659 you are conflating two different issues and muddying the argument. MichaelMior is perfectly correct to state that to verify that an email address exists, you will have to send an email to that address which requires user action.
    – kumarharsh
    Jun 20 '18 at 6:42

G Suite (formally Google Apps for Your Domain) does allow hyphens (dashes) within email addresses, even as the last character.

Usernames can contain letters (a-z), numbers (0-9), dashes (-), underscores (_), apostrophes ('), and periods (.).

Source: Name and password guidelines

As you noted, Gmail does not allow hyphens in email addresses.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.