Análise aprofundada de endereços de e-mail

• O endereço de e-mail não é apenas uma combinação simples de nome de usuário e domínio, mas um sistema que inclui estrutura complexa, regras definidas nos padrões RFC e armadilhas de segurança
• Na parte local (antes do @), existem vários formatos válidos pouco conhecidos, como forma entre aspas, comentários e Unicode, mas a maioria não é suportada em ambientes reais
• Todo e-mail possui dois endereços de remetente: o Envelope Sender e o cabeçalho From, e essa diferença é a causa fundamental de spoofing e phishing
• O comportamento específico de cada provedor, como a política do Gmail de ignorar pontos (dot), endereçamento com plus e aliases de domínio, afeta diretamente segurança e validação
• Ao construir sistemas para coletar ou validar endereços de e-mail, é essencial entender com precisão a lacuna entre o padrão RFC e o comportamento real

---

Estrutura básica

• Um endereço de e-mail é composto por três partes: parte local (antes do @), separador @ e domínio (depois do @)
• Embora pareça simples à primeira vista, cada parte tem regras e casos de borda que afetam segurança, privacidade e validação

Parte local (Local Part)

• Caracteres permitidos

  • Caracteres permitidos no formato padrão sem aspas (dot-atom): letras a-z, A-Z, números 0-9, caracteres especiais . _ - + ! # $ % & ' * / = ? ^ { | } ~
  • O comprimento máximo é de 64 octetos (octet); em ASCII padrão isso equivale a 64 caracteres, mas há diferença em partes locais com Unicode
    • Octeto significa exatamente um grupo de 8 bits e é usado em redes (IPv4) para representar valores no intervalo de 0 a 255
    • 64 octetos correspondem a um bloco de dados de 512 bits

• Sensibilidade a maiúsculas e minúsculas

  • Segundo a RFC 5321, a parte local tecnicamente diferencia maiúsculas de minúsculas, e [e-mail] e [e-mail] podem ser caixas postais diferentes
  • Na prática, todos os principais provedores de e-mail não fazem essa distinção, então normalizar para minúsculas antes de armazenar ou comparar é o padrão mais seguro
  • A parte do domínio nunca diferencia maiúsculas de minúsculas

• Endereçamento com ponto (Dot)

  • Pontos são permitidos na parte local, mas existem três restrições: não pode começar com ponto, não pode terminar com ponto e não pode haver pontos consecutivos
  • Normalização de pontos do Gmail: o Gmail ignora completamente os pontos na parte local, então [e-mail], [e-mail] e [e-mail] são todos entregues na mesma caixa de entrada
    • Isso não é padrão RFC, mas um comportamento específico do Gmail
    • É um vetor real de ataque que pode ser explorado por atacantes para criar contas separadas com variações de ponto e contornar limites de conta única ou obter testes grátis duplicados

• Subendereçamento (endereçamento com plus)

  • É possível adicionar uma tag à parte local usando um separador, e o servidor de e-mail entrega para o endereço base mantendo a tag (padrão RFC 5233)
  • O separador mais comum é +, com suporte em Gmail, Outlook, ProtonMail, Fastmail etc.
    • Em algumas configurações do Yahoo e em certas configurações do Postfix, usa-se -
    • No qmail, = é o separador padrão, e é por isso que o VERP codifica @ como =
  • Principais casos de uso:
    • Rastreamento de vazamento: cadastrar-se com uma tag única por serviço (ex.: [e-mail]) para identificar a origem do vazamento ao receber spam
    • Filtragem da caixa de entrada: classificar automaticamente mensagens enviadas para endereços com tags específicas usando regras de e-mail
    • Múltiplas contas: em serviços que não normalizam o plus, é possível criar contas separadas com um único e-mail
  • Muitos validadores de e-mail em sites rejeitam +, mas isso é um bug no código de validação, não uma limitação do e-mail

• Formato de string entre aspas (Quoted String Form)

  • Se a parte local for envolvida por aspas duplas, a maioria das restrições de caracteres é relaxada, permitindo espaços, @, pontos consecutivos e pontos no início ou no fim
  • Ex.: "john doe"@example.com, "user@name"@example.com, " "@example.com
  • Na prática, quase todos os provedores de e-mail não aceitam partes locais entre aspas, então embora válido pela RFC, isso é inútil no uso real

• Comentários (Comments)

  • Comentários entre parênteses podem aparecer no início ou no fim da parte local, e o servidor de e-mail os remove sem afetar a entrega
  • Tecnicamente é válido segundo a RFC 5322, mas não é usado na era moderna
  • Validadores que rejeitam parênteses são mais restritivos do que a RFC

• Parte local em Unicode (EAI)

  • A internacionalização de endereços de e-mail (EAI), definida nas RFC 6530, 6531 e 6532, permite caracteres UTF-8 na parte local
  • É necessário usar a extensão SMTPUTF8 na sessão SMTP, e tanto o servidor de envio quanto o de recebimento precisam oferecer suporte
  • Em 2026, a adoção ainda é limitada, e como caracteres Unicode usam de 2 a 4 octetos, é possível atingir o limite de 64 octetos com menos caracteres visuais

• Formatos históricos

  • Bang path (UUCP): método de roteamento usado antes do DNS em redes de máquinas Unix conectadas por modem, com caminho de nomes de host separados por ! (machine1!machine2!user), motivo pelo qual ! está na lista de caracteres permitidos. Hoje está completamente obsoleto
  • Percent hack: truque de roteamento por relay no formato [e-mail]; o caractere % continua válido na parte local mesmo após o mecanismo de roteamento ter sido descontinuado na RFC 5321
  • Source routing: lista explícita de saltos de relay no comando SMTP RCPT TO (@relay1,@relay2:user@domain). Obsoleto na RFC 5321

• VERP (Variable Envelope Return Path)

  • Técnica usada em sistemas de e-mail em massa para rastrear o destinatário exato que gerou um bounce
  • Codifica o endereço do destinatário no remetente do envelope (MAIL FROM), substituindo o @ do endereço do destinatário por =
    • Ex.: bounces+alice=[e-mail]
  • Mailchimp, SendGrid e Amazon SES usam VERP ou variações para processamento de bounces em grande escala

• SRS (Sender Rewriting Scheme)

  • Formato de endereço que aparece quando um servidor encaminha um e-mail e reescreve o remetente do envelope para passar na verificação SPF
  • No formato SRS0=HASH=TT=originaldomain.com=[e-mail]
  • Em encaminhamento com múltiplos saltos, assume a forma SRS1=HASH=[e-mail]
  • É um endereço estruturalmente válido, mas um artefato de infraestrutura, não um endereço usado por pessoas
  • O componente HASH é um HMAC do timestamp e do endereço original, servindo para evitar falsificação e limitar o período de validade do token

Parte do domínio (Domain Part)

• Regras dos rótulos

  • O domínio é composto por rótulos separados por pontos, e cada rótulo permite letras a-z, números 0-9 e hífen -
  • Não pode começar nem terminar com hífen, e não pode haver hífens consecutivos na 3ª e 4ª posições (exceto rótulos Punycode que começam com xn--)
  • Cada rótulo pode ter no máximo 63 caracteres, o domínio inteiro no máximo 253 caracteres, e o endereço de e-mail completo (addr-spec) no máximo 254 caracteres

• Subdomínios

  • Um domínio pode ter vários níveis e, além do limite total de 253 caracteres, não há um limite rígido para a profundidade dos subdomínios
  • Uso comum: infraestrutura de e-mail (mail., smtp., mx.), separação organizacional (sales.company.com), envio por ESP (email.company.com)

• Literais de endereço IP

  • Em vez de um nome de domínio, é possível usar um endereço IP entre colchetes: user@[192.168.1.1], user@[IPv6:2001:db8::1]
  • É válido segundo a RFC 5321, mas quase nunca é aceito por servidores de e-mail públicos, sendo usado em sistemas de e-mail internos e testes de SMTP

• Domínios de rótulo único

  • Domínios sem ponto (por exemplo, user@localhost) são tecnicamente válidos em alguns contextos, mas servidores de e-mail públicos os rejeitam
  • postmaster@localhost é um caso especial convencional de e-mail local do sistema em sistemas do tipo Unix

• Nomes de domínio internacionalizados (IDN) e Punycode

  • Como o DNS aceita apenas ASCII, caracteres não ASCII são codificados em Punycode (RFC 3492), e todos os rótulos codificados começam com o prefixo xn--
  • Clientes de e-mail exibem o domínio na escrita nativa, e o SMTP o transmite na forma Punycode
  • Ataques de homógrafos: é possível registrar domínios parecidos com domínios conhecidos usando caracteres visualmente idênticos de outros scripts Unicode. Os navegadores têm defesas que exibem Punycode para IDNs suspeitos, mas a maioria dos clientes de e-mail não tem esse tipo de proteção, tornando o ataque mais eficaz no e-mail

• Ponto final (Trailing Dot)

  • No DNS, todo domínio tecnicamente termina com um ponto final que representa a zona raiz, mas em e-mail isso é sempre implícito e omitido
  • A maioria dos validadores rejeita o formato [e-mail].

• Registros MX

  • O domínio de um endereço de e-mail não precisa ser necessariamente o local do servidor de e-mail; o servidor remetente consulta os registros DNS MX (Mail Exchanger) para descobrir o hostname real do servidor de e-mail
  • Um número de prioridade menor significa prioridade maior, e se não houver nenhum registro MX, há fallback para o registro A do domínio
  • Se um domínio nunca deve receber e-mail, pode publicar um registro MX nulo (MX 0 .) para informar explicitamente aos servidores remetentes que não tentem a entrega (RFC 7505)

Domínio de topo (TLD)

• Os TLDs genéricos originais

  • Os 7 gTLDs da internet inicial: .com (comercial, hoje sem restrição, operado pela Verisign), .net (rede, sem restrição), .org (organizações, sem restrição), .edu (instituições educacionais credenciadas dos EUA, restrito), .gov (governo dos EUA, restrito), .mil (Forças Armadas dos EUA, restrito), .int (organizações internacionais baseadas em tratados, muito restrito)
  • .arpa é um TLD de infraestrutura administrado pela IANA, usado em consultas DNS reversas

• TLDs de código de país (ccTLD)

  • Códigos de 2 letras baseados nos códigos de país ISO 3166-1 alpha-2, com cerca de 250 existentes
  • Alguns ccTLDs foram reaproveitados por outros setores:
    • .io (Território Britânico do Oceano Índico → empresas de tecnologia), .tv (Tuvalu → mídia e streaming), .ai (Anguila → empresas de IA), .co (Colômbia → alternativa a .com), .me (Montenegro → sites pessoais), .ly (Líbia → encurtadores de URL), .sh (Santa Helena → projetos de software)
  • Ao usar um ccTLD reaproveitado, tecnicamente ele fica sob a jurisdição do registro daquele país, e o domínio é controlado pelo registro do país de origem, não pela ICANN

• TLDs patrocinados (sTLD)

  • TLDs com organização patrocinadora e requisitos de elegibilidade: .aero (transporte aéreo, patrocinado pela SITA), .coop (cooperativas), .museum (museus), .jobs (empregos), .xxx (adulto), .post (correios), .cat (língua e cultura catalãs)

• Novos TLDs genéricos (desde 2012)

  • Em 2012, a ICANN abriu pedidos para novos gTLDs e mais de 1.200 novos TLDs foram delegados
  • Impacto importante na validação de e-mail: validadores que limitam o tamanho do TLD a 4~6 caracteres quebram (.photography, .international, .construction etc.)
  • Relacionados a desenvolvedores: .app, .dev, .web, .code / comércio: .shop, .store, .online / conteúdo: .blog, .news, .media / negócios: .tech, .agency, .cloud
  • Os novos gTLDs são super-representados em spam e phishing devido ao baixo custo de registro e às políticas fracas de abuso de alguns registros

• TLDs de marca

  • Na expansão da ICANN em 2012, grandes empresas solicitaram seus próprios TLDs: .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
  • A maioria não é usada como endereço público de e-mail; serve principalmente para uso interno ou nem é usada

• TLDs geográficos e de cidades

  • TLDs próprios de cidades e regiões: .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
  • No registro, normalmente é preciso comprovar vínculo com a região correspondente

• TLDs internacionalizados

  • Muitos países têm TLDs em scripts não ASCII, codificados em Punycode no DNS
    • .xn--p1ai (Rússia, cirílico), .xn--fiqz9s (China, caracteres simplificados), .xn--mgberp4a5d4ar (Arábia Saudita, escrita árabe), .xn--h2brj9c (Índia, devanágari)

• TLDs reservados e para documentação

  • TLDs reservados pelas RFC 2606 e RFC 6761 para testes e documentação:
    • .test (nunca existe no DNS público, seguro para testes de software), .example (para exemplos em documentação), .invalid (quando é preciso um domínio que com certeza não resolva), .localhost (para loopback)
  • A IANA registrou example.com, example.net e example.org para documentação e exemplos, permitindo seu uso livre em exemplos de código sem risco de atingir uma caixa de e-mail real

• TLDs descontinuados

  • ccTLDs removidos devido ao desaparecimento de países: .yu (Iugoslávia, removido em 2010), .cs (Tchecoslováquia, removido em 1995), .dd (Alemanha Oriental, removido em 1990), .tp (Timor-Leste, substituído por .tl e removido totalmente em 2015)
  • Exceção: .su (União Soviética) ainda tem domínios ativos apesar da dissolução em 1991, e continua ativo embora a IANA discuta a transição há anos

Domínios de segundo nível em ccTLDs

• Muitos ccTLDs adicionam categorias funcionais de segundo nível entre o nome registrável e o TLD
  • Reino Unido: .co.uk, .org.uk, .gov.uk / Austrália: .com.au, .edu.au / Japão: .co.jp, .ac.jp / Índia: .co.in, .gov.in / Brasil: .com.br, .gov.br
• Quando sistemas de verificação de e-mail precisam encontrar o domínio organizacional, isso afeta a validação e a detecção do domínio organizacional

• Public Suffix List (PSL)

  • Lista mantida pela comunidade em publicsuffix.org que registra todos os sufixos de domínio nos quais usuários da internet podem registrar nomes diretamente
  • Inclui tanto delegações oficiais (.co.uk, .com.au) quanto registros privados (github.io, wordpress.com, herokuapp.com)
  • Usa notação curinga, por exemplo *.ck, e exceções são marcadas com !, por exemplo !www.ck
  • Usada por validadores de e-mail e filtros de spam para identificar o domínio organizacional dentro da string completa do domínio
  • Não é um padrão do IETF, mas é o padrão de fato (de facto standard) para esse problema

Formatos de endereço de e-mail

• Endereço básico (Bare Address)

  • Forma addr-spec local@domain, usada em comandos SMTP e em contextos simples

• Formato com colchetes angulares

  • No SMTP, os comandos MAIL FROM e RCPT TO envolvem o endereço entre colchetes angulares: MAIL FROM:<[e-mail]>
  • Os colchetes angulares fazem parte da sintaxe do comando SMTP, não do endereço em si

• Formato de nome de exibição (Display Name Format)

  • Em cabeçalhos de mensagem (From, To, Cc), um nome legível por humanos pode vir antes do endereço entre colchetes angulares: "John Doe" <[e-mail]>
  • Se o nome de exibição contiver caracteres especiais, as aspas são obrigatórias
  • Falsificação de nome de exibição: o remetente pode definir o nome de exibição como quiser, permitindo ataques no formato "PayPal Security <[e-mail]>" <[e-mail]>
    • Como muitos clientes de e-mail mostram apenas o nome de exibição na lista da caixa de entrada, isso é uma das técnicas de phishing mais comuns

• Sintaxe de grupo (Group Syntax)

  • Formato de grupo nomeado para vários destinatários definido na RFC 5322: Marketing Team: [e-mail], "Bob Smith" <[e-mail]>;
  • Padrão de destinatários ocultos: To: undisclosed-recipients:; — sintaxe de grupo vazia, em que os destinatários reais estão no envelope SMTP (RCPT TO) e não aparecem no cabeçalho da mensagem

• Nomes de exibição codificados

  • Em sistemas de e-mail antigos, caracteres não ASCII no nome de exibição eram tratados como palavras codificadas RFC 2047: =?charset?encoding?encoded_text?=
  • A codificação é B (base64) ou Q (quoted-printable)
  • Com suporte moderno a SMTPUTF8, é possível usar UTF-8 diretamente no cabeçalho sem esse wrapper de codificação

Os dois remetentes de todo e-mail

• Remetente do envelope (Envelope Sender / MAIL FROM)

  • Definido no comando SMTP MAIL FROM: e não faz parte do conteúdo da mensagem em si
  • Usado para roteamento de bounces, é o alvo da verificação SPF e é armazenado pelo servidor destinatário final no cabeçalho Return-Path:
  • Também chamado de envelope from, reverse path ou RFC5321.MailFrom

• Cabeçalho From

  • Endereço no cabeçalho From: da mensagem, que é o que o cliente de e-mail mostra como remetente
  • É o que o DMARC protege em conjunto com o alinhamento SPF ou DKIM
  • Pode ser definido livremente pelo remetente e, na maioria dos servidores de e-mail, não há validação inerente
  • Esses dois endereços podem ser totalmente diferentes, e isso é um cenário normal e esperado:
    • Em disparos em massa via ESP, o MAIL FROM pode ser [e-mail] e o cabeçalho From pode ser [e-mail]
    • Em listas de e-mail, o MAIL FROM pode ser o endereço de bounce da lista, e o cabeçalho From, o autor original
    • No encaminhamento de e-mail, o servidor de encaminhamento pode reescrever o MAIL FROM com SRS, mantendo o cabeçalho From com o remetente original
  • Se o domínio não aplicar DMARC, qualquer pessoa pode enviar usando um MAIL FROM totalmente sem relação enquanto coloca esse domínio no cabeçalho From

• Cabeçalho Sender

  • Identifica o remetente real quando o autor efetivo da submissão da mensagem é diferente do endereço From: Sender: [e-mail]

• Cabeçalho Reply-To

  • Especifica para onde as respostas devem ir e pode ser diferente do endereço From
  • Também pode ser explorado como vetor de phishing: o invasor faz o From parecer legítimo e define o Reply-To para o próprio endereço

• Remetente nulo

  • MAIL FROM:<> é uma estrutura SMTP válida e importante: o remetente de envelope vazio é usado para mensagens de bounce, respostas automáticas e mensagens que não devem gerar bounces por si mesmas
  • Evita loops infinitos de bounce, nos quais dois sistemas continuam trocando notificações de falha

Endereços baseados em função (Role-Based Addresses)

• Obrigatório pela RFC 5321

  • postmaster@domain: em qualquer domínio que aceite e-mail, a aceitação de mensagens para esse endereço é obrigatória segundo a RFC 5321, sem exceções

• Recomendado pela RFC 2142

  • abuse@domain (denúncias de spam e abuso), hostmaster@domain (administração da zona DNS), security@domain (divulgação de vulnerabilidades e relatórios de segurança), webmaster@domain (problemas no servidor web), noc@domain (operações de rede)

• Endereços de função convencionais

  • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@ etc. não são padrões oficiais, mas são amplamente usados
  • Endereços de função normalmente são compartilhados por várias pessoas, portanto, ao enviar informações sensíveis, vários membros da equipe podem ter acesso
  • abuse@ e postmaster@ recebem e-mails de reclamação, por isso são alvos de engenharia social

• Endereços catch-all

  • Não são um formato específico de endereço de e-mail, mas uma configuração do servidor de e-mail que aceita entrega mesmo para partes locais sem uma caixa postal específica
  • Casos de uso: capturar erros de digitação, testes de desenvolvedores, criação de endereços únicos por serviço sem um sistema formal de aliases
  • Desvantagens: como qualquer parte local é entregue, há grande volume de spam, e a validação de existência de endereços por probing SMTP se torna impossível (todas as sondagens recebem resposta de sucesso)

Comportamentos específicos por provedor

• Gmail

  • Normalização de pontos: ignora todos os pontos na parte local
  • Endereçamento com plus: suporta o delimitador +
  • @googlemail.com: apelido histórico de @gmail.com devido a uma disputa de marca na Alemanha e no Reino Unido; ambos os domínios entregam na mesma caixa de entrada
  • Restrições de caracteres: permite apenas letras, números e pontos na parte local (incluindo + para endereçamento com plus). Não oferece suporte ao conjunto completo de caracteres do RFC
  • Limite de comprimento da parte local: 30 caracteres, muito abaixo do máximo de 64 do RFC

• Microsoft (Outlook, Hotmail, Live)

  • Sem normalização de pontos: [e-mail] e [e-mail] são caixas de correio separadas
  • Apelidos de domínio: @hotmail.com, @live.com e @outlook.com podem apontar para a mesma conta ao configurar aliases
  • Suporte a endereçamento com plus

• Apple (iCloud)

  • Apelidos de domínio: @icloud.com, @me.com e @mac.com entregam na mesma caixa de entrada (histórico de mudança de nome do serviço de .mac → .me → .icloud)
  • Suporte a endereçamento com plus
  • Hide My Email: gera aliases aleatórios no formato [e-mail], mantendo o endereço real oculto com um alias exclusivo para cada serviço ou app

• ProtonMail / Proton

  • Apelidos de domínio: @proton.me, @protonmail.com e @pm.me entregam na mesma caixa de entrada
  • Suporte a endereçamento com plus

• Serviços de alias de e-mail

  • Separados do e-mail descartável, são serviços que criam endereços de encaminhamento permanentes e controláveis:
    • SimpleLogin (da Proton): encaminha aliases personalizados ou aleatórios para qualquer caixa de entrada
    • Addy.io (antigo AnonAddy): semelhante ao SimpleLogin, com possibilidade de self-hosting
    • Firefox Relay (Mozilla): aliases aleatórios limitados no plano gratuito
    • DuckDuckGo Email Protection: aliases @duck.com
  • Para o remetente, geram endereços estruturalmente indistinguíveis de uma caixa de entrada real
  • Diferença principal em relação ao e-mail descartável: aliases são permanentes e controláveis, podendo ser desativados por alias específico, usados para verificar qual serviço enviou a mensagem e encaminhados para a caixa de entrada desejada

E-mail descartável e temporário

• Oferecem caixas de entrada sem necessidade de cadastro e que normalmente expiram após pouco tempo; exemplos conhecidos incluem Mailinator, Guerrilla Mail, 10 Minute Mail e TempMail
• A maioria usa roteamento catch-all, então qualquer parte local daquele domínio é entregue a uma caixa de entrada
• Muitas caixas de entrada são públicas, então qualquer pessoa que conheça o endereço pode ler as mensagens
• Existem listas de bloqueio de domínios descartáveis conhecidos (o repositório GitHub disposable-email-domains é o mais referenciado), mas elas são sempre incompletas, e os serviços trocam continuamente para novos domínios para contornar o bloqueio

Validação

• Validade técnica vs. validade prática

  • Válidos pelo RFC, mas quase nunca aceitos por servidores reais: espaço entre aspas (" "@example.com), @ entre aspas ("user@name"@example.com), domínio literal com IP (user@[192.168.1.1]), caractere único/rótulo único (a@b)
  • Válidos pelo RFC e também aceitos na prática: [e-mail], [e-mail], [e-mail], [e-mail]
  • Para a maioria das aplicações, um validador prático é melhor do que um validador totalmente compatível com o RFC: verificar a estrutura básica, validar um conjunto razoável de caracteres e, opcionalmente, consultar o DNS MX do domínio

• Bugs comuns em validadores

  • Rejeitar + na parte local: [e-mail] é totalmente válido, e esse é um bug muito comum
  • Rejeitar _ na parte local: também é válido
  • Rejeitar % na parte local: é um caractere válido; o que foi descontinuado foi apenas o uso de roteamento com percent hack
  • Limitar o comprimento do TLD a 4~6 caracteres: bloqueia centenas de novos gTLDs como .photography, .international e .construction
  • Validar com uma lista de TLDs codificada manualmente: como a lista muda continuamente, o validador envelhece
  • Limite total de comprimento incorreto: usar 255 ou 256 em vez de 254. A errata nº 1690 da RFC 3696 corrigiu para 254 o valor 320, amplamente citado de forma incorreta
  • Rejeitar letras maiúsculas na parte local: válido segundo o RFC
  • Rejeitar [e-mail]: é válido; domínios com múltiplos pontos em padrões ccTLD de segundo nível são normais
  • Rejeitar .dev, .app, .io como TLD: todos são TLDs válidos e delegados

• Limites de comprimento

  Parte	Limite
  Parte local	64 octetos
  Rótulo de domínio	63 octetos
  Domínio completo	253 octetos
  Endereço completo (addr-spec)	254 octetos

• Como o limite da parte local é em octetos, não em caracteres, endereços EAI com caracteres Unicode multibyte podem aparentar ter menos de 64 caracteres e ainda assim atingir o limite em octetos

• Validação baseada em DNS

  • Verificação de registro MX: valida se o domínio tem registro MX; é rápida e de baixo risco. Domínios que usam fallback para registro A (sem MX configurado) podem falhar nesse teste
  • Verificação de Null MX: se o domínio tiver MX 0 ., ele explicitamente não recebe e-mail
  • Probing com SMTP RCPT TO: conecta ao servidor de e-mail e envia o comando RCPT TO para verificar se o endereço é aceito, mas muitos servidores respondem 250 para todos os endereços para evitar coleta de endereços, então não é confiável. Domínios catch-all sempre respondem positivamente. Também há risco de o IP de sondagem entrar em blacklist
  • A única forma de validar um endereço de e-mail com total confiabilidade é enviar uma mensagem real e confirmar a entrega; todo o resto é heurística

Implicações de segurança

• Falsificação do nome de exibição

  • Qualquer pessoa pode definir o nome de exibição de um e-mail como quiser e, em visualizações de caixa de entrada que mostram apenas esse nome, o usuário não consegue distinguir um remetente legítimo de uma personificação sem verificar explicitamente o endereço real

• Ataques homográficos com Punycode

  • É possível registrar domínios visualmente idênticos a domínios reais e conhecidos usando caracteres de outros conjuntos Unicode
  • Diferentemente dos navegadores, clientes de e-mail em geral não exibem alertas sobre isso

• Bypass de contas com o truque dos pontos do Gmail

  • Como o Gmail ignora pontos, um invasor pode cadastrar variações pontuadas de um endereço Gmail existente em um serviço para burlar limites de uma conta por usuário, obter testes grátis duplicados e receber e-mails destinados ao dono da conta original

• Reutilização de endereços de e-mail

  • Provedores podem reatribuir endereços abandonados a novos usuários, e o novo dono da conta pode receber e-mails de recuperação de serviços cadastrados pelo antigo titular, permitindo tomada de conta por redefinição de senha
  • O Gmail afirma não reatribuir endereços, mas alguns outros provedores historicamente já fizeram isso

• Exposição de tags de subendereçamento

  • Ao se cadastrar com [e-mail], o serviço receptor consegue ver o endereço completo, incluindo a tag
  • Serviços que removem e armazenam sem a tag plus expõem o endereço base; serviços que armazenam o endereço completo como está podem revelar a estratégia de rastreamento nas configurações da conta ou em exportações de dados