Requisitos de Gmail y Yahoo para remitentes en 2026: qué se aplica de verdad

Los requisitos de Gmail y Yahoo para remitentes masivos entraron en vigor el 1 de febrero de 2024, y durante la mayor parte de ese primer año omitirlos significaba peor ubicación, no correo bloqueado. Esa tregua terminó. Desde noviembre de 2025, Gmail rechaza el tráfico no conforme en la capa SMTP, lo que significa que los requisitos ahora aparecen en su registro de rebotes en lugar de en su tasa de apertura.

Este es un chequeo de situación para 2026: cuáles son las reglas, cómo se ve realmente la aplicación en el protocolo y qué verificar en sus propios dominios hoy.

Los requisitos, en una tabla

Las pautas para remitentes de correo de Google y el Yahoo Sender Hub convergieron en reglas casi idénticas. Dos niveles:

Requisito	A quién aplica
Autenticación SPF o DKIM	Todos
Registro PTR válido (el DNS directo y el inverso coinciden)	Todos
TLS en la conexión de envío	Todos
Tasa de spam por debajo del 0.3%, idealmente por debajo del 0.1%	Todos
SPF y DKIM, ambos aprobando	Remitentes masivos
Registro DMARC, al menos p=none, con un dominio From alineado	Remitentes masivos
Baja en un clic (RFC 8058) más un enlace visible en el cuerpo	Remitentes masivos, correo de marketing
Bajas procesadas en un plazo de 2 días	Remitentes masivos

Un remitente masivo es cualquiera que envíe cerca de 5000 mensajes o más hacia cuentas personales de Gmail en un período de 24 horas. Dos detalles de las preguntas frecuentes de las pautas para remitentes de Google que la mayoría de los resúmenes omite: la condición de remitente masivo no tiene fecha de vencimiento, un solo día que califique marca al dominio de forma permanente, y las reglas aplican solo al correo enviado a cuentas personales de Gmail, no a destinatarios de Google Workspace. Yahoo especifica además una clave DKIM mínima de 1024 bits.

El registro DMARC mínimo que satisface a ambos proveedores es una línea:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

El generador de DMARC construye este registro con una dirección de reportes, y el requisito de alineación, que su dominio From coincida con el dominio que SPF o DKIM validaron, es la parte que conviene probar en lugar de suponer.

Cómo se aplica en 2026

Durante 2024 y la mayor parte de 2025, un remitente que omitía los requisitos veía sobre todo una degradación silenciosa: llegada a la carpeta de spam y daño lento de reputación. Las preguntas frecuentes de Google ahora lo declaran abiertamente: desde noviembre de 2025, los mensajes no conformes “experimentarán interrupciones, incluidos rechazos temporales y permanentes”.

En el protocolo, el rechazo permanente para correo sin autenticar es 550 5.7.26:

550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF [example.com] with ip: [203.0.113.25] = did not pass
550 5.7.26 For instructions on setting up authentication, go to
550 5.7.26 https://support.google.com/mail/answer/81126#authentication

Léanlo de abajo hacia arriba: el mensaje nombra el dominio y la IP que evaluó, y cuál de las dos comprobaciones falló. Que ambas fallen suele significar un registro faltante; que una falle suele significar un proveedor que envía en su nombre sin alineación. Las preguntas frecuentes de Gmail también documentan una familia de códigos temporales 4.7.x que limitan la tasa del tráfico sospechoso en lugar de rechazarlo; 4.7.28, por ejemplo, es una cuota de volumen sobre una IP, un dominio o una clave DKIM con comportamiento problemático. Una demora 4xx se reintenta; tomen una tasa creciente de ellas como la advertencia antes del 5xx.

La aplicación de Yahoo se apoya en la demora. La cadena que los remitentes ven, documentada en los códigos de error SMTP de Yahoo, es la demora TSS04:

421 4.7.0 [TSS04] Messages from 203.0.113.25 temporarily deferred due to
unexpected volume or user complaints - 4.16.55.1;
see https://postmaster.yahooinc.com/error-codes

Las dos causas nombradas son el diagnóstico: o el volumen saltó de una forma que Yahoo no reconoce para esa IP, o los destinatarios están marcando el botón de spam. Reintentar con más fuerza empeora ambas.

La acción: busquen 5.7.26, 4.7. y TSS04 en sus registros de rebotes de los últimos 30 días. Si su plataforma oculta los rebotes crudos, la lista de supresión es el recurso de respaldo, y cualquier entrada con fecha posterior a noviembre de 2025 y redacción de autenticación merece una revisión.

El límite del 0.3% de tasa de spam en la práctica

Ese número se mide en Google Postmaster Tools, y es más estricto de lo que parece. La expectativa declarada de Google es mantenerse por debajo del 0.1% y nunca llegar al 0.3%. La consecuencia de cruzarlo cambió en junio de 2024: un dominio en o por encima del 0.3% deja de ser elegible para mitigación, es decir, el soporte de Google no intervendrá en un problema de entrega hasta que la tasa se mantenga por debajo del 0.3% durante 7 días consecutivos. El umbral no es solo una entrada del filtro; es la línea de elegibilidad para recibir ayuda.

Yahoo publica el mismo techo del 0.3% con un detalle que vale la pena conocer: su tasa se calcula sobre el correo entregado en la bandeja de entrada. El correo que ya cayó en spam no puede generar quejas, así que un remitente puede ver la tasa medida mejorar mientras la ubicación colapsa: el denominador se encoge, no el problema.

Una sola campaña hacia un segmento desactualizado puede gastar todo el presupuesto: el 0.3% son tres quejas por cada mil entregados. La acción es un piso, no un techo: abran Postmaster Tools, revisen la gráfica de tasa de spam de los últimos 90 días y, si hay algún pico, comparen su fecha contra su registro de envíos antes de que salga la próxima campaña.

Baja en un clic: dónde siguen fallando las implementaciones

El requisito, obligatorio para el correo masivo de marketing desde el 1 de junio de 2024, es el RFC 8058, y es un par de encabezados, no un enlace:

List-Unsubscribe: <https://example.com/u?t=8f3ac91>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Las trampas que todavía hacen fallar a remitentes en 2026:

• Un enlace en el pie no es el mecanismo. Los encabezados son lo que Gmail muestra como su propio botón de baja en la parte superior del mensaje. Las preguntas frecuentes de Google son explícitas: los enlaces que usan solo mailto y los de URL simple no satisfacen el requisito. El enlace visible en el cuerpo se exige además, no en su lugar.
• El endpoint debe aceptar un POST sin pasos humanos. Una página de “administrar preferencias” que exige inicio de sesión o un clic de confirmación no cumple la definición de un solo clic.
• El reloj es de 2 días. Ambos proveedores exigen que la baja se procese en un plazo de dos días. Una sincronización semanal de su ESP a su CRM no llega.
• El correo transaccional está exento, y etiquetar marketing como transaccional para saltarse el botón es justo el tipo de cosa que las tasas de quejas exponen por sí solas.

La acción: envíen su última campaña a un buzón que controlen y lean los encabezados crudos; ambas líneas List-Unsubscribe deben estar presentes, y el analizador de encabezados las muestra junto con los resultados de autenticación en una sola pasada.

Microsoft ahora aplica el mismo manual

El tercer gran proveedor de buzones se sumó en 2025. Desde el 5 de mayo de 2025, Microsoft exige SPF, DKIM y un registro DMARC alineado a los dominios que envían más de 5000 mensajes al día a direcciones de Outlook.com, Hotmail y Live, y rechaza el correo no conforme con su propio código permanente, recorrido en la guía del 550 5.7.515 en Outlook:

550 5.7.515 Access denied, sending domain example.com does not
meet the required authentication level.

La consecuencia práctica: ya no existe una bandeja de entrada grande de consumo donde el correo masivo sin autenticar se limite a filtrarse. Los mismos tres registros satisfacen a los tres proveedores, así que un dominio que aprueba para Gmail aprueba para Outlook, siempre que la alineación se mantenga. Si la colocación en Outlook es su problema específico, el orden de diagnóstico difiere del de Gmail y está cubierto en la guía de colocación en spam.

Qué verificar en sus dominios hoy

Verificar el cumplimiento una vez toma unos diez minutos con un chequeo de salud de dominio: lee SPF, DKIM y DMARC juntos e informa si la alineación realmente se sostiene, que es el modo de falla al que las cadenas de rebote de arriba siguen apuntando.

La trampa es que el cumplimiento no es un estado que se alcanza, es un estado que se desvía. Los requisitos atan registros que otras personas editan: un proveedor integrado por marketing agrega un include, una migración de DNS elimina un registro _dmarc, una plataforma rota un selector DKIM. Cada uno de esos cambios es silencioso, y desde noviembre de 2025 el modo de falla del silencio es correo rechazado en lugar de un deslizamiento lento. Un chequeo puntual responde la pregunta de hoy para un dominio; no tiene memoria de cómo se veían los registros antes del cambio, que es exactamente la información que un pico de rechazos vuelve urgente. LitInboxes vuelve a ejecutar estos chequeos en cada dominio monitoreado cada seis horas, conserva el historial con fechas que convierte “los rebotes empezaron la semana pasada” en “el selector DKIM desapareció un martes”, vigila las señales de tasa de spam y reputación, y envía los cambios por correo, Slack, Discord o un webhook. Hay un recorrido aquí si quieren verlo sobre un dominio real.

La lista de verificación

1. Confirmen que SPF y DKIM aprueban para cada plataforma que envía como su dominio, no solo la principal.
2. Confirmen que existe un registro DMARC con p=none como mínimo, con los reportes rua activados, y que su dominio From se alinea con SPF o DKIM.
3. Busquen 5.7.26, 4.7. y TSS04 en los rebotes de los últimos 30 días.
4. Lean la tasa de spam en Postmaster Tools contra la meta del 0.1% y el techo del 0.3%, de los últimos 90 días.
5. Envíense una campaña y confirmen que ambos encabezados List-Unsubscribe están presentes y que el endpoint acepta un POST sin pasos adicionales.
6. Confirmen que las bajas llegan a su plataforma de envío en un plazo de 2 días, no en una sincronización semanal.
7. Confirmen que la IP de envío tiene un registro PTR que resuelve de vuelta al mismo nombre de host.
8. Vuelvan a revisar después de cualquier cambio de DNS, incorporación de un proveedor o migración de plataforma, porque es ahí cuando los dominios conformes dejan de serlo en silencio.