O glossário de e-mail que todo dev precisa ter nos favoritos

E-mail existe desde os anos 1970 e isso se nota. A terminologia é uma bagunça de siglas, conceitos sobrepostos e specs escritas por comitês. Se você já ficou olhando pra uma mensagem de bounce se perguntando o que "550 5.7.1" significa, ou googlou "SPF vs DKIM" pela terceira vez no ano, essa página é pra você.

Isso é uma referência. Salve nos favoritos. Volte quando precisar.

Autenticação

SPF (Sender Policy Framework)

Um registro DNS TXT que lista quais endereços IP e servidores podem enviar e-mail em nome do seu domínio. Quando um servidor receptor recebe uma mensagem alegando ser de seudominio.com, ele checa o registro SPF pra ver se o servidor de envio está autorizado.

O registro fica no seu domínio raiz e se parece com isso:

v=spf1 include:sendkit.dev include:_spf.google.com ~all

Cada diretiva include: autoriza os servidores de e-mail de um serviço. O ~all no final significa "soft-fail pra qualquer coisa não listada" (trate como suspeito mas não rejeite). Use -all pra hard fail quando estiver confiante que tudo está configurado.

SPF tem um limite rígido de 10 lookups de DNS. Ultrapassou e o registro inteiro vira inválido. Isso pega times de surpresa quando usam múltiplas ferramentas SaaS que cada uma adiciona suas próprias diretivas include:.

Relacionado: Como configurar SPF, DKIM e DMARC

DKIM (DomainKeys Identified Mail)

Um mecanismo de assinatura criptográfica. Seu servidor de envio assina cada e-mail enviado com uma chave privada. O servidor receptor busca a chave pública correspondente no seu DNS (publicada como um registro TXT em selector._domainkey.seudominio.com) e verifica a assinatura.

Se a assinatura bate, duas coisas são confirmadas: a mensagem veio da sua infraestrutura, e não foi modificada em trânsito.

Chaves DKIM deveriam ser de 2048 bits no mínimo. Algumas configurações mais antigas ainda usam chaves de 1024 bits, mas os receptores começam a sinalizá-las como fracas.

Quando você adiciona um domínio na Sendkit, as chaves DKIM são geradas automaticamente e hospedadas via registros CNAME. Isso permite que a Sendkit rotacione chaves em uma programação sem você tocar no DNS.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

A camada de política que amarra SPF e DKIM. Um registro DMARC diz aos servidores receptores o que fazer quando a autenticação falha, e pra onde enviar relatórios sobre os resultados de autenticação.

v=DMARC1; p=none; rua=mailto:[email protected]

O parâmetro p= define a política:

• p=none -- só monitora, nenhuma ação em falhas. Comece aqui.
• p=quarantine -- manda mensagens que falham pro spam.
• p=reject -- rejeita mensagens que falham de vez. Esse é o objetivo.

O parâmetro rua= diz aos receptores pra onde enviar relatórios agregados (arquivos XML mostrando o que passou e falhou). Esses relatórios são a única forma de saber se sua autenticação está funcionando antes de apertar a política.

DMARC também checa alinhamento: o domínio no header From: precisa bater com o domínio que passou em SPF ou DKIM. Essa é a parte que a maioria das pessoas perde. Uma mensagem pode passar no SPF mas ainda falhar no DMARC se os domínios não alinham.

BIMI (Brand Indicators for Message Identification)

Um registro DNS que permite você exibir o logo da sua marca ao lado dos seus e-mails em caixas de entrada compatíveis. Gmail, Apple Mail e Yahoo suportam. BIMI exige uma política DMARC válida de p=quarantine ou p=reject e um Verified Mark Certificate (VMC) de uma autoridade certificadora.

Não melhora a entregabilidade diretamente, mas aumenta a confiança e o reconhecimento na caixa de entrada.

ARC (Authenticated Received Chain)

Um protocolo que preserva resultados de autenticação quando mensagens são encaminhadas. Listas de e-mail e serviços de forwarding quebram SPF e às vezes DKIM. ARC adiciona headers a cada hop pra que o servidor receptor final possa rastrear a cadeia de autenticação de volta até o remetente original.

Se você roda um serviço de forwarding, adicionar headers ARC evita que suas mensagens encaminhadas falhem no DMARC no destino.

Registros DNS

Registro MX (Mail Exchange)

Diz ao mundo quais servidores aceitam e-mail pro seu domínio. Quando alguém envia uma mensagem pra [email protected], o servidor de e-mail deles consulta o DNS por registros MX pra achar onde entregar.

Registros MX têm um valor de prioridade. Números mais baixos significam prioridade mais alta. Se o servidor primário está fora, o remetente tenta o próximo.

seudominio.com.  MX  10  mx1.sendkit.dev.
seudominio.com.  MX  20  mx2.sendkit.dev.

Sem registros MX ninguém consegue receber e-mail no seu domínio. Isso também é o que a validação de e-mail checa -- se um domínio não tem registros MX, qualquer endereço nesse domínio é inentregável.

Registro TXT

Um tipo genérico de registro DNS que armazena dados de texto. Registros SPF, DKIM e DMARC são todos armazenados como registros TXT. O servidor receptor sabe qual é qual pelo prefixo (v=spf1, v=DKIM1, v=DMARC1).

Você só pode ter um registro TXT SPF por domínio. Dois registros SPF no mesmo domínio tornam os dois inválidos.

Registro PTR (Pointer)

O reverso de um registro A. Em vez de mapear um domínio pra um endereço IP, um registro PTR mapeia um endereço IP de volta pra um domínio. Servidores de e-mail usam lookups reversos de DNS pra verificar que um IP de envio tem um registro PTR válido batendo com o domínio de envio.

Registros PTR ausentes ou incompatíveis são bandeira vermelha pra filtros de spam. Se você está enviando de um IP dedicado, garanta que o registro PTR está configurado.

Registro A

Mapeia um nome de domínio pra um endereço IPv4. Embora não seja específico de e-mail, o registro A do seu domínio importa porque alguns servidores de e-mail recorrem a ele quando não existem registros MX. Um registro AAAA é a mesma coisa pra IPv6.

Registro CNAME

Um alias que aponta um domínio pra outro. A Sendkit usa registros CNAME pra DKIM pra você não ter que colar chaves públicas brutas em registros TXT. O CNAME aponta seu sendkit._domainkey.seudominio.com pro DNS da Sendkit, onde a chave em si é hospedada e rotacionada automaticamente.

Entregabilidade

Reputação do remetente

Um score de confiança que provedores de e-mail (Gmail, Outlook, Yahoo) atribuem ao seu domínio de envio e endereço IP. É baseado em taxas de bounce, reclamações de spam, métricas de engajamento e se você atinge spam traps.

Alta reputação significa que seus e-mails alcançam a caixa de entrada. Baixa reputação significa pasta de spam ou rejeição direta. Uma vez danificada, reputação leva semanas pra reconstruir.

Taxa de bounce

A porcentagem de e-mails enviados que falharam na entrega. Existem dois tipos:

• Hard bounce -- falha permanente. O endereço não existe, o domínio é inválido, ou o servidor rejeitou permanentemente a mensagem. Hard bounces prejudicam mais a reputação do remetente.
• Soft bounce -- falha temporária. A caixa do destinatário está cheia, o servidor caiu, ou a mensagem é muito grande. Soft bounces geralmente se resolvem na nova tentativa.

Mantenha sua taxa de bounce abaixo de 2%. Qualquer coisa acima de 5% e você está em apuros com a maioria dos provedores.

Spam trap

Um endereço de e-mail projetado especificamente pra pegar remetentes com higiene de lista ruim. Existem dois tipos:

• Pristine traps -- endereços que nunca foram usados por uma pessoa real. Existem só pra pegar scrapers e compradores de listas de e-mail.
• Recycled traps -- endereços antigos que foram abandonados, depois reutilizados pelo provedor como traps. Acertar esses significa que você não está limpando sua lista.

Enviar pra spam traps afunda sua reputação rápido. A única defesa é validação de e-mail adequada e limpeza regular de lista.

IP warming

O processo de aumentar gradualmente o volume de e-mail de um novo endereço IP ou domínio. ISPs são suspeitas de novos remetentes disparando volume alto no dia um. Warm-up constrói confiança mostrando comportamento consistente e de baixa reclamação ao longo de semanas.

Uma programação típica de warm-up começa com algumas centenas de e-mails por dia e dobra a cada poucos dias até chegar no seu volume alvo. Pule isso e você provavelmente vai ser limitado ou bloqueado.

Lista de supressão

Uma lista de endereços de e-mail pra onde você nunca deve enviar. Isso inclui endereços que deram hard bounce, apresentaram reclamações de spam ou se descadastraram. A Sendkit gerencia listas de supressão automaticamente -- bounces e reclamações são suprimidos sem você escrever código.

Ignorar supressão é uma das formas mais rápidas de destruir entregabilidade.

Feedback loop (FBL)

Um mecanismo onde ISPs notificam remetentes quando destinatários marcam o e-mail deles como spam. Quando um usuário clica em "Denunciar spam" no Gmail ou Outlook, a ISP envia um relatório de volta pro remetente (se ele está registrado no FBL).

Você deve processar esses relatórios e imediatamente suprimir o endereço que reclamou. Continuar a enviar pra pessoas que reclamaram é forma garantida de danificar sua reputação.

SMTP e protocolo

SMTP (Simple Mail Transfer Protocol)

O protocolo usado pra enviar e-mail entre servidores. Existe desde 1982 (RFC 821, atualizado pela RFC 5321). SMTP usa uma série de comandos de texto (HELO, MAIL FROM, RCPT TO, DATA) pra transferir mensagens.

SMTP moderno usa criptografia TLS. Porta 587 com STARTTLS é o padrão pra submissão. Porta 465 usa TLS implícito. Porta 25 é pra relay servidor-a-servidor e geralmente é bloqueada por ISPs pra conexões de consumidor.

O SMTP relay da Sendkit aceita conexões nas portas 587 e 465 e funciona como substituto drop-in pra qualquer provedor SMTP.

Envelope sender (Return-Path)

O endereço de e-mail usado durante o handshake SMTP (o comando MAIL FROM). Isso é diferente do header From: que o destinatário vê. Notificações de bounce vão pro endereço do envelope sender, por isso também é chamado de return-path ou endereço de bounce.

A distinção importa pro alinhamento DMARC. SPF checa o domínio do envelope sender, não o domínio do header From:.

Handshake SMTP

A conversa vai-e-vem entre dois servidores de e-mail ao entregar uma mensagem:

1. EHLO/HELO -- o servidor de envio se identifica.
2. MAIL FROM -- especifica o envelope sender.
3. RCPT TO -- especifica o destinatário.
4. DATA -- o conteúdo real da mensagem (headers + corpo).
5. QUIT -- fecha a conexão.

Serviços de validação de e-mail fazem um handshake parcial (até RCPT TO) pra checar se uma caixa existe sem de fato enviar uma mensagem.

TLS (Transport Layer Security)

Criptografia pra dados em trânsito. Quando dois servidores de e-mail se comunicam por TLS, o conteúdo da mensagem é criptografado entre eles. Isso não significa que a mensagem é criptografada ponta-a-ponta (os servidores em si ainda podem lê-la), mas impede escuta na rede.

STARTTLS atualiza uma conexão existente em texto puro pra criptografada. TLS implícito (porta 465) começa criptografado desde o início.

MIME (Multipurpose Internet Mail Extensions)

O padrão que permite e-mail carregar mais do que texto simples. MIME define como codificar anexos, conteúdo HTML, imagens inline e conjuntos de caracteres. Quando você envia um e-mail com ambas versões HTML e texto simples, MIME lida com a estrutura multipart.

Anatomia da mensagem

Header From

O endereço de e-mail exibido ao destinatário. É o que as pessoas veem na caixa de entrada. É definido pelo remetente e tecnicamente pode ser qualquer coisa, que é exatamente por que SPF, DKIM e DMARC existem -- pra verificar que é legítimo.

Header Reply-To

Um header opcional que diz aos clientes de e-mail pra onde enviar respostas. Se não definido, respostas vão pro endereço From:. Útil quando você envia de [email protected] mas quer que respostas vão pra [email protected].

Message-ID

Um identificador único atribuído a cada e-mail. Se parece com <[email protected]>. Message-IDs são usados pra threading de conversas e pra rastrear status de entrega entre sistemas.

Headers de e-mail

Metadados anexados a cada mensagem de e-mail. Headers incluem informação de roteamento (Received), resultados de autenticação (Authentication-Results), tipo de conteúdo (Content-Type) e mais. Ao debugar problemas de entregabilidade, os headers brutos são o primeiro lugar pra olhar.

A maioria dos clientes de e-mail te deixa ver headers brutos. Procure por Authentication-Results pra checar o status de SPF, DKIM e DMARC.

Conceitos de envio

E-mail transacional

Mensagens disparadas por uma ação do usuário: resets de senha, confirmações de pedido, códigos de login, recibos de fatura. São esperadas pelo destinatário e tipicamente têm altas taxas de abertura. Precisam chegar rápido e de forma confiável.

A email API da Sendkit é feita pra e-mail transacional -- envie via REST API ou SMTP com entrega rastreada através de webhooks.

E-mail de marketing (e-mail em massa)

Mensagens enviadas pra uma lista de assinantes: newsletters, promoções, anúncios de produto. Diferente do e-mail transacional, os destinatários não pediram explicitamente cada mensagem individual. E-mail de marketing exige consentimento adequado (opt-in) e deve incluir um link de descadastro.

Webhook

Um callback HTTP que notifica sua aplicação quando algo acontece. No contexto de e-mail, webhooks te dizem quando uma mensagem é entregue, aberta, clicada, dá bounce ou é marcada como spam. Em vez de consultar uma API por status, o provedor de e-mail empurra eventos pro seu endpoint em tempo real.

Validação de e-mail

O processo de checar se um endereço de e-mail é entregável antes de enviar pra ele. Uma stack de validação adequada inclui checagens de sintaxe, lookups DNS/MX, detecção de e-mail descartável e verificação de caixa SMTP.

A API de validação de e-mail da Sendkit roda todas essas checagens em uma única requisição. Validar no ponto de coleta evita que endereços ruins entrem no seu banco.

Relacionado: Como validar endereços de e-mail antes de enviar

IP dedicado vs IP compartilhado

Um IP compartilhado é usado por múltiplos remetentes no mesmo provedor de e-mail. Sua reputação é parcialmente influenciada pelo comportamento de outros remetentes nesse IP. Bom pra remetentes de baixo volume.

Um IP dedicado é atribuído exclusivamente a você. Sua reputação é inteiramente sua. Melhor pra remetentes de alto volume (100K+ e-mails/mês) que mantêm listas limpas. Exige warm-up de IP antes do uso.

Conformidade

CAN-SPAM

Lei dos EUA que governa e-mail comercial. Requisitos: incluir seu endereço físico, fornecer um mecanismo claro de descadastro, honrar pedidos de opt-out em 10 dias úteis, não usar assuntos enganosos. Aplica-se a e-mail de marketing, não transacional.

GDPR (General Data Protection Regulation)

Regulação da UE que governa como dados pessoais (incluindo endereços de e-mail) são coletados, armazenados e processados. Exige consentimento explícito pra e-mail de marketing, o direito ao esquecimento e portabilidade de dados. Violações carregam multas de até 4% da receita global.

LGPD (Lei Geral de Proteção de Dados)

Lei brasileira de proteção de dados, similar ao GDPR. Exige uma base legal pra processar dados pessoais, consentimento pra comunicações de marketing, e dá aos indivíduos o direito de acessar e deletar seus dados.

Opt-in / double opt-in

Single opt-in significa que um usuário fornece o endereço de e-mail e é imediatamente adicionado à sua lista. Double opt-in (opt-in confirmado) envia um e-mail de confirmação primeiro -- o usuário precisa clicar num link pra verificar o endereço antes de ser adicionado.

Double opt-in produz listas mais limpas e protege contra typos e cadastros falsos. É exigido por lei em algumas jurisdições (Alemanha, por exemplo) e fortemente recomendado em todos os outros lugares.

Códigos de status comuns

Quando um e-mail falha na entrega, a mensagem de bounce inclui um código de status SMTP. Aqui estão os que você vai ver mais:

• 250 -- sucesso. A mensagem foi aceita.
• 421 -- serviço indisponível. Tente mais tarde (temporário).
• 450 -- caixa indisponível. Geralmente temporário (caixa cheia, servidor ocupado).
• 451 -- erro local no processamento. Tente mais tarde.
• 452 -- armazenamento insuficiente. O servidor ficou sem espaço.
• 550 -- caixa não encontrada. O endereço não existe (hard bounce).
• 551 -- usuário não é local. O servidor não lida com e-mail pra esse endereço.
• 552 -- mensagem muito grande. Reduza o tamanho do anexo ou conteúdo.
• 553 -- nome da caixa não permitido. Geralmente um problema de sintaxe.
• 554 -- transação falhou. Rejeição genérica, frequentemente relacionada a spam.

O código de três dígitos às vezes é seguido por um código de status estendido como 5.7.1 (entrega não autorizada) que dá contexto mais específico.

Fechando

A terminologia de e-mail está espalhada por décadas de RFCs, documentação de provedor e conhecimento tribal. Esse glossário cobre os termos que você vai efetivamente encontrar ao configurar infraestrutura de e-mail, debugar entregabilidade ou construir aplicações que enviam e-mail.

Se algo está faltando, provavelmente merece o próprio artigo. Confira o blog da Sendkit pra análises profundas em tópicos específicos, ou a documentação pra detalhes de implementação.