Quais caracteres são permitidos em um endereço de email?


641

Não estou perguntando sobre a validação completa do email.

Eu só quero saber o que são permitidos caracteres user-namee serverpartes do endereço de email. Isso pode ser simplificado demais, talvez os endereços de e-mail possam assumir outras formas, mas não me importo. Estou perguntando apenas sobre este formulário simples: user-name@server(por exemplo, wild.wezyr@best-server-ever.com) e permiti caracteres em ambas as partes.


185
O +é permitido. Isso me deixa maluco quando os sites não o permitem, porque meu e-mail contém +e muitos sites não o permitem.
Dan Herbert

42
Eu acho que é importante fornecer links para as especificações, pois você realmente deseja fazer isso direito, e é aí que as especificações entram. Se você está com preguiça de ler e entender as especificações, por favor, verifique os caracteres permitidos nos endereços de e-mail para as pessoas que se preocupam com isso.
jhwist

9
Pergunta anterior sobre o mesmo material: stackoverflow.com/questions/760150/ . O triste é que, embora essa pergunta seja quase 8 meses mais antiga que essa, a pergunta mais antiga tem respostas muito melhores. Quase todas as respostas abaixo já estavam desatualizadas quando foram publicadas originalmente. Veja a entrada da Wikipedia (e não se preocupe, ela possui referências oficiais relevantes ).
John Y

10
Ao contrário de várias respostas, os espaços são permitidos na parte local dos endereços de email, se citados. "hello world"@example.comé válido.
precisa saber é o seguinte

3
@LaraRuffleColes - para o Gmail, quando você cria uma conta de e-mail, ele não permite que você crie endereços contendo um sinal de "+". O sinal "+" ("Endereço positivo") permite que qualquer pessoa com um endereço do Gmail adicione um sinal "+" seguido de uma "sequência" ao final do nome de usuário para criar um endereço de e-mail "alternativo" ("alias") para usar em sua conta. Exemplo: "example@gmail.com", "example+tag@gmail.com". Um uso típico (e provavelmente "Primário") disso é ser capaz de criar endereços de e-mail alternativos para sua conta, que permitem marcar e filtrar as mensagens de e-mail recebidas, teoricamente filtradas pelo remetente.
Kevin Fegan

Respostas:


797

Consulte RFC 5322: Internet Message Format e, em menor grau, RFC 5321: Simple Mail Transfer Protocol .

O RFC 822 também cobre endereços de email, mas lida principalmente com sua estrutura:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

E, como sempre, a Wikipedia possui um artigo decente sobre endereços de email :

A parte local do endereço de email pode usar qualquer um destes caracteres ASCII:

  • letras latinas maiúsculas e minúsculas A para Ze apara z;
  • dígitos 0para 9;
  • caracteres especiais !#$%&'*+-/=?^_`{|}~;
  • ponto ., desde que não seja o primeiro ou o último caractere, a menos que citado, e também que não apareça consecutivamente, a menos que seja citado (por exemplo,John..Doe@example.com não é permitido, mas "John..Doe"@example.comé permitido);
  • espaço e "(),:;<>@[\] caracteres são permitidos com restrições (eles são permitidos apenas dentro de uma cadeia de caracteres entre aspas, conforme descrito no parágrafo abaixo; além disso, uma barra invertida ou aspas duplas devem ser precedidas por uma barra invertida);
  • comentários são permitidos com parênteses nas extremidades da parte local; por exemplo, john.smith(comment)@example.come (comment)john.smith@example.comsão ambos equivalentes a john.smith@example.com.

Além dos caracteres ASCII, a partir de 2012 você pode usar caracteres internacionais acimaU+007F , codificados como UTF-8, conforme descrito na especificação RFC 6532 e explicado na Wikipedia . Observe que, a partir de 2019, esses padrões ainda serão marcados como Propostos, mas serão lançados lentamente. As alterações nessa especificação adicionaram essencialmente caracteres internacionais como caracteres alfanuméricos válidos (texto) sem afetar as regras de caracteres especiais permitidos e restritos, como !#e @:.

Para validação, consulte Usando uma expressão regular para validar um endereço de email .

A domainpeça é definida da seguinte forma :

Os padrões da Internet (Request for Comments) para protocolos de mandato que os rótulos de nome de host de componentes podem conter apenas as letras ASCII aatravés z(de um modo case-insensitive), os dígitos 0através 9, eo hífen ( -). A especificação original de nomes de host no RFC 952 exigia que os rótulos não pudessem começar com um dígito ou hífen e não deveriam terminar com um hífen. No entanto, uma especificação subsequente ( RFC 1123 ) permitiu que os rótulos de nome de host iniciassem com dígitos. Não são permitidos outros símbolos, caracteres de pontuação ou espaços em branco.


15
@WildWzyr, não é assim tão simples. Os endereços de email têm muitas regras para o que é permitido. É mais simples consultar as especificações do que listar todas elas. Se você quer a completa Regex, verifique aqui para ter uma idéia de por que isso não é tão simples: regular-expressions.info/email.html
Dan Herbert

6
não existe uma lista simples, apenas porque você deseja algo simples, não significa que será assim. alguns caracteres podem estar apenas em determinados locais e não em outros. você não pode ter o que deseja o tempo todo.

15
@WildWezyr Bem, o caractere de ponto final é permitido na parte local. Mas não no começo ou no fim. Ou com outro ponto final. Portanto, a resposta NÃO é tão simples quanto apenas uma lista de caracteres permitidos, existem regras sobre como esses caracteres podem ser usados ​​- .ann..other.@example.comnão é um endereço de email válido, mas sim ann.other@example.com, mesmo que ambos usem os mesmos caracteres.
Mark Pim

14
Além disso, lembre-se de que com nomes de domínio internacionalizados chegando, a lista de caracteres permitidos explodirá.
precisa saber é o seguinte

50
Esta não é mais a resposta válida, devido a endereços internacionalizados. Veja a resposta de Mason.
ZacharyP

329

Cuidado! Há um monte de podridão de conhecimento nesse segmento (coisas que costumavam ser verdadeiras e agora não são).

Para evitar rejeições falso-positivas de endereços de email reais no mundo atual e futuro e de qualquer lugar do mundo, você precisa conhecer pelo menos o conceito de alto nível da RFC 3490 , "Internacionalizando nomes de domínio em aplicativos (IDNA)". Eu sei que as pessoas nos EUA e A geralmente não gostam disso, mas ele já está em uso disseminado e rapidamente crescente em todo o mundo (principalmente nas partes dominadas que não são inglesas).

O essencial é que agora você pode usar endereços como mason @ 日本 .com e wildwezyr@fahrvergnügen.net. Não, isso ainda não é compatível com tudo o que existe por aí (como muitos já lamentaram acima, mesmo endereços simples no estilo qmail + ident são geralmente rejeitados incorretamente). Mas há uma RFC, há uma especificação, agora é apoiada pela IETF e ICANN e, mais importante, há um número crescente e crescente de implementações que suportam essa melhoria que estão em serviço no momento.

Eu não sabia muito sobre esse desenvolvimento até voltar para o Japão e começar a ver endereços de email como hei @ や る .ca e URLs da Amazon como este:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ス - デ ジ タ カ メ ラ - ポ ー タ ブ ル デ デ オ オ / b / ref = topnav_storetab_e? ie = UTF8 & node = 3210981

Sei que você não deseja links para especificações, mas se você confiar apenas no conhecimento desatualizado de hackers nos fóruns da Internet, seu validador de email acabará rejeitando endereços de email que usuários que não falam inglês esperam cada vez mais trabalhar. Para esses usuários, essa validação será tão irritante quanto a forma comum de morte encefálica que todos odiamos, aquela que não pode lidar com um + ou um nome de domínio em três partes ou o que seja.

Portanto, não estou dizendo que não é um aborrecimento, mas a lista completa de caracteres "permitidos sob algumas / quaisquer / nenhuma / nenhuma condição" é (quase) todos os caracteres em todos os idiomas. Se você deseja "aceitar todos os endereços de email válidos (e muitos inválidos também)", é necessário levar em consideração o IDN, o que basicamente torna inútil uma abordagem baseada em caracteres, a menos que você primeiro converta os endereços de email internacionalizados em Punycode .

Depois de fazer isso, você pode seguir (a maioria) os conselhos acima.


17
Direita; nos bastidores, os nomes de domínio ainda são apenas ASCII. Porém, se seu aplicativo da web ou formulário aceitar a entrada inserida pelo usuário, ele precisará executar o mesmo trabalho que o navegador da Web ou o cliente de email quando o usuário digitar um nome de host IDN: para converter a entrada do usuário em um formato compatível com DNS. Então valide. Caso contrário, esses endereços de email internacionalizados não serão aprovados na sua validação. (Conversores como o que eu vinculei para modificar apenas os caracteres não ASCII que são dados, portanto, é seguro usá-los em endereços de e-mail não internacionalizados (que acabam de ser devolvidos sem modificação).)
Mason

2
Para desenvolvedores de Javascript , agora estou pesquisando métodos para fazer isso, e o Punycode.js parece ser a solução mais completa e refinada.
fácil

5
Observe que o email internacionalizado (conforme definido atualmente) não converte endereços não ASCII usando punycode ou similar, estendendo grandes partes do próprio protocolo SMTP para usar UTF8.
IMSoP

2
Estou faltando alguma coisa ou isso não responde à pergunta? Estou lendo 'a outra resposta está errada, você precisa aceitar mais caracteres', mas falha ao indicar quais caracteres extras. Também não consegui (facilmente) ver nesse RFC se isso significa todos os pontos de código Unicode ou apenas o BMP.
Samuel Harmer

3
Este parece estar no caminho certo para ser a resposta correta. Aposto que receberia muito mais votos se você incluísse detalhes sobre caracteres reservados e permitidos.
21717 Sean

59

O formato do endereço de e-mail é: local-part@domain-part(máx. 64 @ 255 caracteres, não mais 256 no total).

o local-part e domain-partpoderia ter um conjunto diferente de caracteres permitidos, mas isso não é tudo, pois há mais regras.

Em geral, a parte local pode ter esses caracteres ASCII:

  • minúsculas letras latinas: abcdefghijklmnopqrstuvwxyz,
  • letras latinas maiúsculas: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • dígitos: 0123456789 ,
  • caracteres especiais: !#$%&'*+-/=?^_`{|}~ ,
  • ponto: . (não é o primeiro ou o último caractere ou repetido a menos que seja citado)
  • pontuações de espaço, como: "(),:;<>@[\] (com algumas restrições),
  • comentários: ()(são permitidos entre parênteses, por exemplo (comment)john.smith@example.com).

Parte do domínio:

  • letras latinas minúsculas: abcdefghijklmnopqrstuvwxyz,
  • letras latinas maiúsculas: ABCDEFGHIJKLMNOPQRSTUVWXYZ ,
  • dígitos: 0123456789 ,
  • hífen: - (não é o primeiro ou o último caractere),
  • pode conter um endereço IP entre colchetes: jsmith@[192.168.2.1]ou jsmith@[IPv6:2001:db8::1].

Esses endereços de email são válidos:

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com (parte local de uma letra)
  • "much.more unusual"@example.com
  • "very.unusual.@.unusual.com"@example.com
  • "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
  • example-indeed@strange-example.com
  • admin@mailserver1 (nome de domínio local sem domínio de nível superior)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org (espaço entre aspas)
  • example@localhost (enviado do host local)
  • example@s.solutions(consulte a Lista de domínios de nível superior da Internet )
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

E estes exemplos de inválidos:

  • Abc.example.com(sem @caractere)
  • A@b@c@example.com(apenas um @é permitido entre aspas)
  • a"b(c)d,e:f;gi[j\k]l@example.com (nenhum dos caracteres especiais nesta parte local é permitido entre aspas)
  • just"not"right@example.com (as cadeias citadas devem ser separadas por pontos ou o único elemento que compõe a parte local)
  • this is"not\allowed@example.com (espaços, aspas e barras invertidas só podem existir quando estiverem dentro de cadeias entre aspas e precedidos por uma barra invertida)
  • this\ still\"not\allowed@example.com (mesmo que escapado (precedido por uma barra invertida), os espaços, as aspas e as barras invertidas ainda devem estar contidos entre aspas)
  • john..doe@example.com(ponto duplo antes @); (com ressalva: o Gmail deixa isso passar)
  • john.doe@example..com(ponto duplo depois @)
  • um endereço válido com um espaço à esquerda
  • um endereço válido com um espaço à direita

Fonte: Endereço de email na Wikipedia


Regex RFC2822 do Perl para validação de e-mails:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

O regexp completo para endereços RFC2822 foi de apenas 3,7k.

Consulte também: Analisador de Endereço de Email RFC 822 em PHP .


As definições formais de endereços de email estão em:

  • RFC 5322 (seções 3.2.3 e 3.4.1, obsoletas na RFC 2822), RFC 5321, RFC 3696,
  • RFC 6531 (caracteres permitidos).

Relacionado:


5
Como uma precaução extra para os possíveis implementadores desse regex: não. Apenas verifique se ele segue o formato something@something.somethinge o chame por dia.
21817 Chris Sobolewski

Enquanto algo como isso não é sustentável, é um bom exercício para decodificar e realmente descobrir o que ele faz
unjankify

@ChrisSobolewski permite várias coisas de ambos os lados do '@'
Jasen

Eu tentei implementar isso no postfix via tabela de acesso pcre sob uma restrição check_recipient_access, primeiro convertendo os 3 pcres longos (da página vinculada) em uma linha cada e cobrindo e seguindo assim: /^[...pcre ..] $ / DUNNO, adicionando uma linha final /.*/ REJECT, mas ainda permite endereços de email inválidos. Postfix 3.3.0; perl 5, versão 26, subversão 1 (v5.26.1).
Scoobydoo

3
Loucura eu digo. Quem o usaria na produção. Há um ponto em que a expressão regular não deve mais ser usada. Está muito além desse ponto.
tomuxmon

22

A Wikipedia tem um bom artigo sobre isso , e as especificações oficiais estão aqui . Partida Wikipdia:

A parte local do endereço de email pode usar qualquer um destes caracteres ASCII:

  • Letras maiúsculas e minúsculas em inglês (az, AZ)
  • Dígitos 0 a 9
  • Personagens ! # $% & '* + - / =? ^ _ `{| } ~
  • Personagem . (ponto, ponto, ponto final), desde que não seja o primeiro ou o último caractere e também não apareça duas ou mais vezes consecutivas.

Além disso, cadeias de caracteres entre aspas (por exemplo: "John Doe" @ example.com) são permitidas, permitindo assim caracteres que de outra forma seriam proibidos, no entanto, eles não aparecem na prática comum. RFC 5321 também adverte que "um host que espera receber e-mails deve evitar definir caixas de correio onde a parte local exige (ou usa) o formulário entre aspas".


@WildWezyr Nomes de host válidos, que podem ser um endereço IP, FQN ou algo resolvível para um host de rede local.
precisa saber é o seguinte

As strings citadas eram essenciais para passar por um gateway, lembra-se do Banyan Vines?
Mckenzm #

13

O Google faz uma coisa interessante com seus endereços gmail.com. Os endereços gmail.com permitem apenas letras (az), números e pontos (que são ignorados).

por exemplo, pikachu@gmail.com é o mesmo que pi.kachu@gmail.com, e os dois endereços de email serão enviados para a mesma caixa de correio. PIKACHU@gmail.com também é entregue na mesma caixa de correio.

Portanto, para responder à pergunta, às vezes depende do implementador de quanto dos padrões RFC eles desejam seguir. O estilo de endereço gmail.com do Google é compatível com os padrões. Eles fazem dessa maneira para evitar confusão, onde pessoas diferentes usariam endereços de email semelhantes, por exemplo

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

O link da Wikipedia é uma boa referência sobre quais endereços de email geralmente permitem. http://en.wikipedia.org/wiki/Email_address


2
Sim, esta é uma ótima resposta sobre por que o Gmail não permite criar e-mails com isso. Mas você pode enviar e receber e-mails {john'doe}@my.serversem nenhum problema. Testado com o servidor hMail também.
Piotr Kula

Você pode testar seu cliente enviando um email para {piotr'kula}@kula.solutions- Se funcionar, você receberá uma boa resposta automática. Caso contrário, nada acontecerá.
Piotr Kula

3
O Gmail segue a RFC 6530 no sentido de que todos os endereços de email possíveis permitidos pelo Gmail são válidos de acordo com a RFC. O Gmail decide restringir ainda mais o conjunto de endereços permitidos com regras adicionais e criar endereços semelhantes com pontos na parte local, opcionalmente seguidos por "+" e caracteres alfanuméricos, sinônimos.
Teemu Leisti

O Google limita os critérios de criação da conta ... imagino que eles limpem a sequência de contas de e-mail recebida da "pontuação" extra e o sinal de seqüência de caracteres de alias mais à direita, para que o email possa ser roteado para a conta adequada. Mole-mole. Ao fazer isso, eles efetivamente não permitem que as pessoas criem endereços de e-mail apenas para ser idiotas, de modo que os endereços válidos criados geralmente passem por validações simples e mais complexas.
precisa saber é o seguinte

Não é apenas o Gmail. Alguns provedores têm "filtros de retransmissão" que rejeitam determinadas strings citadas, particularmente contendo "=" como se fossem delimitadores. Isso é para impedir que os usuários configurem gateways e aninhem endereços de spam na cadeia de caracteres privada citada. "@" é válido, mas "= @ =" não é (considerado) válido.
Mckenzm

12

Você pode começar pelo artigo da wikipedia :

  • Letras maiúsculas e minúsculas em inglês (az, AZ)
  • Dígitos 0 a 9
  • Personagens ! # $% & '* + - / =? ^ _ `{| } ~
  • Personagem . (ponto, ponto, ponto final), desde que não seja o primeiro ou o último caractere e também não apareça duas ou mais vezes consecutivas.

11

Nome:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

Servidor:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

4
Que tal <>e []? Por exemplo "()<>[]:,;@\\\"!#$%&'-/=?^_{} | ~ .a "@ example.org`?
kenorb

20
Por favor, cite fontes. Sem fontes, isso parece conjectura.
Mathieu K.

15
Isso está desatualizado e possivelmente nunca foi correto.
Jason Harrison

9

Verifique @ e. e, em seguida, envie um e-mail para verificação.

Ainda não consigo usar meu endereço de email .name em 20% dos sites da Internet porque alguém estragou sua validação de email ou porque antecede a validade dos novos endereços.


9
Até . não é estritamente necessário; Ouvi falar de pelo menos um caso de endereço de email em um domínio de nível superior (especificamente em ua). O endereço era <name> @ua - sem ponto!

Essa é a maneira mais fácil de não atrapalhar sua validação, porque quase tudo é permitido e, se algo não for permitido, o servidor do destinatário informará você.
Avamander

5

A resposta curta é que existem 2 respostas. Há um padrão para o que você deve fazer. ou seja, um comportamento sábio e que o manterá longe de problemas. Há outro padrão (muito mais amplo) para o comportamento que você deve aceitar sem causar problemas. Essa dualidade funciona para enviar e aceitar emails, mas tem ampla aplicação na vida.

Para um bom guia para os endereços que você cria; veja: http://www.remote.org/jochen/mail/info/chars.html

Para filtrar emails válidos, basta transmitir qualquer coisa compreensível o suficiente para ver a próxima etapa. Ou comece a ler um monte de RFCs, cuidado, aqui estão dragões.


O link se foi. Que conteúdo havia?
ygoe 26/05/19

5

Uma boa leitura sobre o assunto .

Excerto:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

1
Eu estava pensando sobre o '@' antes da parte do domínio. Isso pode ser usado?
Saiyaff Farouk 16/03

@SaiyaffFarouk de acordo com a especificação, sim. No entanto, a maioria dos provedores de email provavelmente não vai permitir isso como parte de sua própria validação
Luke Madhanga

esse blog lista Joe.\\Blow@example.comsem aspas. Isso é realmente válido? Não parece claro, dadas as respostas aqui, mas estou perguntando porque vi casos (muito raros) de seqüências de email DNS SoA rname que contêm barras invertidas.
wesinat0r 22/04

5

A resposta aceita se refere a um artigo da Wikipedia ao discutir a parte local válida de um endereço de email, mas a Wikipedia não é uma autoridade nisso.

O IETF RFC 3696 é uma autoridade nesse assunto e deve ser consultado na seção 3. Restrições nos endereços de email na página 5:

Os endereços de email contemporâneos consistem em uma "parte local" separada de uma "parte do domínio" (um nome de domínio totalmente qualificado) por um sinal de arroba ("@"). A sintaxe da parte do domínio corresponde à da seção anterior. As preocupações identificadas nessa seção sobre filtragem e listas de nomes também se aplicam aos nomes de domínio usados ​​em um contexto de email. O nome do domínio também pode ser substituído por um endereço IP entre colchetes, mas esse formulário é fortemente desencorajado, exceto para fins de teste e solução de problemas.

A parte local pode aparecer usando as convenções de cotação descritas abaixo. Os formulários citados raramente são usados ​​na prática, mas são necessários para alguns fins legítimos. Portanto, eles não devem ser rejeitados nas rotinas de filtragem, mas devem ser passados ​​para o sistema de email para avaliação pelo host de destino.

A regra exata é que qualquer caractere ASCII, incluindo caracteres de controle, possa aparecer entre aspas ou em uma sequência entre aspas. Quando é necessário citar, o caractere de barra invertida é usado para citar o seguinte caractere. Por exemplo

  Abc\@def@example.com

é uma forma válida de um endereço de email. Espaços em branco também podem aparecer, como em

  Fred\ Bloggs@example.com

O caractere de barra invertida também pode ser usado para citar a si mesmo, por exemplo,

  Joe.\\Blow@example.com

Além de citar usando o caractere de barra invertida, caracteres de aspas duplas convencionais podem ser usados ​​para cercar seqüências de caracteres. Por exemplo

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

são formas alternativas dos dois primeiros exemplos acima. Esses formulários citados raramente são recomendados e são incomuns na prática, mas, conforme discutido acima, devem ser suportados por aplicativos que estão processando endereços de email. Em particular, os formulários citados frequentemente aparecem no contexto de endereços associados a transições de outros sistemas e contextos; esses requisitos de transição ainda surgem e, como um sistema que aceita um endereço de email fornecido pelo usuário não pode "saber" se esse endereço está associado a um sistema legado, os formulários de endereço devem ser aceitos e passados ​​para o ambiente de email.

Sem aspas, as partes locais podem consistir em qualquer combinação de
caracteres alfabéticos, dígitos ou qualquer um dos caracteres especiais

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

O período (".") também pode aparecer, mas não pode ser usado para iniciar ou terminar a parte local, nem dois ou mais períodos consecutivos. Em outras palavras, qualquer caractere gráfico (de impressão) ASCII que não seja o sinal de arroba ("@"), barra invertida, aspas duplas, vírgula ou colchetes pode aparecer sem aspas. Se alguma dessas listas de caracteres excluídos aparecer, elas devem ser citadas. Formulários como

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

são válidos e são vistos com bastante regularidade, mas qualquer um dos caracteres listados acima é permitido.

Como outros fizeram, envio uma regex que funciona tanto para PHP quanto para JavaScript para validar endereços de email:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

3

Como pode ser encontrado neste link da Wikipedia

A parte local do endereço de email pode usar qualquer um destes caracteres ASCII:

  • letras latinas maiúsculas e minúsculasA para Ze apara z;

  • dígitos 0para 9;

  • caracteres especiais !#$%&'*+-/=?^_`{|}~;

  • dot ., desde que não seja o primeiro ou o último caractere, a menos que citado, e também que não apareça consecutivamente, a menos que seja citado (por exemplo,John..Doe@example.com não é permitido, mas "John..Doe"@example.comé permitido);

  • espaço e"(),:;<>@[\] caracteres são permitidos com restrições (eles são permitidos apenas dentro de uma cadeia de caracteres entre aspas, conforme descrito no parágrafo abaixo; além disso, uma barra invertida ou aspas duplas devem ser precedidas por uma barra invertida);

  • comentários são permitidos com parênteses nas extremidades da parte local; por exemplo, john.smith(comment)@example.come (comment)john.smith@example.comsão ambos equivalentes a john.smith@example.com.

Além dos caracteres ASCII acima, caracteres internacionais acima de U + 007F, codificados como UTF-8, são permitidos pela RFC 6531 , embora os sistemas de correio possam restringir quais caracteres usar ao atribuir peças locais.

Uma cadeia de caracteres citada pode existir como uma entidade separada por pontos na parte local ou quando as aspas mais externas são os caracteres mais externos da parte local (por exemplo, abc."defghi".xyz@example.comou "abcdefghixyz"@example.comsão permitidas. Por outro lado, abc"defghi"xyz@example.comnão é; nem é abc\"def\"ghi@example.com). Strings e caracteres entre aspas, no entanto, não são comumente usados. RFC 5321 também adverte que "um host que espera receber e-mails deve evitar definir caixas de correio onde a parte local exige (ou usa) o formulário entre aspas".

A parte local postmasteré tratada especialmente - não faz distinção entre maiúsculas e minúsculas e deve ser encaminhada ao administrador de email do domínio. Tecnicamente todos os outros de peças locais são case-sensitive, portanto, jsmith@example.come JSmith@example.comespecificar diferentes caixas de correio; no entanto, muitas organizações tratam letras maiúsculas e minúsculas como equivalentes.

Apesar da grande variedade de caracteres especiais que são tecnicamente válidos; organizações, serviços de correio, servidores de correio e clientes de correio na prática geralmente não aceitam todos eles. Por exemplo, o Windows Live Hotmail permite apenas a criação de endereços de email usando alfanuméricos, ponto ( .), sublinhado ( _) e hífen ( -). Conselho comum é evitar o uso de caracteres especiais para evitar o risco de emails rejeitados.


0

A resposta é (quase) ALL(ASCII de 7 bits).
Se as regras de inclusão forem "... permitidas sob algumas / algumas / nenhumas condições ..."

Apenas observando uma das várias regras de inclusão possíveis para o texto permitido na parte "texto do domínio" na RFC 5322 na parte superior da página 17, encontramos:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

os três únicos caracteres ausentes nesta descrição são usados ​​no literal do domínio [], para formar um par de aspas \e o caractere de espaço em branco (% d32). Com isso, todo o intervalo 32-126 (decimal) é usado. Um requisito semelhante aparece como "qtext" e "ctext". Muitos caracteres de controle também são permitidos / usados. Uma lista desses caracteres de controle aparece na página 31, seção 4.1 do RFC 5322, como obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

Todos esses caracteres de controle são permitidos conforme indicado no início da seção 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

E essa regra de inclusão é, portanto, "muito ampla". Ou, em outro sentido, a regra esperada é "muito simplista".


0

Por uma questão de simplicidade, eu desinfecto o envio removendo todo o texto entre aspas duplas e os associados entre aspas duplas antes da validação, colocando o kibosh nos envios de endereços de email com base no que não é permitido. Só porque alguém pode ter o John .. "O * $ hizzle * Bizzle" .. O endereço Doe@whatever.com não significa que eu tenho que permitir isso no meu sistema. Estamos vivendo no futuro, onde talvez leve menos tempo para obter um endereço de e-mail gratuito do que para fazer um bom trabalho limpando sua bunda. E não é como se os critérios de e-mail não fossem colados ao lado da entrada dizendo o que é e o que não é permitido.

Também desinfecto o que especificamente não é permitido por várias RFCs após a remoção do material citado. A lista de caracteres e padrões especificamente não permitidos parece ser uma lista muito mais curta para testar.

Não permitido:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

No exemplo dado:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

Enviar uma mensagem de e-mail de confirmação para o resultado restante após uma tentativa de adicionar ou alterar o endereço de e-mail é uma boa maneira de verificar se seu código pode lidar com o endereço de e-mail enviado. Se o email passar na validação após quantas rodadas de higienização forem necessárias, inicie essa confirmação. Se uma solicitação retornar do link de confirmação, o novo email poderá ser movido do status ou armazenamento do purgatório || temporário || em espera para se tornar um email armazenado de primeira classe real e genuíno.

Uma notificação de falha ou sucesso na alteração do endereço de email pode ser enviada para o endereço de email antigo, se você quiser considerar. As configurações não confirmadas da conta podem cair fora do sistema, pois as tentativas com falha ocorreram completamente após um período de tempo razoável.

Não permito e-mails fedido no meu sistema, talvez isso seja apenas jogar dinheiro fora. Porém, 99,9% das vezes as pessoas fazem a coisa certa e têm um email que não leva os limites de conformidade ao limite, utilizando cenários de compatibilidade de casos extremos. Cuidado com o regex DDoS, este é um local onde você pode ter problemas. E isso está relacionado à terceira coisa que faço, eu limitei o tempo que estou disposto a processar qualquer email. Se ele precisar desacelerar minha máquina para ser validado - não estará ultrapassando a lógica do ponto de extremidade da minha API de dados de entrada.

Edit: Esta resposta continuou sendo enganada por ser "ruim", e talvez merecesse. Talvez ainda esteja ruim, talvez não.


2
Eu acho que esta resposta foi rebaixada porque esta é uma opinião e, na verdade, não responde à pergunta. Além disso, os usuários que obtêm seu endereço de email silenciosamente higienizado nunca receberão emails de você. É melhor informá-los que o endereço de e-mail deles não é aceito.
Vcarel

2
Eu suspeito que os votos negativos são porque existem muitas idéias aqui. A lista não permitida, embora sejam testes de unidade úteis, deve ser precedida pelo que é permitido. A abordagem de programação parece relativamente boa, mas provavelmente se encaixaria melhor depois de listar as especificações com as quais você está trabalhando, etc. Seções e edição de cópia moderada ajudariam. Apenas meus 2 centavos.
HoldOffHunger 10/09

@ vcarel - Ah, com certeza. A validação do lado do usuário front-end os informaria quais regras (disponíveis na dica de ferramenta) estavam quebrando. Você está certo - é uma opinião geral. No entanto, a pergunta acima é de alguém que está perguntando ao X uma pergunta Y com certeza. Isso é orientação e funciona ... não apenas funciona, funciona bem. Não deixo endereços de e-mail de merda nos meus sistemas onde tomo as decisões.
BradChesney79

@HoldOffHunger Percebo que a ideia geral não é tão coerente quanto poderia ser, posso revisar em outro dia em que tenho mais tempo para expressar isso melhor. Obrigado pela compreensão.
BradChesney79

-1

No meu PHP eu uso essa verificação

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

tente você mesmo http://phpfiddle.org/main/code/9av6-d10r


-1

Eu criei esse regex de acordo com as diretrizes da RFC:

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

1
Esta versão aprimora o regex, verificando o comprimento do domínio / subdomínios. Aproveitar! ^ [\\ w \\. \\! _ \\% # \\ $ \\ & \\ '= \\? \ * \\ + \\ - \\ / \\ ^ \ `\\ {\\ | \\} \\ ~] + @ (?: [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])? (?: \\. [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])?) *) $
Mau

-2

O Gmail permitirá apenas o sinal de + como caractere especial e, em alguns casos (.), Mas outros caracteres especiais não são permitidos no Gmail. A RFC diz que você pode usar caracteres especiais, mas evite enviar e-mails para o Gmail com caracteres especiais.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.