O cliente pagou. A encomenda existe. A aplicação mostra “Email de confirmação enviado”. Cinco minutos depois, chega uma mensagem ao suporte: “Não recebi nada.” Os dois ecrãs podem estar a dizer a verdade. Estão apenas a descrever partes diferentes do percurso.
O Dia Mundial dos Correios, a 9 de outubro, assinala 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 email também tem passagens de responsabilidade, e o visto 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 registado. “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 a aplicação junta estes estados, o diagnóstico começa com uma testemunha pouco fiável: a sua 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 receção são pontos diferentes. RFC 5321, secçã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 aceite; DELIVERY indica entrega ao servidor de email 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.
Numa interface de confirmação de encomenda, a nossa proposta é mostrar “Encomenda registada” de imediato e apresentar o estado do email separadamente. Mantenha o comprovativo disponível na conta autenticada. Uma mensagem em falta não deve deixar o cliente a ponderar se carregar 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 email não funciona. Reúna a referência da encomenda, 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 registos e evite guardar palavras-passe, ligações de recuperação ou o corpo integral da mensagem apenas para facilitar a investigação.
Os códigos de estado alargados classificam o sucesso com 2.x.x, a falha temporária com 4.x.x e a falha permanente com 5.x.x. Os restantes algarismos 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 email. Interprete a resposta completa e a documentação do fornecedor. RFC 3463: códigos de estado alargados.
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 a sua fila de envio parou ontem é uma forma eficiente de desperdiçar o tempo de duas pessoas.
Não transforme o botão Reenviar num canhão de mensagens. Limite as tentativas, espace-as conforme a falha e distinga pedidos repetidos de novos eventos de negócio. Voltar a tentar enviar um email nunca deve criar outra encomenda nem desencadear outro pagamento. Esta separação é uma recomendação de desenho da aplicação, não uma promessa do SMTP.
SPF, DKIM e DMARC fazem verificações diferentes
O SPF permite ao sistema de receçã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 por si: copiar um registo 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 é encriptação 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 restantes 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 faturação 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 subscriçõ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 receção têm regras próprias. Requisitos de remetentes do Gmail.
Separe o comprovativo de encomenda de uma campanha promocional no desenho 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 descarregar conteúdos remotos em segundo plano, mesmo sem interação com a mensagem. O carregamento de uma imagem de rastreio 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.
Num fluxo transacional, meça o resultado necessário: a pessoa concluiu a verificação, consultou o comprovativo ou recuperou a conta? Defina esse evento na aplicação, recolha 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 um pedido duplicado. Confirme que a encomenda continua única, os estados do email 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 email de confirmação falhar, a reserva continua visível na conta do cliente, a falha fica registada e existe um reenvio controlado.” É suficientemente concreto para um programador implementar e para o responsável pelo produto verificar.
A melhoria útil raramente é um visto 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 registo de entrega. Não pode certificar que alguém pousou o café para ler a carta.