O cliente pagou. O pedido existe. O aplicativo mostra “E-mail de confirmação enviado”. Cinco minutos depois, chega uma mensagem ao suporte: “Não recebi nada.” As duas telas podem estar dizendo a verdade. Elas apenas descrevem partes diferentes do caminho.
O Dia Mundial dos Correios, em 9 de outubro, marca a criação da União Postal Universal em 1874. É um bom pretexto para recuperar uma distinção postal: entregar uma carta ao transportador não é o mesmo que ver alguém lê-la. O e-mail também tem passagens de responsabilidade, e o sinal verde costuma dizer menos do que gostaríamos. Nações Unidas: Dia Mundial dos Correios.
Do envio à leitura: estados diferentes
Comece dentro do próprio produto. “Criado” pode significar que o evento de negócio ficou registrado. “Em fila” pode significar que existe uma tarefa em segundo plano. Nenhum dos dois prova que o serviço de envio aceitou a mensagem. Quando o aplicativo junta estes estados, o diagnóstico começa com uma testemunha pouco confiável: a própria interface.
Um servidor SMTP que aceita a mensagem após DATA com uma resposta 250 assume a responsabilidade de a entregar ou retransmitir. É uma passagem de responsabilidade no protocolo, não uma prova de chegada à caixa de entrada ou de leitura. Verifique qual foi o servidor que respondeu: um intermediário e o sistema final de recepção são pontos diferentes. RFC 5321, seção 6.1.
Os nomes dos eventos do fornecedor também precisam de definição. No Amazon SES, por exemplo, SEND indica que o pedido de envio foi aceito; DELIVERY indica entrega ao servidor de e-mail do destinatário. A distinção é útil precisamente porque o segundo evento ainda não diz “a pessoa leu”. Outros serviços podem usar nomes diferentes. Leia o significado dos eventos antes de dar um título à coluna do painel. Definições dos eventos no Amazon SES.
Em uma interface de confirmação de pedido, a nossa proposta é mostrar “Pedido registrado” de imediato e apresentar o status do e-mail separadamente. Mantenha o comprovante disponível na conta autenticada. Uma mensagem que não chegou não deve deixar o cliente pensando se clicar novamente em Pagar é uma técnica razoável de diagnóstico.
O que verificar quando a mensagem desaparece
Siga uma mensagem concreta, em vez de uma queixa vaga de que o e-mail não funciona. Reúna a referência do pedido, a hora de criação, o resultado da tarefa e o identificador atribuído pelo serviço de envio. Procure depois o evento de entrega e o código de diagnóstico. Limite o acesso a estes registros e evite guardar senhas, links de recuperação ou o corpo integral da mensagem apenas para facilitar a investigação.
Os códigos de estado ampliados classificam o sucesso com 2.x.x, a falha temporária com 4.x.x e a falha permanente com 5.x.x. Os outros dígitos acrescentam contexto. Uma falha permanente significa que repetir a mesma tentativa sem alterações dificilmente resolverá o problema; não significa que a pessoa nunca mais possa receber e-mail. Interprete a resposta completa e a documentação do fornecedor. RFC 3463: códigos de estado ampliados.
A nossa ordem de investigação é simples: confirmar a criação da tarefa, o seu processamento, a aceitação pelo fornecedor e o resultado no servidor de destino. Só depois faz sentido investigar a filtragem da caixa com o destinatário. Pedir a alguém para procurar no spam antes de notar que sua fila de envio parou ontem é uma forma eficiente de desperdiçar o tempo de duas pessoas.
Não transforme o botão Reenviar em um canhão de mensagens. Limite as tentativas, espace-as conforme a falha e distinga pedidos repetidos de novos eventos de negócio. Tentar enviar novamente um e-mail nunca deve criar outro pedido nem disparar outro pagamento. Esta separação é uma recomendação de projeto do aplicativo, não uma promessa do SMTP.
SPF, DKIM e DMARC fazem verificações diferentes
O SPF permite ao sistema de recepção verificar se o servidor emissor está autorizado para o domínio relevante do envelope. Por si só, não autentica o nome amigável que a pessoa vê. Inclua os serviços legítimos que efetivamente enviam em seu nome: copiar um registro DNS de um tutorial alheio não substitui esse levantamento. Especificação SPF.
O DKIM associa uma assinatura criptográfica, ligada a um domínio, a cabeçalhos selecionados e ao corpo da mensagem. Ajuda o destinatário técnico a validar a assinatura e o conteúdo assinado. Não é criptografia de ponta a ponta nem certifica que a mensagem seja útil, desejada ou honesta. Especificação DKIM.
O DMARC relaciona a autenticação SPF ou DKIM bem-sucedida com o domínio do remetente visível, através do alinhamento, e permite publicar preferências de tratamento. A especificação principal atual é a RFC 9989, publicada em maio de 2026, que substitui as RFC 7489 e 9091. Uma mensagem autenticada continua sujeita às demais verificações do destinatário. Especificação atual do DMARC.
Uma implementação prática começa por um inventário: a loja, a plataforma de suporte, a ferramenta de faturamento e a newsletter podem enviar mensagens. Verifique a autenticação de cada uma antes de endurecer a política. Caso contrário, uma alteração pensada para impedir falsificação também pode revelar um emissor legítimo esquecido. Trate as mudanças no DNS como uma instalação controlada, com responsável e plano de recuperação.
Uma assinatura válida não reserva lugar na caixa de entrada
As orientações do Gmail para contas pessoais exigem SPF ou DKIM a todos os remetentes e acrescentam exigências de SPF, DKIM e DMARC para grandes volumes. Abordam ainda TLS, DNS, mensagens indesejadas e cancelamento de inscrições. Cumprir a autenticação é importante, mas não há garantia de colocação na caixa de entrada. Requisitos consultados em 8 de outubro de 2026; outros serviços de recepção têm regras próprias. Requisitos de remetentes do Gmail.
Separe o comprovante de pedido de uma campanha promocional no projeto do produto. O cliente precisa de um para concluir a transação e pode não querer o outro. Use um assunto descritivo, um remetente reconhecível e uma mensagem focada. É menos vistoso do que um truque de entregabilidade, mas também exige menos pedidos de desculpa.
Uma “abertura” não prova que alguém leu
A Apple explica que a Proteção da Privacidade no Mail pode baixar conteúdos remotos em segundo plano, mesmo sem interação com a mensagem. O carregamento de uma imagem de rastreamento pode, por isso, produzir uma aparente abertura sem demonstrar atenção humana. No sentido inverso, alguém pode ler o texto sem carregar imagens remotas. Apple: proteção da privacidade no Mail.
Em um fluxo transacional, meça o resultado necessário: a pessoa concluiu a verificação, consultou o comprovante ou recuperou a conta? Defina esse evento no aplicativo, colete apenas o necessário e separe-o dos diagnósticos de entrega. Um painel com uma taxa de abertura elevada não substitui saber se o cliente ficou bloqueado.
Um pequeno teste de aceitação antes do lançamento
Use endereços de teste controlados e o ambiente de testes do fornecedor, quando existir. Experimente uma entrega bem-sucedida, um destino inválido, uma falha temporária e uma solicitação duplicada. Confirme que o pedido continua único, os estados do e-mail permanecem distintos e o suporte consegue seguir a tentativa sem ver segredos. São verificações propostas, não resultados de testes realizados pela Zephyrus.
Para um serviço fictício de reservas, o critério de aceitação poderia ser: “Se o e-mail de confirmação falhar, a reserva continua visível na conta do cliente, a falha fica registrada e existe um reenvio controlado.” É suficientemente concreto para um desenvolvedor implementar e para a pessoa responsável pelo produto verificar.
A melhoria útil raramente é um sinal de “enviado” mais luminoso. É uma descrição honesta do que o sistema sabe, do que não sabe e do passo seguinte. O carteiro digital pode deixar um registro de entrega. Não pode certificar que alguém deixou o café de lado para ler a carta.