Un equipo legal necesitaba prueba de que se había recibido un aviso de terminación de contrato. Lo enviaron por correo electrónico y solicitaron una confirmación de lectura. El cliente de correo del destinatario les pidió enviar un acuse—y el destinatario se negó. El remitente no tenía prueba de lectura, y la cuestión jurídica de si el aviso se había notificado correctamente se complicó.
Las notificaciones de entrega y lectura por correo electrónico parecen sencillas, pero no lo son. Existen estándares, pero la implementación es inconsistente, y los destinatarios tienen un control considerable sobre la información que comparten. Comprender DSN y MDN le ayuda a saber qué puede y qué no puede rastrear de forma fiable.
DSN: Delivery Status Notification
DSN es un estándar (RFC 3461) para informar si un correo electrónico se entregó correctamente al servidor de correo del destinatario.
Cuando envía un correo electrónico, puede solicitar un DSN. Si el servidor receptor lo admite, recibirá una notificación cuando el correo se entregue correctamente, cuando falle de forma permanente (rebote) o cuando se retrase.
DSN opera a nivel de servidor. Le indica si el correo llegó al servidor de correo del destinatario, no si llegó a su bandeja de entrada ni si lo leyó. Un DSN exitoso significa que el servidor aceptó el mensaje—aun así puede terminar en spam o ser filtrado.
Los mensajes de rebote son una forma de DSN. Cuando un correo no puede entregarse, el servidor receptor (o un servidor intermedio) genera un DSN que explica el motivo. Estos son los mensajes de "entrega fallida" que recibe cuando una dirección no es válida o un servidor es inaccesible.
DSN es relativamente fiable porque lo gestionan los servidores, no los usuarios. Los servidores o lo admiten o no, pero no se niegan activamente a enviar notificaciones como sí pueden negarse los usuarios a enviar confirmaciones de lectura.
MDN: Message Disposition Notification
MDN es un estándar (RFC 8098) para informar qué ocurrió con un correo después de la entrega—en concreto, si el destinatario lo leyó.
Cuando solicita un MDN (comúnmente llamado "confirmación de lectura"), le está pidiendo al cliente de correo del destinatario que le notifique cuando abra el mensaje. Si acepta, recibirá una notificación que confirma que el mensaje se mostró.
La diferencia crítica con respecto a DSN: MDN requiere la cooperación del destinatario. Los clientes de correo suelen pedir permiso antes de enviar confirmaciones de lectura, y los usuarios pueden negarse. Muchas personas siempre se niegan. Algunos clientes de correo ni siquiera admiten MDN. Las políticas corporativas a menudo deshabilitan por completo las confirmaciones de lectura.
Esto hace que MDN sea poco fiable para el seguimiento. Podría solicitar confirmaciones para 1.000 correos y recibir 50. Eso no significa que solo se leyeran 50—significa que solo 50 destinatarios aceptaron enviar confirmaciones. Los otros 950 podrían haber leído el correo y rechazado la confirmación, o podrían no haberlo leído en absoluto.
Cómo solicitar notificaciones
Solicitar DSN y MDN implica encabezados específicos del correo electrónico.
Para DSN, se establecen opciones durante la transacción SMTP usando el parámetro NOTIFY. Puede solicitar notificación en caso de éxito, fallo, retraso o nunca. Los detalles dependen de su cliente de correo o del sistema de envío.
Para MDN, incluya un encabezado Disposition-Notification-To en su correo especificando adónde enviar la confirmación. Cuando el destinatario abre el correo, su cliente comprueba este encabezado y (si está configurado para hacerlo) envía una notificación a esa dirección.
La mayoría de los clientes de correo tienen opciones visibles para solicitar confirmaciones de lectura. En Outlook, está en las opciones del mensaje. En Gmail, está disponible para cuentas de Workspace. El cliente se encarga de los detalles técnicos.
Para el envío programático, debe establecer usted mismo los encabezados correspondientes. Su biblioteca o servicio de correo debería admitirlo, aunque el método exacto varía.
Por qué MDN es problemático
Varios factores hacen que las confirmaciones de lectura sean poco fiables y, a veces, contraproducentes.
El control del usuario implica bajas tasas de respuesta. La mayoría de los clientes de correo preguntan antes de enviar confirmaciones, y muchos usuarios se niegan de manera automática. No puede obligar a alguien a confirmar que leyó su correo.
Las preocupaciones de privacidad impulsan el rechazo. Las confirmaciones de lectura revelan información—que el destinatario existe, que leyó el correo, cuándo lo leyó. Los usuarios y organizaciones preocupados por la privacidad deshabilitan por completo las confirmaciones.
El spam y el phishing explotan las confirmaciones. Solicitar una confirmación de lectura les confirma a los spammers que una dirección es válida y está monitorizada. Muchos usuarios preocupados por la seguridad nunca envían confirmaciones por este motivo.
Las normas profesionales varían. En algunos contextos, pedir confirmaciones de lectura se percibe como desconfianza o microgestión. La propia solicitud puede dañar las relaciones.
La inconsistencia técnica implica que las confirmaciones no funcionan de manera uniforme. Diferentes clientes de correo manejan MDN de forma distinta. Algunos no lo admiten. Algunos lo admiten pero por defecto lo rechazan. Algunos envían confirmaciones automáticamente. No puede confiar en un comportamiento consistente.
Cuándo DSN y MDN son útiles
A pesar de sus limitaciones, estas notificaciones tienen usos legítimos.
Usar DSN para correos transaccionales críticos ayuda a confirmar la entrega. Si envía restablecimientos de contraseña o notificaciones importantes, la confirmación DSN de que el servidor aceptó el mensaje aporta cierta garantía.
Usar DSN para la gestión de rebotes es esencial. Las notificaciones de rebote (un tipo de DSN) le indican qué direcciones son inválidas para poder eliminarlas de su lista. Esto es higiene estándar del correo.
MDN puede ser apropiado para comunicaciones específicas de alta importancia. Avisos legales, documentos contractuales u otras comunicaciones en las que importe la prueba de recepción pueden justificar solicitar confirmación de lectura—con el entendimiento de que no siempre la obtendrá.
MDN para comunicaciones internas en entornos controlados puede funcionar. Si su organización configura los clientes de correo para enviar confirmaciones automáticamente, las confirmaciones internas se vuelven fiables. Pero esto requiere la aplicación de políticas de TI.
Alternativas a MDN
Dada la falta de fiabilidad de MDN, otros enfoques suelen funcionar mejor para medir la interacción.
El seguimiento por píxel (seguimiento de aperturas) no requiere la cooperación del destinatario. Una imagen invisible en el correo se carga cuando se abre el mensaje, notificando a su servidor. Tiene sus propias limitaciones (bloqueo de imágenes, funciones de privacidad), pero no depende del consentimiento del usuario para cada correo.
El seguimiento de clics confirma la interacción de forma más fiable que el seguimiento de aperturas. Si alguien hace clic en un enlace de su correo, sabe que interactuó con él. Es una evidencia más sólida que una confirmación de lectura.
El seguimiento de respuestas funciona para correos que solicitan respuesta. Si alguien responde, definitivamente leyó el correo. Para comunicaciones donde se espera respuesta, esta es una confirmación natural.
Los servicios de confirmación de entrega con fines legales proporcionan entrega certificada con prueba. Son servicios especializados para situaciones en las que se requiere prueba legal de entrega—no infraestructura estándar de correo.
DSN y MDN en la práctica
Para la mayoría de los programas de correo, esta es la guía práctica.
Use DSN para gestionar los rebotes. Asegúrese de que su sistema de correo procese las notificaciones de rebote para mantener la higiene de la lista. Es una práctica estándar y, en la mayoría de los casos, no requiere configuración especial.
No confíe en MDN para medir la interacción. Las confirmaciones de lectura son demasiado poco fiables. Use en su lugar el seguimiento por píxel y de clics, entendiendo sus limitaciones.
Solicite MDN de forma selectiva, si acaso. Para mensajes de alta importancia específicos en los que quiere saber si el destinatario lo leyó, solicitar una confirmación es razonable. Pero no espere respuestas y no lo use de manera rutinaria.
Entienda que ninguno prueba la lectura. DSN prueba la aceptación por el servidor, no la entrega a la bandeja de entrada. MDN prueba que el correo se mostró, no que realmente se leyó o se entendió. Ninguno aporta la certeza que proporciona el correo certificado o la entrega en persona.
Frequently asked questions
¿Puedo obligar a alguien a enviar una confirmación de lectura?
No. MDN requiere la cooperación del destinatario. Su cliente de correo pide permiso y puede negarse. No hay manera de forzar una confirmación, e intentar eludir esto sería una violación de la privacidad.
¿Por qué no recibo notificaciones de rebote para todos los correos fallidos?
No todos los servidores envían DSN. Algunos descartan en silencio el correo no entregable. Algunos envían los rebotes a direcciones que no le llegan. La gestión de rebotes es imperfecta, por lo que la higiene de la lista requiere múltiples señales.
¿Son las confirmaciones de lectura lo mismo que el seguimiento de aperturas?
No. Las confirmaciones de lectura (MDN) requieren el consentimiento del destinatario y se envían explícitamente. El seguimiento de aperturas utiliza imágenes invisibles que se cargan sin consentimiento explícito. Miden cosas similares, pero funcionan de manera diferente y tienen distinta fiabilidad.
¿Debería solicitar confirmaciones de lectura para correos de marketing?
En general, no. Parece poco profesional, no generará datos útiles (la mayoría de los destinatarios se negará) y podría activar filtros de spam. Use en su lugar el seguimiento estándar de aperturas y clics.