Los requisitos para remitentes de Gmail y Yahoo, explicados
Por Thomas · CISO virtual · 2026-06-16
En febrero de 2024, Gmail y Yahoo convirtieron la autenticación del correo de una buena práctica en un billete de entrada. Los remitentes que no cumplen sus requisitos ven cómo su correo se ralentiza, acaba en spam o se rechaza. Para toda empresa que envía correos de marketing, boletines, recibos o notificaciones, las reglas han cambiado. Esta guía explica lo que se exige, a quién afecta y cómo cumplir con la normativa — y por qué cumplir es solo el suelo, no el techo.
Qué ha cambiado, y por qué
Gmail y Yahoo entregan cada uno a miles de millones de buzones: sus políticas fijan de facto el estándar de todo el sector. Cansados de soportar el coste del correo no autenticado y abusivo, se alinearon en torno a una base común de requisitos para los remitentes masivos — y empezaron a hacerlos cumplir. En resumen: quien envía en volumen tiene que demostrar quién es con SPF, DKIM y DMARC, o su correo no llegará de forma fiable.
A quién afecta
Las reglas más estrictas apuntan a los remitentes masivos — definidos por Google como quienes envían alrededor de 5000 mensajes o más al día a direcciones de Gmail. Yahoo emplea un lenguaje similar, sin una cifra pública firme. Algunos puntos que conviene entender:
- El umbral se refiere al volumen dirigido a sus usuarios, y una vez cruzado, ambos proveedores tratan al remitente como masivo de forma casi permanente.
- Se mide a escala del dominio: todos los envíos — marketing, transaccional, herramientas internas — cuentan juntos.
- Incluso por debajo del umbral, las expectativas básicas (autenticar el correo, no hacer spam) se aplican cada vez más. La hipótesis segura hoy: todo remitente serio necesita SPF, DKIM y DMARC.
Los requisitos, punto por punto
Para los remitentes masivos, la lista de comprobación común es:
- SPF y DKIM ambos configurados para el dominio de envío — no uno u otro. DKIM en particular debe ser válido y firmar el correo.
- Un registro DMARC publicado, como mínimo
p=none. Es el requisito explícito y nombrado que pilló por sorpresa a muchos equipos: sin registro DMARC = no conforme. - La alineación — el dominio del
From:debe alinearse con SPF o DKIM. Una configuración que pasa pero sin alineación no satisface DMARC y, por tanto, tampoco el requisito. (Si «alineación» resulta confuso, conviene mirar cómo funcionan juntos SPF, DKIM y DMARC.) - Cancelación de suscripción en un clic (RFC 8058) en el correo de marketing, atendida en un plazo de dos días.
- Una tasa baja de quejas por spam — por debajo del 0,3 %, idealmente muy por debajo del 0,1 %.
- Un DNS inverso (PTR) confirmado para las IP de envío, y TLS para el transporte.
Los puntos 1 a 3 son el núcleo de la autenticación del correo, y ahí es donde se esconde la mayor parte del incumplimiento. La buena noticia: es exactamente lo que había que hacer de todos modos.
«Tenemos un registro DMARC» no es la línea de meta
Muchos equipos reaccionaron al plazo de 2024 publicando un simple p=none y dando el asunto por cerrado. Eso respeta la letra del requisito — pero vale la pena entender lo que aporta y lo que no.
p=none significa solo monitorización. Satisface el mínimo de Gmail y Yahoo, y pone en marcha el flujo de informes agregados necesario para avanzar. Pero no ofrece ninguna protección contra la suplantación de identidad: alguien que falsifique el dominio sigue llegando a los buzones, ya que el registro les ha dicho a los destinatarios que no hagan nada cuando algo falle. Cumplir en p=none es el suelo, no el objetivo.
La verdadera meta es p=reject, donde el correo no autenticado enviado en nombre del dominio se rechaza de verdad. Es a la vez mejor seguridad y mejor señal de entregabilidad — los proveedores confían más en los dominios que aplican una política. El camino para llegar es la misma secuencia disciplinada, independientemente del plazo de cumplimiento: inventariar las fuentes, alinearlas y luego subir la política. Lo desarrollamos en alcanzar p=reject sin romper el correo legítimo.
Cómo cumplir (y luego protegerse)
Un orden de operaciones práctico:
- Comprobar el punto de partida. Nuestro analizador DMARC gratuito dice si SPF, DKIM y DMARC existen y se alinean — y da una nota. En unos segundos queda claro si el dominio pasaría los controles de Gmail/Yahoo.
- Corregir lo básico. Publicar un SPF que liste las fuentes reales; activar la firma DKIM en cada plataforma; publicar un registro DMARC con una dirección
rua=para arrancar los informes. - Leer los informes. Revelan cada fuente que emite en nombre del dominio — las que hay que alinear antes de endurecer.
- Alinear cada fuente legítima, luego subir la política de
noneaquarantiney después areject. - Mantener la higiene — cancelación en un clic, tasas de quejas bajas, listas limpias. La autenticación abre la puerta; el comportamiento mantiene dentro. Toda esa vertiente de reputación y engagement se aborda en profundidad en nuestra guía de entregabilidad en Gmail.
¿Y Microsoft? (2025)
Gmail y Yahoo abrieron el camino; Microsoft siguió en 2025. El proveedor de Outlook.com, Hotmail y Live.com anunció que, a partir de mayo de 2025, los remitentes de gran volumen (de nuevo en torno a 5000 mensajes/día o más hacia sus buzones de consumo) deben publicar también SPF, DKIM y DMARC alineados. Al principio, el correo no conforme se enruta a la carpeta de spam en lugar de rechazarse — una fase de tolerancia antes de un endurecimiento anunciado. El mensaje es claro: los tres grandes proveedores de consumo convergen ahora hacia la misma base de autenticación, y apuntar solo a Gmail/Yahoo sería miope. Desgranamos el calendario y los criterios precisos de Outlook en un artículo dedicado.
La buena noticia es que no hay nada más que hacer. La lista de comprobación es idéntica: SPF + DKIM válidos, un registro DMARC (como mínimo p=none, siendo el objetivo p=reject), y sobre todo la alineación del dominio del From:. Un dominio que satisface a Gmail y Yahoo correctamente satisface a Microsoft — siempre que no haya descuidado la alineación. Y como demostró el episodio de 2024, muchos equipos se creen conformes por tener solo «un registro DMARC», sin que sus fuentes se alineen de verdad. Un análisis gratuito despeja la duda en unos segundos.
Una nota para los sectores regulados
En las finanzas, la sanidad u otro sector regulado, las reglas de Gmail/Yahoo son solo una de las fuerzas que empujan en la misma dirección. Marcos como NIS2 y DORA elevan las exigencias en materia de controles operativos y antiphishing, y la autenticación del correo es un control evidente y auditable que se puede presentar. Conviene tratar los requisitos para remitentes de 2024 como la punta visible de un movimiento más amplio: el DMARC aplicado se convierte en la base esperada, no en la excepción. La postura de sectores enteros se puede consultar en nuestro Observatorio DMARC.
Preguntas frecuentes
¿Los correos transaccionales cuentan para el umbral de 5000/día? Sí. Google cuenta todo el correo hacia usuarios de Gmail desde un mismo dominio — marketing, recibos, alertas, notificaciones internas — de forma conjunta. No hay exención transaccional, y la mayoría de los dominios subestiman su volumen real.
Enviamos menos de 5000/día. ¿Estamos exentos? De las reglas masivas más estrictas, por ahora. Pero las expectativas básicas — autenticarse con SPF y DKIM, publicar DMARC, mantener una tasa de quejas baja — se aplican cada vez más a todos, y cruzar el umbral aunque sea una vez pasa a tratamiento de «remitente masivo» de forma casi definitiva. El reflejo seguro: autenticarse sea cual sea el volumen.
¿Esto se aplica a los subdominios? Sí. Hay que autenticar cada subdominio realmente emisor, y ajustar la etiqueta DMARC sp (política de subdominio) para que los subdominios no queden abiertos a la suplantación mientras la raíz está bloqueada.
Pasamos por una plataforma compartida (Mailchimp, SendGrid…). ¿Estamos cubiertos? Solo con un DKIM alineado con el dominio propio configurado en esa plataforma. La firma por defecto de una plataforma compartida se alinea con la plataforma, no con el remitente: no satisface DMARC. La configuración correcta es el dominio de firma con marca propia que ofrece el proveedor — normalmente unos cuantos CNAME.
¿En cuánto tiempo hay que cumplir? Los requisitos ya se están aplicando. Cuando el correo se ralentiza o acaba en spam en Gmail o Yahoo, una autenticación débil o no alineada es lo primero que hay que revisar — el punto de partida es un análisis gratuito.
¿Y si ignoramos estos requisitos? Nada tan espectacular como un bloqueo inmediato, al principio: el correo primero se ralentiza (throttling), luego se dirige cada vez más a spam. La degradación es silenciosa y progresiva — las tasas de apertura se erosionan sin error visible — lo que la hace tanto más peligrosa cuanto que se diagnostica tarde. A igual volumen, un competidor autenticado aterriza en la bandeja de entrada mientras que un dominio sin autenticar no. Y cuando los mensajes ya aterrizan en spam, nuestra guía de diagnóstico paso a paso ayuda a remontar a la causa.
¿Estas reglas se aplican al correo hacia nuestros propios empleados? Si los equipos usan cuentas de Gmail, Yahoo u Outlook.com, sí — al proveedor no le importa la distinción interno/externo, solo quién recibe el mensaje. Los buzones alojados en el tenant propio siguen su filtrado, pero todo lo que llega a un buzón de consumo se juzga según estas reglas.
Thomas gestiona el camino
Satisfacer el requisito es rápido; alcanzar una protección real sin romper el flujo de correo es el verdadero trabajo — y es exactamente lo que automatiza Thomas, el CISO virtual. Encuentra cada fuente a partir de los informes, genera los registros SPF, DKIM y DMARC precisos que hay que publicar, y acompaña de un simple p=none hasta un p=reject seguro.
Análisis de dominio gratuito o crear una cuenta para cumplir y protegerse. ¿Primera visita? El punto de entrada es qué es DMARC.
Aplicar DMARC, en la práctica
Thomas, el CISO virtual de DMARC.com, identifica cada fuente de envío legítima, escribe los registros DNS exactos y lleva un dominio de p=none a p=reject — sin romper su correo.
Alcanzar p=reject — gratisGuías relacionadas
- Entregabilidad Gmail: la guía completa
Por qué los emails aterrizan (o no) en la pestaña Principal de Gmail. Autenticación, reputación, interacción: todo lo que determina la entregabilidad, explicado en detalle.
- Activar DKIM en Microsoft 365: la guía paso a paso
Microsoft 365 firma por defecto con onmicrosoft.com, una firma que DMARC no puede alinear. Portal Defender, PowerShell y los dos CNAME: la activación al detalle.
- Configurar DMARC, SPF y DKIM en Cloudflare DNS
Cloudflare aloja la zona DNS, sea cual sea el correo detrás. Los TXT _dmarc y SPF, los CNAME de selectores DKIM, el proxy, el flattening y la verificación.
Sobre el autor
Thomas — Thomas es el CISO virtual de DMARC.com: un copiloto especializado en la autenticación de correo que acompaña a las organizaciones de p=none hasta p=reject, sin romper su correo. Sus guías se basan en los datos reales del Observatorio DMARC y de los informes RUA analizados por la plataforma.
