Muchos clientes se sorprenden cuando tienen problemas de entregabilidad en B2C y han sido muy cuidadosos en cumplir con la normativa legal de protección de datos, han recabado sus suscriptores de forma inequívoca, ellos quieren recibir los boletines y cursan las bajas con celeridad.
Por desgracia, a veces, se han olvidado de un detalle muy importante, eliminar de su BBDD las cuentas de los ISP que han dado un rebote indicativo de que la cuenta ya no existe o no está operativa (normalmente por enviar con sistemas internos artesanales que no gestionan los bounces/rebotes).
Por ejemplo cuando un envío devuelve cualquiera de estos códigos de respuesta SMTP:
- 5.0.0 Address does not exist – La dirección no existe.
- 5.1.1 Bad destination mailbox address – Dirección de buzón de destino incorrecta.
- 5.1.2 Bad destination system address – Dirección del sistema de destino incorrecta.
- 5.1.3 Bad destination mailbox address syntax – Sintaxis de dirección de buzón de destino incorrecta.
- 5.1.4 Destination mailbox address ambiguous – Dirección del buzón de destino ambigua.
- 5.1.6 Mailbox has moved – El buzón se ha movido.
- 5.1.7 Bad sender’s mailbox address syntax – Sintaxis de la dirección del buzón del remitente incorrecto.
- 5.1.8 Bad sender’s system address – Dirección del sistema del remitente erróneo.
- 5.2.0 Other or undefined mailbox status – Otro estado de buzón o indefinido.
- 5.2.1 Mailbox disabled, not accepting messages – Buzón deshabilitado, no acepta mensajes.
Aunque en general hay que descartar y no volver a enviar cualquier rebote/bounce hard con un código 5.x.x.
Cuando esto no se hace el problema es el siguiente:
► Si superamos el número máximo por hora a envíos que ya se han indicado como rebotados con anterioridad el ISP de destino puede bloquear o encolar los siguientes mensajes.
Veamos este log de ejemplo en el que hotmail lo indica de forma inequívoca:
queue #rcpt kbytes conn st retry last error
———————————————- —— ———- —- — ——– ———-
hotmail.queue/cliente_ip-zone_com-6 500997 15929377.0 9 Maximum of 20 recipient errors detected; disconnecting while connected from smtp.consultorpc.com (93.159.xxx.xx) to hotmail-com.olc.protection.outlook.com (104.47.5.33)
· Soluciones a este problema
Lo primero si se utilizan sistemas locales de envío hay que atender los rebotes e irlos limpiando de la BBDD.
A veces es complejo ya que requiere cierta programación o dedicar recursos humanos pero nos podemos ayudar con algún software que existe en el mercado que puede gestionarlos por pop3.
No obstante lo mejor es hacer los envíos con una plataforma como Mailrelay que nos de esta prestación incluida.
Para las BBDD que ya tenemos “sucias” sin haber mantenido podría parece ser fácil de solucionar ya que se trataría de atender a partir de ahora la indicación de las cuentas fallidas, pero no.
Es cierto que cuando se detecten nuevas cuantas erróneas o que ya no están operativas Mailrelay ya las marcará como rebotados, pero las antiguas algunas seguirán dando rebote pero otras no.
La razón es que los ISP convierten algunas en spamtraps o podríamos denominar mejor bouncetraps que vuelven a dejar operativas sin dar rebote varios meses después precisamente para detectar que remitentes cumplen con su exigencia de limpiar los rebotados y fallidos y cuales no.
Para limpiar estas la única solución es descartar las BBDD que tengamos sin mantener o por lo menos mandar a mails que hayan tenido alguna actividad los últimos 3 meses.
Para terminar comentar que la limpieza de cuentas fallidas y rebotados se suele dejar pasar porque normalmente los ISP no son muy estrictos (sobre todo con los remitentes correctos que no hacen spam), pero en ciertas épocas del año (por ejemplo ahora a finales y principios) suelen poner más duras sus reglas y empezar a encolar por este motivo.
También pasa cuando tienen problemas de demasiada carga de trabajo en sus servidores.
