En abril de 2026 las personas que gestionan las bandejas de entrada y las listas negras del mundo pasaron tres días en Barcelona. Tomamos notas. Aquí están las 25 comprobaciones que salieron de ahí, en lenguaje sencillo, de uso libre, con la persona que dijo cada una identificada.
En abril de 2026, las personas que gestionan las bandejas de entrada, las listas negras y los servidores de correo del mundo pasaron tres dias en La Pedrera de Barcelona en el Deliverability Summit. Steve Atkins de Word to the Wise, David Finger de Seznam, LB Blair y Varun Jain de SendPost, Syed Alam de Postmastery, Chris Adams de Bird, Raymond Dijkxhoorn de SURBL. Hablamos el segundo dia y tomamos notas de todo lo demas.
Esto es lo que nos trajimos: 25 cosas que un programa de email puede revisar, cada una atribuida a quien la dijo, cada una escrita para que un responsable de CRM o de marketing pueda leerla sin un ingeniero de sistemas al lado. Es de uso libre, se puede copiar y reenviar. Si alguna te ahorra un viernes, cuentanos cual.
Comprobaciones de contenido antes del envio
Manten cada linea de cabecera corta
Steve Atkins mostro que una linea de cabecera de mas de 998 caracteres deja de ser SMTP valido, y Microsoft corta las cabeceras alrededor de los 700 caracteres. Cuando una cabecera se corta sin un espacio donde partir, el DKIM se rompe sin ningun aviso. El header List-Unsubscribe suele ser el culpable, porque algunas plataformas meten todo el registro del suscriptor en esa unica URL.
Como comprobarlo: Revisa tu cabecera List-Unsubscribe y otras cabeceras largas. Lo que pase de 500 caracteres merece acortarse; lo que pase de 900, arreglarse hoy mismo.
Steve Atkins, Word to the Wise
Acorta el propio enlace de baja
Atkins senalo un patron concreto: algunos ESPs meten en la URL de baja todos los campos que conocen del suscriptor, generando enlaces de varios miles de caracteres. Esos enlaces rompen el DKIM igual que una cabecera larga.
Como comprobarlo: Mide la longitud total de tu cabecera List-Unsubscribe. Si la URL pasa de 500 caracteres, cambiala por un token corto que tu servidor resuelva contra el registro del suscriptor, en lugar de llevar los datos en la propia URL.
Steve Atkins, Word to the Wise
Codifica el cuerpo, no lo conviertas en una sola linea
Los minificadores de HTML eliminan los saltos de linea, y eso deja un cuerpo de una sola linea de miles de caracteres. No existe una regla de plegado para el cuerpo como la que existe para las cabeceras. Codificar en quoted-printable o base64 mantiene cada linea por debajo de 80 caracteres en el cable, haga lo que haga el minificador.
Como comprobarlo: Confirma que tu canal de envio codifica el cuerpo HTML en quoted-printable o base64 antes de salir, y marca cualquier linea sin codificar de mas de 998 caracteres.
Steve Atkins, Word to the Wise
No envies acentos ni emojis en crudo por el cable
El soporte SMTP para UTF-8 en crudo no es universal. Si un relay por el camino no lo soporta, vuelve a codificar el cuerpo el mismo, y eso rompe el hash del cuerpo del DKIM. Codificar acentos, emojis, cirilico o kanji como quoted-printable o base64 evita el problema por completo.
Como comprobarlo: Revisa cabeceras y cuerpo en busca de bytes no ASCII sin codificar antes de enviar. Si encuentras alguno, fuerza quoted-printable o base64 en lugar de confiar en que el servidor receptor negocie bien el UTF-8.
Steve Atkins, Word to the Wise
Pon https en cada enlace, tambien en el pie
LB Blair y Varun Jain revisaron casi 4.000 millones de mensajes en SendPost: los emails donde cada enlace era https entregaron el 98,1% de las veces. Un unico enlace http suelto no cambiaba nada medible, pero dos o mas hacian caer la entrega con fuerza. Los culpables habituales son enlaces viejos del pie, dominios de tracking y el logo de un partner que nadie ha tocado en anos.
Como comprobarlo: Abre tu ultima campana, busca http:// en el HTML y arregla lo que encuentres. Son unos diez minutos y es la victoria mas barata de esta lista.
LB Blair y Varun Jain, SendPost
Los enlaces no perjudican, los irrelevantes si
En el mismo conjunto de datos de SendPost, el grupo de emails con mas apertura llevaba siete enlaces o mas, tanto en newsletters como en ecommerce. El numero de enlaces nunca fue el problema que se suponia. Lo que de verdad perjudica un mensaje son los enlaces que el lector no tiene motivo para pulsar, no la cantidad.
Como comprobarlo: Antes de quitar enlaces para “simplificar” un email, pregunta si cada uno se gana su sitio, no cuantos hay.
LB Blair y Varun Jain, SendPost
Escribe un alt text que alguien quiera leer
El mismo conjunto de datos de SendPost mostro que los emails sin alt text en ninguna imagen rendian peor que el resto, y que los receptores leen las palabras del alt text como una senal sobre el mensaje. Que faltara en una o dos imagenes apenas se notaba, pero un texto generico como “banner” o “imagen1” contaba como si no hubiera nada.
Como comprobarlo: Trata el alt text como el pie de foto de un periodico: que se ve y por que esta ahi. Tus lectores con discapacidad visual y la bandeja de entrada coinciden en esto.
LB Blair y Varun Jain, SendPost
Manten el email entre 40 y 80 KB
El punto optimo de SendPost fue entre 41 y 60 KB de HTML. Los emails muy pequenos, de solo texto, tambien rindieron bien. Pasados los 100 KB, el rendimiento cae con rapidez. La mayoria de los emails demasiado pesados no son largos: llevan cinco imagenes destacadas donde bastaria con una, y una plantilla que nadie ha abierto en un editor de codigo este ano.
Como comprobarlo: Mide el HTML ya renderizado antes de enviar. Si pasa de 100 KB, busca primero imagenes que optimizar y codigo viejo que quitar, antes de buscar texto que recortar.
LB Blair y Varun Jain, SendPost
Que salir sea tan facil como un clic
La baja en un clic, la cabecera List-Unsubscribe-Post de la RFC 8058, la ofrece ya el 82,8% de los remitentes masivos y es obligatoria en Gmail y Yahoo desde febrero de 2024. Un lector que puede darse de baja de un toque no llega a pulsar el boton de spam, y ese boton es la senal que mas cuesta.
Como comprobarlo: Pidele a tu plataforma que te ensene la cabecera real en un mensaje enviado de verdad, no solo la pantalla de configuracion que dice que esta activada.
David Finger, Seznam
Comprobaciones de autenticacion
Manten el SPF por debajo de diez consultas DNS
David Finger advirtio que aqui es donde los remitentes con varias herramientas se quedan sin margen mas rapido. El SPF tiene un limite duro de diez consultas DNS; pasarlo hace que el registro devuelva un error permanente, que los servidores de correo tratan como un fallo.
Como comprobarlo: Resuelve de forma recursiva los includes, redirects y demas consultas de tu registro SPF y cuentalos. A partir de ocho merece la pena aplanarlo antes de llegar a diez.
David Finger, Seznam
Firma con RSA-2048, no con Ed25519
Steve Atkins confirmo que Gmail, Yahoo y Microsoft todavia no soportan firmas DKIM con Ed25519. Un mensaje firmado asi vuelve como “neutral: no key” en Gmail, que en la practica equivale a no llevar firma. RSA-2048 sigue siendo el estandar hasta que DKIM2 este terminado.
Como comprobarlo: Revisa la configuracion de firma DKIM para ver el algoritmo y la longitud de clave, y confirma que la clave publica en el DNS coincide con la que realmente usas para firmar.
Steve Atkins, Word to the Wise
Lleva el DMARC hacia p=reject
David Finger lo dijo sin rodeos: p=none “no ofrece proteccion real” y con el tiempo se gana una reputacion mas lenta y mas baja. p=reject es lo que el llamo el estandar de oro, y se espera que los proveedores de bandeja empiecen a penalizar los dominios en p=none dentro de uno o dos anos.
Como comprobarlo: Consulta el registro DMARC de cada dominio de envio. Lo que siga en p=none o p=quarantine necesita un plan de migracion, con los informes rua realmente revisados por el camino.
David Finger, Seznam
Que pasen SPF y DKIM, no solo uno
Microsoft se esta moviendo hacia exigir que pasen tanto SPF como DKIM para el alineamiento de DMARC, en lugar de dejar que uno compense al otro como algunos remitentes suponen.
Como comprobarlo: Despues de un envio, revisa la cabecera authentication-results y confirma que SPF y DKIM aparecen como pass, incluso cuando el DMARC general parece correcto.
Steve Atkins, Word to the Wise
Confirma que tu IP de envio resuelve en ambos sentidos
El DNS inverso confirmado hacia adelante, FCrDNS, significa que el registro PTR de una IP de envio coincide con su nombre HELO, y que ese nombre resuelve hacia adelante de vuelta a la misma IP. Tanto la presentacion propia de Data Innovation como Atkins, por separado, lo llamaron una barrera obligatoria para cualquier dominio nuevo.
Como comprobarlo: Para cada IP de envio: consulta el registro PTR, resuelve ese nombre hacia adelante y confirma que vuelve a la IP original antes de que el dominio envie un solo mensaje.
Florin Armasu, Data Innovation y Steve Atkins, Word to the Wise
Rota los selectores DKIM con calendario y solape
Un selector mensual, publicado una semana antes de entrar en uso y valido durante treinta dias tras la rotacion, hace que una clave nunca quede obsoleta sin una ventana de seguridad detras.
Como comprobarlo: Confirma que el selector DKIM actual corresponde al mes esperado, que el del mes siguiente ya esta publicado en el DNS y que el del mes anterior sigue siendo valido.
Florin Armasu, Data Innovation
Comprobaciones de DNS
Asegurate de que todos los nameservers coinciden
Atkins mostro un caso real en el que dos proveedores de DNS tenian registros ligeramente distintos para el mismo dominio, y eso hacia que el DKIM fallara al azar segun que nameserver respondiera.
Como comprobarlo: Consulta todos los nameservers autoritativos de un dominio y compara los registros SPF, DKIM, DMARC y MX entre todos ellos, cada semana.
Steve Atkins, Word to the Wise
Comprueba que el DNSSEC no esta roto en silencio
Un dominio que publico DNSSEC y luego lo rompio sigue resolviendo bien para la mayoria de herramientas, porque los resolvers estandar no lo validan. Los resolvers que si validan DNSSEC, en cambio, devuelven errores, y la mayoria de comprobadores online nunca revisan esto.
Como comprobarlo: Si un dominio tiene DNSSEC publicado, pasalo por un analizador especifico de DNSSEC, no por un comprobador de DNS generico.
Steve Atkins, Word to the Wise
Vigila los dominios de destino que cambian de dueno
Raymond Dijkxhoorn, de SURBL, senalo que los dominios que cambian de propietario pueden convertirse en spam traps reciclados de la noche a la manana. Una direccion que era segura hace un ano no lo es automaticamente hoy.
Como comprobarlo: Guarda los registros MX que ves de los dominios de destino en el momento de captarlos, y revisalos cada mes. Marca cualquier direccion cuyo MX haya cambiado desde entonces para volver a verificarla.
Raymond Dijkxhoorn, SURBL
Comprobaciones de higiene de lista
Valida la sintaxis antes de que una direccion entre en cola
Toda direccion deberia pasar una comprobacion de sintaxis RFC 5321 antes de entrar en cualquier cola de envio. Es el filtro mas barato que existe y va al principio del canal.
Como comprobarlo: Rechaza las direcciones mal formadas en el momento de captarlas. Suprimelas en silencio en lugar de rebotarlas, y registralas en el almacen de supresion.
Florin Armasu, Data Innovation
Trata con cuidado las direcciones de rol
Direcciones como admin@, abuse@, postmaster@, info@ y sales@ tienen mas riesgo de convertirse en spam traps o de generar quejas por bucles de retroalimentacion.
Como comprobarlo: Marca las direcciones de rol en el momento de captarlas. Mantenlas fuera de los envios masivos de marketing y permitelas solo en correo transaccional, con un ritmo de envio mas suave.
Florin Armasu, Data Innovation
Filtra los dominios desechables
Las direcciones de servicios como guerrillamail o tempmail nunca convierten y a menudo terminan siendo trampas mas adelante. No hay ninguna ventaja en conservarlas.
Como comprobarlo: Manten una lista actualizada de dominios desechables y descarta las direcciones que coincidan en el momento de captarlas, suprimiendolas en silencio en lugar de rebotarlas.
Florin Armasu, Data Innovation
Envia menos a quien dejo de leer, con calendario
Cuando Dela Quist pregunto al panel de blocklists en que momento exacto una direccion silenciosa se vuelve un riesgo, nadie tenia una cifra firme, y SURBL confirmo que las trampas ahora abren y hacen clic a proposito para no quedar fuera de una lista por antiguedad. La respuesta practica es una escalera, no un precipicio: reducir la frecuencia a los 90 dias de silencio, pasar a mensual a los 180, a trimestral a los 270, y pausar del todo tras un ano sin ninguna interaccion, reverificando por MX antes de la supresion final.
Como comprobarlo: Incorpora esa escalera a tu calendario de envios en lugar de hacer una gran purga anual. Protege tu margen tanto como tu colocacion: menos envios a quien ya se fue, mas atencion para quien sigue ahi.
Panel de Blocklists, Deliverability Summit 2026
Comprobaciones de gestion de rebotes
Deja de tratar todo 5xx como el mismo rebote
Syed Alam, de Postmastery, defendio tres categorias en lugar de una: un rebote duro significa que el destinatario es realmente invalido y debe suprimirse de inmediato; un rebote blando es un problema temporal que merece un reintento exponencial antes de suprimir; y lo que el llama un rebote que no lo es, como un rechazo por politica o un mensaje de demasiadas conexiones, es un problema del remitente o de politica que nunca deberia suprimir al destinatario.
Como comprobarlo: Audita tus reglas de clasificacion de rebotes y confirma que los codigos 5xx relacionados con politica se registran aparte, sin tratarlos como prueba de que la direccion es mala.
Syed Alam, Postmastery
Vigila el numero absoluto de quejas, no solo la tasa
Chris Adams, de Bird, describio una red de afiliados que mantenia su tasa de quejas por debajo del 0,03% mientras generaba 78.000 quejas al dia. La tasa por si sola no reflejaba en absoluto la magnitud del problema.
Como comprobarlo: Sigue el numero absoluto de quejas diarias por dominio ademas de la tasa, y fija un disparador de revision, por ejemplo 100 quejas diarias o mas, por pequena que parezca la tasa.
Chris Adams, Bird
Comprobaciones de infraestructura
Revisa cuanto se concentra tu trafico en un solo proveedor
La misma red de afiliados que describio Adams enviaba entre el 95 y el 100% de su trafico solo a Yahoo. Los remitentes legitimos se reparten de forma natural entre proveedores porque asi lo hace su audiencia real.
Como comprobarlo: Calcula la distribucion de proveedores de destino por dominio de envio. Si un solo proveedor se lleva mas del 80% del volumen, tomalo como motivo para mirar mas de cerca de donde viene esa lista.
Chris Adams, Bird
Preparate para BIMI mientras tu DMARC esta fuerte
David Finger confirmo que BIMI ayuda a la reputacion una vez que la base esta lista: DMARC en p=reject, un logo SVG cuadrado de menos de 32 KB, y un Certificado de Marca Verificada que siga vigente.
Como comprobarlo: Para cualquier dominio que ya este en p=reject, comprueba si existe ya un registro BIMI. Si no existe, es una oportunidad abierta, no un problema que arreglar.
David Finger, Seznam
Donde hay voluntad, hay solucion. Ninguna de las 25 comprobaciones anteriores necesita una herramienta nueva: la mayoria necesita veinte minutos y una persona que sepa donde mirar.
Si quieres un segundo par de ojos sobre tu propio programa, los nuestros son gratis durante veinte minutos. Desde 49 EUR por dominio al mes y desde 0,135 EUR por cada 1.000 envios si nos quieres en el equipo.