Conseguir que un correo llegue a la bandeja de entrada en 2026 depende cada vez menos del asunto perfecto y más de DNS, autenticación, reputación, tasas de spam y comportamiento del remitente. Gmail y Yahoo mantienen requisitos específicos para quienes envían grandes volúmenes, mientras que DMARC acaba de dar otro paso con la publicación del RFC 9989. Un dominio mal configurado o una IP con mala reputación puede traducirse en limitaciones, rechazos o mensajes enviados directamente a spam.

Las claves de la entregabilidad del email en 20 segundos

• Gmail considera remitente masivo a quien ronda los 5.000 mensajes diarios a cuentas personales desde un mismo dominio principal.
• SPF, DKIM y DMARC ya forman parte de los requisitos técnicos básicos para grandes remitentes.
• Google recomienda mantener la tasa de spam por debajo del 0,1 % y no alcanzar el 0,3 %.
• Yahoo exige además bajas sencillas y procesarlas en un máximo de dos días.
• IP, DNS, reputación y separación de tráfico importan tanto como el contenido.

El cambio no se produjo de un día para otro. Gmail endureció sus requisitos para grandes remitentes en 2024 y desde noviembre de 2025 ha aumentado la aplicación de medidas contra el tráfico que no cumple las reglas. Google advierte de que los mensajes afectados pueden sufrir rechazos temporales, permanentes o terminar en spam.

En la práctica, operar una plataforma de email masivo se parece cada vez más a mantener un servicio de red. Hay que conocer qué dominios envían, desde qué direcciones IP, cómo están configurados sus registros DNS, qué aplicaciones generan el tráfico y qué porcentaje de destinatarios está denunciándolo como correo no deseado.

Gmail convierte las 5.000 entregas diarias en una frontera importante

Google define como remitente masivo a quien envía aproximadamente 5.000 mensajes o más en 24 horas a cuentas personales de Gmail.

La cuenta no se realiza de manera aislada por subdominio.

Si una organización envía 2.500 correos desde empresa.com y otros 2.500 desde marketing.empresa.com, Google los suma porque pertenecen al mismo dominio principal. Una vez que un dominio alcanza la condición de remitente masivo, Gmail indica que la clasificación es permanente.

Eso tiene consecuencias técnicas.

Para los grandes remitentes, Gmail exige SPF y DKIM, además de publicar una política DMARC. Esta última puede comenzar incluso con p=none, pero tiene que existir.

También exige registros DNS directos e inversos válidos para los servidores o direcciones IP utilizadas en el envío, transmisión mediante TLS y mensajes que respeten RFC 5322.

Hay además un requisito que suele causar confusión: DMARC no consiste simplemente en crear un registro TXT en DNS.

Para que un mensaje pase DMARC, el dominio visible en el encabezado From: tiene que estar alineado con un identificador autenticado mediante SPF o DKIM. Es precisamente esa asociación entre identidad visible y autenticación lo que dificulta la suplantación de dominios.

El nuevo RFC 9989, publicado en mayo de 2026, formaliza la especificación actual de DMARC y sustituye al anterior RFC 7489 y al RFC 9091. El documento forma parte del Standards Track del Internet Engineering Task Force (IETF).

También llegaron el RFC 9990 para los informes agregados DMARC y el RFC 9991 para los informes de fallo, separando en documentos específicos algunas funciones que anteriormente se encontraban dentro de la misma especificación.

Un 0,3 % de spam ya es demasiado

La reputación tampoco se mide únicamente preguntando si el mensaje ha sido técnicamente autenticado.

Gmail presta especial atención a las denuncias de los usuarios.

Google recomienda mantener la tasa de spam mostrada en Postmaster Tools por debajo del 0,1 % y evitar que alcance el 0,3 % o más. Incluso superar el 0,1 % puede afectar negativamente a la entrega en bandeja de entrada.

La cifra pone el problema en perspectiva.

Con 100.000 mensajes entregados, un 0,1 % representaría 100 denuncias de spam. Alcanzar el 0,3 % supondría 300.

Esto explica por qué una lista de correo técnicamente correcta puede terminar deteriorando su reputación si contiene demasiados usuarios que ya no esperan esos mensajes.

Google calcula este indicador diariamente y señala que los remitentes masivos con tasas superiores al 0,3 % pueden quedar fuera de sus mecanismos de mitigación. Para volver a ser elegibles necesitan permanecer por debajo de ese límite durante siete días consecutivos.

La conclusión para cualquier infraestructura de email es sencilla: autenticación y reputación son problemas diferentes.

SPF, DKIM y DMARC pueden estar perfectamente configurados y, aun así, los mensajes pueden terminar en spam si los destinatarios los denuncian repetidamente.

Yahoo exige una arquitectura muy parecida

Yahoo aplica una política cercana a la de Google.

Para los remitentes masivos exige SPF y DKIM, una política DMARC válida con al menos p=none, alineación entre el dominio visible y SPF o DKIM, DNS directo e inverso y cumplimiento de los estándares RFC 5321 y RFC 5322.

También establece una tasa de spam inferior al 0,3 %.

Otro punto especialmente importante afecta a las bajas.

Los correos de marketing y suscripción deben ofrecer un mecanismo sencillo de cancelación, incluyendo List-Unsubscribe, y Yahoo pide que las solicitudes se procesen en un plazo máximo de dos días.

Gmail exige igualmente la baja con un clic en mensajes promocionales y de marketing enviados por remitentes masivos.

Este requisito no se aplica de forma general a correos puramente transaccionales como restablecimientos de contraseña, confirmaciones de reservas o determinadas notificaciones provocadas directamente por una acción del usuario.

El mecanismo técnico está definido en RFC 8058.

El mensaje incorpora los encabezados List-Unsubscribe y List-Unsubscribe-Post, con una URL HTTPS a la que el proveedor de correo puede enviar una petición POST para realizar la baja sin obligar al usuario a navegar por varias páginas.

La reputación de una IP sigue importando

La popularización de SPF, DKIM y DMARC no ha hecho desaparecer uno de los elementos clásicos de la entregabilidad: la dirección IP de origen.

Los proveedores de correo observan tanto dominios como infraestructura de envío.

Una IP nueva que comienza a transmitir cientos de miles de mensajes de forma repentina no presenta el mismo historial que otra que mantiene desde hace meses un volumen estable con pocas denuncias y bajas correctamente procesadas.

Por eso sigue utilizándose el denominado calentamiento o warm-up de IP.

No existe un calendario universal que garantice automáticamente una buena reputación. El principio consiste en comenzar con volúmenes controlados y destinatarios con mayor probabilidad de interactuar positivamente, aumentando posteriormente el tráfico sin producir saltos difíciles de justificar.

La estabilidad importa.

Google recomienda incrementar gradualmente el volumen cuando cambia el patrón de envío y advierte de que un aumento repentino puede generar problemas de entrega. Su propia documentación para remitentes insiste además en enviar volúmenes que los destinatarios esperen recibir.

Eso convierte la planificación de capacidad de email en algo bastante parecido a la operación de cualquier otra infraestructura.

Cambiar de proveedor, inaugurar una nueva IP o mover cientos de miles de correos a otro pool no debería abordarse únicamente como una modificación comercial.

Marketing y correo transaccional no deberían compartir todos los riesgos

Una de las decisiones arquitectónicas más útiles consiste en separar distintos tipos de tráfico.

Un correo para restablecer una contraseña tiene una función completamente diferente de una campaña promocional.

El primero suele ser solicitado explícitamente por el usuario y puede ser necesario para acceder a un servicio. El segundo depende de una lista de suscripción y presenta mayor riesgo de bajas, falta de interacción o denuncias de spam.

Si ambos comparten exactamente la misma infraestructura, un deterioro en las campañas comerciales puede afectar potencialmente a mensajes mucho más sensibles.

La separación puede realizarse mediante dominios o subdominios de envío, identificadores DKIM diferenciados y, en infraestructuras de cierto tamaño, pools de IP distintos.

No implica que dividir el tráfico elimine automáticamente los problemas reputacionales. Google agrega determinados criterios al dominio principal para clasificar a los remitentes masivos, y los proveedores pueden relacionar diferentes señales de una misma organización.

Pero la separación operativa facilita algo básico: saber qué aplicación está generando cada comportamiento.

Si aumenta el volumen de rebotes o denuncias, debería ser posible identificar rápidamente si proceden de newsletters, campañas comerciales, notificaciones o correo transaccional.

Una blacklist no es la única señal que debe vigilarse

Las listas de bloqueo continúan siendo una herramienta utilizada dentro del ecosistema de correo, pero reducir toda la entregabilidad a comprobar si una IP aparece en una blacklist ofrece una visión incompleta.

Cada proveedor utiliza sus propios sistemas de reputación y filtrado.

Una IP puede no figurar en una determinada lista pública y, aun así, tener mala reputación dentro de Gmail o Yahoo. También puede aparecer en una lista cuya influencia real sobre los principales proveedores sea pequeña.

Por eso la monitorización debería reunir varias fuentes.

Para Gmail, Postmaster Tools ofrece información sobre reputación, autenticación, spam y cumplimiento de requisitos. Google ha incorporado además un panel específico de Compliance status para comprobar si el dominio satisface sus directrices.

Los informes agregados de DMARC aportan otra perspectiva: permiten conocer qué direcciones IP están enviando correo en nombre de un dominio y comprobar los resultados de SPF y DKIM.

A ello pueden añadirse métricas propias sobre rebotes, bajas y denuncias.

El objetivo no debería ser conseguir un panel lleno de indicadores, sino detectar pronto cuándo cambia una señal que normalmente permanece estable.

DMARC no sustituye a SPF ni DKIM

Una confusión frecuente consiste en tratar SPF, DKIM y DMARC como tres mecanismos equivalentes.

No lo son.

SPF permite que el propietario de un dominio publique qué servidores están autorizados para enviar correo en su nombre.

DKIM añade una firma criptográfica al mensaje para que el receptor pueda comprobar que determinadas partes no han sido modificadas y que la firma corresponde al dominio indicado.

DMARC utiliza los resultados de esas autenticaciones y comprueba su alineación con el dominio utilizado como autor visible del mensaje.

RFC 9989 define un resultado DMARC válido cuando existe una política para el dominio autor y al menos un identificador autenticado se encuentra correctamente alineado.

Esto importa especialmente cuando intervienen plataformas de marketing, CRM, herramientas de soporte, sistemas de facturación o proveedores externos.

Una empresa puede tener diez aplicaciones diferentes enviando correo desde su dominio. Cada una tiene que integrarse correctamente en la política de autenticación.

Los informes DMARC resultan útiles precisamente porque permiten descubrir servidores que todavía están enviando legítimamente pero que nadie había documentado, además de posibles intentos de suplantación.

2026 convierte la entregabilidad en una disciplina de operaciones

El cambio más importante no está en una única regla de Gmail o Yahoo.

Está en que el email comercial se está convirtiendo en una infraestructura que exige gobierno técnico continuo.

Hay que gestionar dominios, DNS, IP, TLS, claves DKIM, políticas DMARC, informes, listas de suscriptores, bajas, rebotes y reputación. Y cualquier cambio de proveedor puede alterar varias de esas piezas a la vez.

Una campaña puede tener un diseño impecable y una oferta atractiva y no servir de mucho si la infraestructura que la transporta ha perdido la confianza del receptor.

También ocurre lo contrario: una configuración perfecta no convierte correo no solicitado en correo deseado.

Google insiste precisamente en esta diferencia. Sus requisitos técnicos no sustituyen la necesidad de enviar mensajes que los destinatarios quieran recibir.

La entregabilidad en 2026 puede resumirse así: demostrar quién envía, hacerlo desde una infraestructura coherente y conseguir que los usuarios no quieran denunciar ese correo como spam.

Todo lo demás empieza después.

Preguntas frecuentes

¿Cuándo considera Gmail que un dominio es un remitente masivo?

Cuando envía aproximadamente 5.000 mensajes o más en 24 horas a cuentas personales de Gmail. Google suma los envíos realizados desde el mismo dominio principal y mantiene permanentemente la clasificación una vez alcanzada.

¿Qué tasa de spam recomienda Gmail?

Google recomienda mantenerse por debajo del 0,1 % y evitar alcanzar el 0,3 %. Las tasas superiores al 0,1 % ya pueden perjudicar la entrega en bandeja de entrada.

¿Es obligatorio utilizar DMARC para enviar correo masivo?

Gmail y Yahoo requieren DMARC para sus categorías de remitentes masivos. Ambas plataformas permiten comenzar con una política p=none, aunque SPF, DKIM y la alineación del dominio también deben estar correctamente configurados.

¿Qué cambió con DMARC en 2026?

En mayo de 2026 se publicó RFC 9989, la nueva especificación DMARC dentro del Standards Track de la IETF. Sustituye a RFC 7489 y RFC 9091 y se complementa con los RFC 9990 y 9991 para los informes.

Fuente: brandergroup