Garantir 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 provocar limitaciones, rechazos o que los mensajes sean enviados directamente a spam.
Las claves de la entregabilidad del email en 20 segundos
- Gmail considera remitente masivo a quien envía aproximadamente 5.000 mensajes o más en 24 horas a cuentas personales de Gmail.
- SPF, DKIM y DMARC ya son requisitos técnicos básicos para grandes remitentes.
- Google recomienda mantener la tasa de spam por debajo del 0,1 % y no superar el 0,3 %.
- Yahoo además exige bajas sencillas y que se procesen en un máximo de dos días.
- IP, DNS, reputación y separación de tráfico son tan importantes como el contenido.
Este cambio no ocurrió de la noche a la mañana. Gmail endureció en 2024 los requisitos para grandes remitentes y desde noviembre de 2025 ha intensificado las medidas contra el tráfico que incumple las reglas. Google advierte que los mensajes afectados pueden sufrir rechazos temporales, definitivos o terminar en spam.
En la práctica, operar una plataforma de envío masivo de correos se asemeja cada vez más a gestionar una infraestructura de red. Es necesario 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 denuncia esos correos como spam.
Gmail establece las 5.000 entregas diarias como una frontera clave
Google define como remitente masivo a quien envía aproximadamente 5.000 mensajes o más en 24 horas a cuentas personales de Gmail.
Esta medición no se realiza de manera aislada por subdominio.
Por ejemplo, si una organización envía 2.500 correos desde empresa.com y otros 2.500 desde marketing.empresa.com, Google los suma porque ambos pertenecen al mismo dominio principal. Una vez que un dominio alcanza esta condición, Gmail indica que la clasificación es permanente.
Esto tiene implicaciones técnicas importantes.
Para los grandes remitentes, Gmail exige SPF y DKIM, además de publicar una política DMARC. Esta puede comenzar con p=none, pero debe existir.
Además, requiere registros DNS válidos tanto para los servidores directos como para los inversos, transmisión mediante TLS y que los mensajes cumplan con RFC 5322.
Un aspecto que suele generar confusión es que DMARC no consiste simplemente en crear un registro TXT en DNS.
Para que un mensaje pase la validación DMARC, el dominio que aparece en la cabecera From: debe estar alineado con un identificador autenticado mediante SPF o DKIM. Esta relación entre la identidad visible y la autenticación es lo que dificulta las suplantaciones de dominios.
El RFC 9989, publicado en mayo de 2026, formaliza la especificación actual de DMARC, reemplazando a RFC 7489 y RFC 9091. Este documento forma parte del Standards Track del IETF.
También se publicaron el RFC 9990 para informes agregados de DMARC y el RFC 9991 para informes de fallos, separando en documentos específicos funciones que antes estaban dentro de una misma especificación.
Un 0,3 % de spam ya es demasiado
La reputación no se evalúa únicamente comprobando si el mensaje ha sido autenticado técnicamente.
Gmail presta especial atención a las denuncias de los usuarios.
Google recomienda mantener la tasa de spam reportado en Postmaster Tools por debajo del 0,1 % y evitar que alcance o supere el 0,3 %. Incluso superar el 0,1 % puede afectar negativamente la entrega en la bandeja de entrada.
Esta cifra ayuda a contextualizar el problema.
Por ejemplo, con 100.000 mensajes entregados, un 0,1 % equivaldría a 100 denuncias de spam y un 0,3 % a 300.
Por ello, una lista de correo correctamente configurada puede acabar viendo deteriorada su reputación si contiene demasiado usuarios que ya no esperan esos mensajes.
Google calcula este indicador diariamente y advierte que los remitentes masivos con tasas superiores al 0,3 % podrían quedar fuera de los mecanismos de mitigación. Para volver a ser considerados confiables, deben mantenerse por debajo de ese umbral durante siete días consecutivos.
La conclusión para cualquier infraestructura de email es sencilla: autenticación y reputación son aspectos diferentes.
Aunque se tengan configurados correctamente SPF, DKIM y DMARC, los mensajes pueden acabar en spam si los destinatarios los denuncian repetidamente.
Yahoo adopta una política similar
Yahoo aplica criterios similares a los de Google.
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, registros DNS directos e inversos, y cumplimiento con RFC 5321 y RFC 5322.
Además, establece una tasa de spam inferior al 0,3 %.
Otro aspecto clave es el tratamiento de las bajas.
Para correos de marketing y suscripción, Yahoo requiere ofrecer un mecanismo sencillo de cancelación, incluyendo el encabezado List-Unsubscribe, y que estas solicitudes se procesen en un máximo de dos días.
Gmail también exige que los correos promocionales contengan una opción de baja con un clic.
Este requisito no aplica a correos transaccionales, como restablecimientos de contraseña, confirmaciones o notificaciones que derivan de una acción del usuario.
El mecanismo técnico está definido en RFC 8058, que especifica que los mensajes deben incluir encabezados List-Unsubscribe y List-Unsubscribe-Post con una URL HTTPS donde el proveedor pueda enviar una petición POST para cancelar la suscripción sin que el usuario tenga que navegar por varias páginas.
La reputación de una IP sigue siendo relevante
La popularización de SPF, DKIM y DMARC no ha eliminado uno de los elementos tradicionales de la entregabilidad: la dirección IP de origen.
Los proveedores de correo evalúan tanto los dominios como la infraestructura de envío.
Una IP nueva que empieza a enviar cientos de miles de correos de forma repentina no tiene el mismo historial que otra que mantiene un volumen estable con pocas denuncias y bajas correctamente gestionadas.
Por eso aún se utiliza el proceso de calentamiento o warm-up de IP.
No existe una fórmula mágica que garantice una buena reputación automáticamente. El principio es comenzar con volúmenes controlados, dirigidos a destinatarios que probablemente interactúen positivamente, y aumentar paulatinamente el tráfico sin saltos difíciles de justificar.
La estabilidad es clave.
Google recomienda incrementar gradualmente el volumen cuando cambia el patrón de envío y advierte que un aumento repentino puede causar problemas de entrega. Además, insiste en enviar volúmenes que los destinatarios esperarían recibir.
Esto hace que la planificación de capacidad en email sea similar a gestionar cualquier otra infraestructura.
Cambiar de proveedor, inaugurar una nueva IP o mover miles de correos a otro pool no debería hacerse solo como una decisión comercial; requiere gestión y planificación cuidadosas.
Separar marketing y correos transaccionales reduce riesgos
Una decisión estratégica muy útil es dividir diferentes tipos de tráfico.
Un correo para restablecer contraseñas tiene una función distinta a 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 listas de suscripción y presenta mayor riesgo de bajas, falta de interacción o denuncias de spam.
Si ambos tipos de correos comparten la misma infraestructura, un deterioro en campañas comerciales puede afectar a mensajes mucho más sensibles.
La separación puede hacerse mediante dominios o subdominios de envío, identificadores DKIM diferenciados y, en infraestructura de mayor tamaño, pools de IP distintos.
No obstante, dividir el tráfico no garantiza automáticamente una mejor reputación; los proveedores también consideran señales globales. Sin embargo, la separación facilita detectar rápidamente si un aumento en rebotes o denuncias proviene de newsletters, campañas comerciales o correos transaccionales.
La lista negra no es la única métrica que hay que monitorear
Las listas de bloqueo siguen siendo una herramienta habitual, pero reducir toda la entregabilidad a verificar si una IP está en una blacklist es una visión incompleta.
Cada proveedor usa sus propios sistemas de evaluación y filtrado de reputación.
Una IP puede no aparecer en una lista pública y, sin embargo, tener mala reputación en Gmail o Yahoo. Igualmente, puede figurar en listas cuya influencia real sea limitada.
Por ello, la monitorización debe integrar varias fuentes.
Para Gmail, Postmaster Tools proporciona datos sobre reputación, autenticación, spam y cumplimiento de normas. Además, tiene un panel específico de Compliance status para verificar si el dominio cumple con sus políticas.
Los informes agregados de DMARC ofrecen otra visión, permitiendo identificar qué IPs envían en nombre de un dominio y verificar resultados de SPF y DKIM.
A esto se pueden sumar métricas propias de rebotes, bajas y denuncias.
El objetivo no es tener un panel lleno de indicadores, sino detectar pronto cambios en señales que normalmente son estables.
DMARC no reemplaza a SPF ni DKIM
Una confusión frecuente es pensar que SPF, DKIM y DMARC son mecanismos equivalentes.
No lo son.
SPF permite al propietario de un dominio publicar qué servidores están autorizados a enviar correos en su nombre.
DKIM añade una firma criptográfica que permite verificar que partes del mensaje no han sido modificadas y que la firma corresponde al dominio indicado.
DMARC evalúa los resultados de esas autenticaciones y verifica su alineación con el dominio visible en la cabecera del mensaje.
RFC 9989 define un resultado válido de DMARC cuando existe una política para el dominio autor y al menos un identificador autenticado está correctamente alineado.
Esto es especialmente importante cuando intervienen plataformas de marketing, CRM, sistemas de soporte, facturación o proveedores externos.
Una organización puede tener múltiples aplicaciones enviando correos desde su dominio. Cada una debe estar correctamente integrada en la política de autenticación.
Los informes DMARC resultan útiles para descubrir servidores legítimos que aún no estaban documentados, y también detectar intentos de suplantación.
2026: la entregabilidad como disciplina operacional
El cambio principal no radica solo en reglas particulares de Gmail o Yahoo.
El gran cambio es que el email comercial está convirtiéndose en una infraestructura que requiere gobernanza técnica constante.
Es necesario gestionar dominios, DNS, IP, TLS, claves DKIM, políticas DMARC, informes, listas de suscripción, bajas, rebotes y reputación. Cualquier cambio de proveedor puede afectar varias de estas piezas simultáneamente.
Una campaña puede tener un diseño impecable y una oferta atractiva, pero si la infraestructura que la soporta ha perdido confianza, poco resultado tendrá.
Por otro lado, una configuración técnica perfecta no garantiza que los correos no deseados se conviertan en correos deseados.
Google subraya que sus requisitos técnicos no sustituyen la necesidad de que los mensajes sean relevantes y deseados por los destinatarios.
En 2026, la entregabilidad se resume en: demostrar quién envía, hacerlo desde una infraestructura coherente y lograr 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 o más mensajes en 24 horas a cuentas personales de Gmail. Google suma los envíos desde el mismo dominio principal y mantiene esa clasificación de forma permanente una vez alcanzada.
¿Qué tasa de spam recomienda Gmail?
Mantenerla por debajo del 0,1 % y evitar que supere el 0,3 %. Tasas superiores a ese umbral ya pueden perjudicar la entrega en la bandeja de entrada.
¿Es obligatorio usar DMARC para enviar correo masivo?
Gmail y Yahoo requieren DMARC para sus remitentes masivos, aunque se puede empezar con p=none. Además, SPF, DKIM y la correcta alineación del dominio también son necesarios.
¿Qué cambios aportó DMARC en 2026?
En mayo de 2026 se publicó RFC 9989, que actualiza la especificación de DMARC, reemplazando a RFC 7489 y RFC 9091. También se complementan con los RFC 9990 y 9991 para informes.
Fuente: brandergroup