Uma equipe jurídica precisava de prova de que um aviso de rescisão contratual havia sido recebido. Eles enviaram por email e solicitaram um recibo de leitura. O cliente de email do destinatário pediu que enviassem um recibo — e ele recusou. O remetente não tinha prova de leitura, e a questão jurídica sobre se o aviso foi devidamente dado ficou complicada.
Notificações de entrega e leitura de email parecem que deveriam ser simples, mas não são. Os padrões existem, porém a implementação é inconsistente, e os destinatários têm controle significativo sobre as informações que compartilham. Entender DSN e MDN ajuda você a saber o que pode e o que não pode acompanhar de forma confiável.
DSN: Delivery Status Notification
DSN é um padrão (RFC 3461) para informar se um email foi entregue com sucesso ao servidor de email do destinatário.
Ao enviar um email, você pode solicitar um DSN. Se o servidor de recebimento o suportar, você receberá uma notificação quando o email for entregue com sucesso, quando falhar permanentemente (bounce) ou quando houver atraso.
DSN opera no nível de servidor. Ele informa se o email chegou ao servidor de email do destinatário, não se chegou à caixa de entrada ou se foi lido. Um DSN bem-sucedido significa que o servidor aceitou a mensagem — ela ainda pode acabar no spam ou ser filtrada.
Mensagens de bounce são uma forma de DSN. Quando um email não pode ser entregue, o servidor de recebimento (ou um servidor intermediário) gera um DSN explicando o motivo. São aquelas mensagens de “falha na entrega” que você recebe quando um endereço é inválido ou um servidor está inacessível.
DSN é relativamente confiável porque é tratado por servidores, não por usuários. Os servidores ou suportam ou não suportam, mas não recusam ativamente o envio de notificações como os usuários podem recusar recibos de leitura.
MDN: Message Disposition Notification
MDN é um padrão (RFC 8098) para informar o que aconteceu com um email após a entrega — especificamente, se o destinatário o leu.
Quando você solicita um MDN (comumente chamado de “recibo de leitura”), está pedindo ao cliente de email do destinatário que avise quando ele abrir a mensagem. Se ele aceitar, você recebe uma notificação confirmando que a mensagem foi exibida.
A diferença crucial em relação ao DSN: MDN exige cooperação do destinatário. Os clientes de email normalmente pedem autorização aos usuários antes de enviar recibos de leitura, e os usuários podem recusar. Muitas pessoas sempre recusam. Alguns clientes de email nem suportam MDN. Políticas corporativas frequentemente desativam recibos de leitura totalmente.
Isso torna o MDN pouco confiável para rastreamento. Você pode solicitar recibos para 1.000 emails e receber 50 de volta. Isso não significa que apenas 50 foram lidos — significa que apenas 50 destinatários aceitaram enviar recibos. Os outros 950 podem ter lido o email e recusado o recibo, ou podem não ter lido nada.
Como solicitar notificações
Solicitar DSN e MDN envolve cabeçalhos de email específicos.
Para DSN, você define opções durante a transação SMTP usando o parâmetro NOTIFY. É possível solicitar notificação em caso de sucesso, falha, atraso ou nunca. Os detalhes específicos dependem do seu cliente de email ou sistema de envio.
Para MDN, você inclui um cabeçalho Disposition-Notification-To no seu email especificando para onde enviar o recibo. Quando o destinatário abre o email, o cliente verifica esse cabeçalho e (se estiver configurado para isso) envia uma notificação para aquele endereço.
A maioria dos clientes de email tem opções visíveis ao usuário para solicitar recibos de leitura. No Outlook, fica nas opções da mensagem. No Gmail, está disponível para contas Workspace. O cliente cuida dos detalhes técnicos.
Para envio programático, você precisa definir os cabeçalhos apropriados por conta própria. Sua biblioteca ou serviço de email deve oferecer suporte a isso, embora o método exato varie.
Por que MDN é problemático
Vários fatores tornam os recibos de leitura pouco confiáveis e às vezes contraproducentes.
Controle pelo usuário significa baixas taxas de resposta. A maioria dos clientes de email pergunta antes de enviar recibos, e muitos usuários recusam automaticamente. Você não pode obrigar alguém a confirmar que leu seu email.
Preocupações com privacidade levam à rejeição. Recibos de leitura revelam informação — que o destinatário existe, que leu o email, quando leu. Usuários e organizações preocupados com privacidade desativam recibos totalmente.
Spam e phishing exploram recibos. Solicitar um recibo de leitura confirma para spammers que um endereço é válido e monitorado. Muitos usuários focados em segurança nunca enviam recibos por esse motivo.
Normas profissionais variam. Em alguns contextos, solicitar recibos de leitura é visto como falta de confiança ou microgerenciamento. O próprio pedido pode prejudicar relacionamentos.
Inconsistência técnica significa que recibos não funcionam de maneira uniforme. Diferentes clientes de email tratam MDN de formas diferentes. Alguns não suportam. Alguns suportam, mas o padrão é recusar. Alguns enviam recibos automaticamente. Não dá para contar com comportamento consistente.
Quando DSN e MDN são úteis
Apesar das limitações, essas notificações têm usos legítimos.
DSN para emails transacionais críticos ajuda a confirmar a entrega. Se você está enviando redefinições de senha ou notificações importantes, a confirmação via DSN de que o servidor aceitou a mensagem fornece alguma garantia.
DSN para gestão de bounces é essencial. Notificações de bounce (um tipo de DSN) informam quais endereços são inválidos para que você os remova da sua lista. Isso é higiene padrão de email.
MDN para comunicações específicas de alto impacto pode ser apropriado. Avisos legais, documentos contratuais ou outras comunicações em que a prova de recebimento importa podem justificar pedidos de recibo de leitura — com a compreensão de que você nem sempre os receberá.
MDN para comunicações internas em ambientes controlados pode funcionar. Se sua organização configurar clientes de email para enviar recibos automaticamente, recibos de leitura internos tornam-se confiáveis. Mas isso requer aplicação de políticas de TI.
Alternativas ao MDN
Dada a pouca confiabilidade do MDN, outras abordagens geralmente funcionam melhor para acompanhar engajamento.
Rastreamento por pixel (open tracking) não exige cooperação do destinatário. Uma imagem invisível no email é carregada quando o email é aberto, notificando seu servidor. Isso tem suas próprias limitações (bloqueio de imagens, recursos de privacidade), mas não depende do consentimento do usuário para cada email.
Rastreamento de cliques confirma engajamento de forma mais confiável do que rastreamento de abertura. Se alguém clica em um link no seu email, você sabe que houve engajamento. Isso é uma evidência mais forte do que um recibo de leitura.
Rastreamento de respostas funciona para emails que solicitam réplica. Se alguém responde, definitivamente leu o email. Para comunicações em que se espera resposta, isso é uma confirmação natural.
Serviços de confirmação de entrega para fins legais fornecem entrega certificada com prova. São serviços especializados para situações em que é necessária prova legal de entrega — não fazem parte da infraestrutura padrão de email.
DSN e MDN na prática
Para a maioria dos programas de email, aqui vai a orientação prática.
Use DSN para tratamento de bounces. Garanta que seu sistema de email processe notificações de bounce para manter a higiene da lista. Isso é prática padrão e não requer configuração especial na maioria dos casos.
Não dependa de MDN para acompanhar engajamento. Recibos de leitura são muito pouco confiáveis. Use rastreamento por pixel e rastreamento de cliques, entendendo suas limitações.
Solicite MDN de forma seletiva, se solicitar. Para mensagens específicas de alta importância em que você quer saber se o destinatário leu, pedir recibo é razoável. Mas não espere respostas, e não use isso rotineiramente.
Entenda que nenhum deles prova leitura. DSN prova aceitação pelo servidor, não entrega na caixa de entrada. MDN prova que o email foi exibido, não que foi de fato lido ou compreendido. Nenhum oferece a certeza que correspondência registrada ou entrega em pessoa fornece.
Frequently asked questions
Posso obrigar alguém a enviar um recibo de leitura?
Não. MDN exige cooperação do destinatário. O cliente de email do destinatário pede permissão, e ele pode recusar. Não há como forçar um recibo, e tentar contornar isso seria uma violação de privacidade.
Por que não recebo notificações de bounce para todos os emails que falharam?
Nem todos os servidores enviam DSN. Alguns descartam silenciosamente emails não entregáveis. Alguns enviam bounces para endereços que não chegam até você. O tratamento de bounces é imperfeito, por isso a higiene de lista requer múltiplos sinais.
Recibos de leitura são a mesma coisa que open tracking?
Não. Recibos de leitura (MDN) exigem consentimento do destinatário e são enviados explicitamente. Open tracking usa imagens invisíveis que carregam sem consentimento explícito. Medem coisas semelhantes, mas funcionam de forma diferente e têm confiabilidade distinta.
Devo solicitar recibos de leitura para emails de marketing?
Em geral, não. Parece pouco profissional, não vai gerar dados úteis (a maioria dos destinatários vai recusar) e pode acionar filtros de spam. Em vez disso, use o rastreamento padrão de abertura (open) e de cliques.