Balance de entregabilidad 2026: 9 cambios que atender antes de 2027

Nueve cambios llegaron a los remitentes de email en 2026, y la mayoría exige un ajuste antes de 2027. Google retiró Postmaster Tools v1 y sus puntuaciones de reputación. DMARC se republicó como RFC 9989, que añade tres etiquetas y elimina pct. DKIM2 apunta a 2027. Gmail juzga ahora un dominio y sus subdominios en conjunto, y Comcast ha empezado a trasladar sus buzones a los filtros de Yahoo.

Matthew Vernhout, de Email Industries, repasó los nueve en el webinar de Unspam.email 2026 Deliverability Review and 2027 Outlook del 8 de octubre de 2026, con Michaela Barriga, también de Email Industries, como moderadora. Este resumen cubre cada cambio con las diapositivas de la sesión, las modificaciones exactas del registro DMARC y las diez preguntas que hizo el público. Si quieres una lista fechada de todos los cambios de 2026, incluidos los que la sesión no trató, consulta nuestro resumen de novedades de entregabilidad del correo.

Pulsa play para cargar este vídeo desde YouTube (Google). Consulta nuestra política de cookies.

Los nueve cambios de un vistazo

Cada cambio tiene su propia sección más abajo, con la diapositiva que se mostró en la sesión cuando la hay.

Google Postmaster Tools v1 ya no existe, y sus puntuaciones de reputación se fueron con él

Google Postmaster Tools v1 ya no funciona: sus paneles, sus valoraciones de reputación High, Medium, Low y Bad, sus exportaciones y su API están apagados. Spam Resource informó de que la interfaz se estaba retirando cuenta por cuenta desde el 20 de agosto de 2026, y Matthew situó el final del apagado en torno a octubre. Postmaster Tools v2 no tiene ninguna puntuación de reputación que las sustituya.

La opinión de Matthew, a partir de conversaciones con gente de Google, es que esas puntuaciones llevaban mucho tiempo sin ser precisas. Postmaster Tools v1 tenía unos 15 años y estaba sin mantenimiento desde mucho antes de su retirada. Por eso v1 y v2 mostraban cifras distintas de denuncias de spam para el mismo dominio: v2 tenía las fuentes de datos completas, así que v2 ya era la fuente de referencia.

Para los remitentes cambian tres cosas:

• Todo lo que leía datos de la v1 hay que reconstruirlo. Las cuentas pasaron a v2 por sí solas, pero los scripts y las integraciones de proveedores no. La API v2 tiene una estructura de datos nueva y necesita acceso OAuth a la cuenta de Postmaster.
• Postmaster Tools v2 informa del cumplimiento, no de la reputación. Muestra qué porcentaje de mensajes supera la comprobación de baja en un clic, los fallos de alineación SPF y DKIM y el spam denunciado por los usuarios. Nuestra guía de Postmaster Tools v2 cubre cada vista.
• Los datos cubren solo cuentas personales de Gmail. Postmaster Tools mide el correo enviado a direcciones gmail.com y googlemail.com, nunca a buzones de Google Workspace. Una marca de consumo obtiene datos abundantes, mientras que un remitente B2B con poco volumen hacia cuentas personales de Gmail a menudo recibe demasiado pocos para una lectura fiable.

Matthew pidió a todo el mundo que use el botón de comentarios de Postmaster Tools v2 para solicitar un indicador de reputación. Su razonamiento: Google añade lo que piden suficientes remitentes.

La lista negra Heatwave de Validity apunta a los dominios calentados con interacción falsa

Heatwave es una lista negra de dominios que Validity lanzó el 3 de septiembre de 2026, dirigida al correo en frío que sale de dominios calentados con interacción sintética. Una herramienta de calentamiento sintético envía correo entre cuentas que controla y después lo abre, lo responde y lo saca de spam automáticamente, para que un dominio nuevo parezca de confianza. El anuncio de Validity cita a Spamhaus, SURBL, Comcast y Proofpoint entre las organizaciones que usan o evalúan la lista. Matthew cifró su tamaño en unos 1,1 millones de dominios en el lanzamiento, y sigue creciendo.

Heatwave califica un dominio en lugar de limitarse a incluirlo en la lista. Matthew describió cuatro estados:

1. No listado.
2. Precalentamiento: el dominio se está calentando y todavía no ha enviado nada más.
3. Calentamiento sintético observado: tráfico de calentamiento y nada más.
4. Graduado: el dominio se calentó de forma sintética y ahora envía prospección real.

Un dominio que nunca usó una herramienta de calentamiento puede salir de la lista a través de la vía de escalado de Heatwave. Lee primero la descripción del listado, porque indica qué comportamiento se observó. Un remitente que sí usa una herramienta de calentamiento debería preguntar directamente al proveedor si su patrón de interacción es abusivo, porque Heatwave apunta precisamente a esas herramientas.

DMARCbis añade tres etiquetas: np, psd y t

DMARCbis es el estándar DMARC revisado, publicado como RFC 9989 en mayo de 2026, y añade tres etiquetas al registro DMARC: np, psd y t. Matthew lo describió como la versión dos de DMARC, aunque un registro DMARCbis sigue empezando por v=DMARC1.

• np fija la política para los subdominios que no existen. El apaño de antes era un registro SPF o DKIM comodín que declaraba que un nombre no envía correo. np=reject pide a los receptores que rechacen el correo de cualquier subdominio tuyo que no tenga ningún registro DNS, que es justo donde acuden primero los suplantadores.
• psd indica dónde empieza tu organización. DMARC encontraba antes el dominio organizativo de un dominio a través de la Public Suffix List, un archivo mantenido por voluntarios al que le cuesta seguir el ritmo de los nuevos dominios de nivel superior. El RFC 9989 sustituye esa consulta por un recorrido del árbol DNS, y psd=n en tu propio dominio raíz indica a los receptores que es el dominio organizativo de sí mismo y de todo lo que cuelga de él. psd=y es para las entidades de registro que gestionan un sufijo público, no para las marcas.
• t=y es un modo de prueba. El receptor aplica un nivel menos que la política publicada, así que p=reject; t=y se trata como quarantine y p=quarantine; t=y como none. Matthew lo recomendó para el paso de none a quarantine, de modo que los informes muestren lo que pasaría antes de que ningún correo se vea afectado.

Matthew añadió algo que importa más que cualquier etiqueta: activa los informes agregados. Muchas empresas que llegan a Email Industries publicaron p=none hace años sin ninguna dirección rua. Ese registro cumple el requisito de Google y Yahoo, pero no le dice nada al propietario del dominio. Los dominios personales del propio Matthew, cada uno con un solo usuario, sufren suplantaciones con regularidad. Entre los dominios que analizamos, solo el 48% publica una política DMARC y el 52% de los dominios sigue sin tener ninguna, según el Email Deliverability Benchmark de Unspam.email.

DMARCbis elimina pct, ri, rf y el límite de tamaño de los informes

El RFC 9989 eliminó las etiquetas pct, ri y rf, y convirtió el límite de tamaño ! de una dirección de informes en sintaxis obsoleta que quienes generan los informes ignoran. Las cuatro pueden borrarse hoy mismo de un registro DMARC.

La etiqueta pct era la que más confusión causaba. Pedía a los receptores que aplicaran la política a un porcentaje del correo que fallaba, y el argumento de Matthew era que nadie podía calcularlo: ¿cuánto es el 50% de una cifra desconocida? Algunos receptores muestreaban un mensaje de cada dos, y muchos trataban la etiqueta como un todo o nada. El valor más común, pct=100, era el valor por defecto de todas formas y no hacía nada.

Hay un caso que va más allá de lo cosmético. Un registro con p=reject; pct=25 rechazaba una cuarta parte del correo que fallaba con el estándar antiguo y lo rechaza todo en un receptor que sigue el RFC 9989. Google, Yahoo y Microsoft no se habían comprometido públicamente con la semántica del RFC 9989 en septiembre de 2026, así que las dos interpretaciones conviven. Nuestra guía del RFC 9989 tiene el detalle. Un remitente que escalonó la exigencia con pct debería usar ahora t=y con el mismo fin.

El límite de tamaño es el !10m al final de una dirección como rua=mailto:drua@example.net!10m, que pedía informes de no más de 10 MB. Matthew rara vez lo vio en uso, y los informes agregados son pequeños de todas formas. El RFC 9989 conserva la sintaxis solo para que los registros antiguos se sigan pudiendo analizar.

Actualizar un registro a DMARCbis son tres borrados y dos añadidos

El registro de la diapositiva de Matthew venía de un cliente real, con solo el dominio cambiado. Esta es la versión heredada:

v=DMARC1; p=reject; pct=100; ri=86400; fo=1; rua=mailto:drua@example.net!10m; ruf=mailto:druf@example.net

Este es el mismo registro actualizado para DMARCbis:

v=DMARC1; p=reject; np=reject; psd=n; fo=1; rua=mailto:drua@example.net; ruf=mailto:druf@example.net

La actualización borra pct=100, ri=86400 y el límite de tamaño !10m, y añade np=reject y psd=n. Es seguro publicarla hoy. Un receptor que sigue con el RFC 7489 ignora np y psd, porque ambos estándares piden a los receptores que ignoren las etiquetas que no conocen, y los valores borrados eran valores por defecto o se ignoran.

La pregunta que más repitió el público fue cuándo hacer este cambio, y la respuesta de Matthew fue que ya. El verificador de DMARC de Unspam.email señala pct, ri y rf en un registro publicado, y el generador de registros DMARC escribe un registro con una política np.

DKIM2 resuelve el replay y las listas de correo, y es un proyecto para 2027

DKIM2 es la próxima versión de DKIM, todavía un borrador del IETF y no un RFC, y resuelve dos problemas que el DKIM original arrastra desde hace años. Matthew espera que empiece a importar en 2027.

• DKIM2 frena el replay. Con el DKIM actual, un atacante puede tomar un mensaje firmado, cambiar las partes que la firma no cubre y reenviarlo en masa sin que DKIM deje de validar. Los remitentes se defendían firmando cabeceras de más (oversigning). DKIM2 registra cada salto que da un mensaje, así que una copia reenviada a otros destinatarios ya no se valida como el original.
• DKIM2 sobrevive a las listas de correo. Hoy, una lista de discusión que añade un pie o edita el asunto rompe una firma DKIM. Con DKIM2, cada sistema que modifica un mensaje registra qué cambió, y el receptor final puede reconstruir el camino hacia atrás para confirmar que el original estaba intacto. Matthew lo llamó cadena de custodia.

DKIM2 también deja sitio a claves más robustas, incluidos algoritmos poscuánticos. Sobre la longitud de clave Matthew fue tajante: las claves de 512 bits no deberían usarse nunca, las de 1024 bits van de salida y 2048 bits es el tamaño que hay que pedirle a tu plataforma. Nuestra guía sobre la longitud de clave DKIM explica qué se gana y qué se pierde con cada tamaño.

Los remitentes que usan una plataforma de email no tienen casi nada que cambiar en el DNS a corto plazo. Las plataformas ejecutarán un firmante DKIM2 junto al firmante DKIM1 con tu clave actual, y un CNAME que apunte tu registro DKIM al proveedor le permite actualizar las claves más adelante sin que tengas que intervenir. FastMail es el mayor proveedor de buzón que firma hoy con DKIM2 y lo comprueba en el correo entrante, pero la mayoría de los remitentes todavía no firman con él. El consejo práctico de Matthew fue pedir a tu plataforma de email su hoja de ruta de DKIM2 en la próxima llamada o renovación, porque las plataformas construyen lo que piden suficientes clientes. Nuestra guía sobre DKIM2 y DMARCbis cubre el borrador a fondo.

El programa de Gmail para remitentes políticos es una verificación, no carta blanca

Gmail abrió un Verified Sender Program para comités políticos de EE. UU. el 8 de septiembre de 2026, construido sobre Campaign Verify, el servicio de verificación que ya se usa para los SMS y las llamadas políticas. Llega después de un piloto anterior de Google para el correo político al que se sumaron pocas campañas.

Un comité registrado en la Federal Election Commission puede inscribirse cuando verifica su dominio de envío a través de Campaign Verify, firma con DKIM, publica SPF, se registra en Postmaster Tools y mantiene su tasa de spam por debajo del 0,3% en una media de 14 días. El correo inscrito sigue yendo a spam cuando un destinatario lo denuncia, bloquea al remitente o lo filtra. Matthew insistió en que el programa es Google aprendiendo quién es un remitente político, no una exención de sus políticas.

Varios clientes de Email Industries se han registrado, y Matthew todavía no ha visto un efecto medible. Para cualquier otro remitente no cambia nada.

La bandeja con IA de Gmail lee tu texto, y un email hecho solo de imágenes no tiene nada que resumir

Gmail usa ahora Gemini para ordenar, priorizar y resumir el correo, y un resumen solo puede describir el texto que contiene un mensaje. Google anunció el Gmail de la era Gemini el 8 de enero de 2026, y la vista de bandeja con IA, que ordena lo que merece atención, sigue limitada a suscriptores.

Matthew hizo cuatro observaciones sobre el correo en la bandeja con IA:

• Todas las pestañas de Gmail son la bandeja de entrada. Principal, Promociones, Social, Notificaciones y Foros son todas bandeja de entrada, y quien lee Gmail en Outlook o Thunderbird nunca ve las pestañas. Forzar el paso de Promociones a Principal funciona durante un tiempo, y después el correo se vuelve a clasificar.
• La prioridad se aprende de la interacción. La bandeja con IA decide qué es urgente según cómo trata cada persona tu correo, así que el marketing que un suscriptor nunca abre baja en la lista de ese suscriptor.
• El email hecho solo de imágenes se resume mal. Sin texto real, el modelo tiene que leer las imágenes o adivinar. El texto HTML y un texto alternativo descriptivo le dan algo con lo que trabajar, y merece la pena comprobar si el resumen dice lo que querías decir.
• Los datos estructurados salen a la superficie. Gmail ya sube un código de verificación en dos pasos a la parte superior del mensaje con un botón para copiarlo. El marcado de schema de una rebaja permite que esos mismos sistemas muestren la oferta de forma más destacada.

Cómo leen los resúmenes un mensaje, y qué controla un remitente en ellos, lo explica nuestra guía sobre los resúmenes con IA en la bandeja de entrada.

Gmail juzga ahora tus subdominios y tu dominio raíz en conjunto

Gmail comprueba sus requisitos para remitentes sobre un dominio y sus subdominios en conjunto, y el panel Estado de cumplimiento de Postmaster Tools v2 los presenta así. El panel comprueba ocho requisitos: autenticación SPF y DKIM, alineación de la cabecera From, autenticación DMARC, cifrado, tasa de spam denunciada por los usuarios, registros DNS, baja en un clic y respeto de las bajas.

La advertencia de Matthew fue que un subdominio que cumple ya no protege a un dominio raíz que no cumple. El caso típico es el marketing enviado desde un subdominio con una baja en un clic que funciona, mientras el correo transaccional sale del dominio raíz hacia personas que ya se dieron de baja. Cuando esos destinatarios denuncian el correo transaccional, lo paga el dominio entero. Lo mismo pasa cuando una segunda división envía a su propia lista y las dos listas se solapan. Email Industries lo ve, en palabras de Matthew, "una y otra vez".

La solución es organizativa, no técnica: una sola lista de supresión compartida por todos los equipos y plataformas que envían con el dominio. Entre los emails que analizamos, solo el 14% de los remitentes supera la comprobación de List-Unsubscribe en un clic, así que, en la mayoría de los programas, lo primero que hay que arreglar es la propia cabecera. Nuestra guía de la cabecera List-Unsubscribe muestra las cabeceras que espera Gmail.

El correo de Comcast pasa a los filtros de Yahoo

Comcast está migrando sus buzones de consumo a Yahoo, así que el correo dirigido a direcciones comcast.net lo filtrarán cada vez más las reglas de Yahoo. La página de migración de Xfinity dice que las direcciones siguen siendo @comcast.net, y los registros MX de comcast.net todavía apuntan a Comcast por ahora. Los dominios de consumo de AT&T, como att.net, ya siguieron el mismo camino.

La migración tiene dos caras para los remitentes:

• Los problemas con Yahoo te seguirán a Comcast. Un remitente con mala entrega en Yahoo debería esperar lo mismo en comcast.net a medida que se trasladan los buzones.
• Lo que funciona en Yahoo funcionará en Comcast. Se aplican el techo del 0,3% de denuncias, las reglas de autenticación y los códigos de rebote de Yahoo, y la mayoría de las plataformas ya procesan esos rebotes.
• La transición será accidentada. Matthew espera más rebotes, bloqueos nuevos y un cambio en el origen de las denuncias mientras se trasladan los buzones.
• Merece la pena registrarse en Yahoo Sender Hub. Verifica tus dominios por DNS y después vigila el volumen entregado y las tasas de denuncias. Yahoo le dijo a Matthew que llegarán más datos.

Nuestra guía para arreglar la entregabilidad en Yahoo cubre las reglas que ahora se aplican a una parte creciente del correo de consumo de EE. UU. Matthew mencionó también un estándar propuesto para informar de la interacción, draft-brotman-aggregate-performance-reporting, que diría a los remitentes cuántos mensajes llegaron a la bandeja de entrada y cómo interactuaron los destinatarios. Según su experiencia, hoy solo Comcast envía esos informes, y lo dejó fuera de las diapositivas porque puede que no sobreviva a la migración.

El plan de entregabilidad para 2027 tiene cuatro pasos

Matthew cerró la sesión con un plan de cuatro pasos para 2027, y cada paso corresponde a uno de los cambios anteriores.

1. Audita el DNS para DMARCbis. Quita las etiquetas eliminadas, añade np=reject y confirma tu alineación. Después somete SPF, DKIM y DMARC a una revisión cada seis meses.
2. Pasa a la API de Postmaster Tools v2. Reconstruye todo lo que leía datos de la v1 y extrae de forma programada el porcentaje de mensajes que superan la baja y los diagnósticos de autenticación.
3. Mantén las denuncias por debajo del 0,1%, y nunca por encima del 0,3%. Si suben las denuncias o los rebotes, endurece tu política de sunset. Si usas un servicio de calentamiento automatizado, comprueba si Heatwave lista tus dominios.
4. Recalibra tus envíos para Yahoo y Comcast. Gestiona los códigos de rebote de Yahoo de la misma forma en todas partes y vigila de cerca los rebotes de Comcast mientras migran los buzones.

La ventana de sunset de 60 días de la diapositiva es un punto de partida para un programa que ya tiene problemas, no una regla. La respuesta de Matthew sobre la política de sunset, más abajo en el turno de preguntas, da el rango que usa de verdad.

Lo que preguntó el público en directo

El público envió diez preguntas durante la sesión. Estas son las respuestas de Matthew, resumidas.

¿Cuándo conviene actualizar un registro DMARC para DMARCbis?

Ya. Matthew recomienda una reunión de revisión del DNS cada seis meses para confirmar que SPF está al día, que las claves DKIM son las correctas y que la exigencia de DMARC sigue encajando. Un dominio que lleva cinco años en p=none con el trabajo hecho está listo para quarantine. Si tu próxima revisión es en enero, añade DMARCbis al orden del día.

¿Gmail filtra de forma distinta los dominios .edu?

No. Matthew no cree que Gmail trate un dominio de forma distinta por su dominio de nivel superior. Gmail juzga el rendimiento pasado, así que más correo en spam suele significar que los destinatarios ya no lo quieren o no lo encuentran relevante. El contenido decide la pestaña: una rebaja de la librería de un campus con precios y descuentos se lee como promocional y acaba en Promociones.

¿Por qué Postmaster Tools muestra errores de baja en un clic si la tengo implementada?

El error suele significar que el correo sigue llegando a alguien que ya se dio de baja. Gmail espera que una baja surta efecto en 48 horas, y las causas habituales son varias listas o plataformas que no comparten las supresiones, o correo transaccional enviado desde otra plataforma a personas que se dieron de baja. Los informes agregados de DMARC muestran todas las plataformas que envían en nombre de tu dominio, y así se encuentra el flujo que nadie tenía controlado. En la experiencia de Matthew, casi siempre es una plataforma de terceros que el equipo no sabía que estaba enviando.

¿El email transaccional está exento de las reglas de baja de Gmail?

No. Los filtros de spam no distinguen el correo transaccional del de marketing: ven un mensaje con contenido. Si el correo transaccional recibe denuncias o intentos de baja, probablemente lleva contenido promocional, o los destinatarios lo denuncian como spam porque no tiene enlace de baja. Canadá deja clara la frontera: la ley canadiense distingue entre mensajes comerciales y no comerciales, sin nada intermedio, así que un mensaje transaccional con un anuncio dentro es comercial.

¿Se puede enviar demasiado email transaccional?

Sí, cuando el destinatario se ha dado de baja del marketing. El ejemplo de Michaela fue una sola compra que generó cinco emails, desde la confirmación del pedido hasta una petición de reseña. Para Matthew, una petición de reseña puede contar como comercial, porque la marca se beneficia de la reseña. Cuando alguien se da de baja, envía solo correo estrictamente transaccional, como el aviso de envío, y prescinde de la venta cruzada.

¿Cuánto debe durar una política de sunset?

Depende de la frecuencia con la que envías. Para un remitente diario, Matthew sugiere unos 30 días sin interacción, lo que da a un suscriptor 30 oportunidades de responder. Para un remitente mensual, dos años pueden ser razonables. Las visitas a la web, los inicios de sesión, el uso de la app y una suscripción de pago cuentan como interacción, y un suscriptor que paga debería seguir recibiendo correo. Sesenta días es el punto de partida agresivo que usa cuando un programa tiene problemas de entrega, 120 días es más realista para la mayoría de las marcas, y la ventana puede volver a ampliarse una vez resueltos los problemas.

¿Se verán los logotipos BIMI para los usuarios de Comcast?

Sí. Cuando el buzón de un usuario de Comcast haya pasado a la web o a la app móvil de Yahoo, Matthew espera que se aplique la visualización de BIMI de Yahoo. Un remitente con BIMI configurado debería empezar a ver ahí su logotipo.

¿Hay que cambiar los registros DKIM o DMARC de un dominio de Google Workspace con años de antigüedad?

DMARC sí y DKIM no, de momento. DMARCbis cambia las etiquetas, así que revisa tu registro y quita o añade etiquetas según haga falta; un proveedor de DMARC que gestione tu registro debería encargarse de la actualización. En DKIM, los proveedores firmarán con DKIM2 usando tu clave actual, y Matthew no espera cambios en el DNS hasta que DKIM2 sea un estándar formal. Si tu registro DKIM es un CNAME hacia tu proveedor, el proveedor puede actualizarlo más adelante con poco esfuerzo por tu parte.

¿Caer en spam perjudica la interacción?

Sí. La mayoría de la gente rara vez abre su carpeta de spam, así que el correo que llega ahí recibe poca interacción, y esa falta de interacción lo mantiene ahí. Tampoco genera denuncias, porque un destinatario no puede denunciar como spam un mensaje que ya está en spam. Un programa casi sin denuncias y con malos resultados debería comprobar dónde está llegando su correo.

¿La ley canadiense exige un enlace de baja en el email transaccional?

Según la ley antispam de Canadá (CASL), un mensaje puramente transaccional, como un recibo electrónico, no necesita consentimiento, pero sí necesita los demás elementos, incluida una opción de baja. Esa baja se aplica después al futuro correo comercial. Los mensajes personales y la correspondencia comercial continuada están exentos por completo. Matthew no había visto ningún caso por falta de baja en correo transaccional, pero citó dos recientes por enviar correo a personas que se habían dado de baja: un compromiso de $500,000 y $200,000 de una bolsa de empleo. Según sus cuentas, se recaudaron $700,000 en seis semanas, así que una lista de supresión que no se conserva es un riesgo real para cualquiera que envíe correo a Canadá.

Prueba los cambios antes de tu próxima campaña

Cada uno de estos cambios se refleja en las cabeceras y en los resultados de autenticación de un mensaje real. Envía uno al comprobador de spam de Unspam.email antes de tu próxima campaña: informa de los resultados de SPF, DKIM y DMARC, de las cabeceras List-Unsubscribe y de una puntuación de spam en un solo test. Si tu programa necesita ayuda práctica, los consultores de entregabilidad de Unspam.email trabajan con remitentes en auditorías y correcciones.

La página de webinars de Unspam.email tiene los detalles de esta sesión y de las siguientes. La anterior, con Matthew Vernhout y Lawrence Heslin, está resumida en Inbox for the Holidays.

Sobre los ponentes

Matthew Vernhout es asesor de email en Email Industries, con sede en Toronto. Presentó la sesión y respondió a las preguntas del público.

Michaela Barriga trabaja en marketing en Email Industries y moderó la sesión.

El webinar lo organizó Unspam.email junto con Email Industries.