Volver a las guías · Fundamentos · 13 min de lectura
Qué exigen exactamente Gmail, Outlook y Yahoo
La tabla comparada de los tres, el umbral de 5.000 al día que suman los subdominios, y la aritmética del 0,30 %: quince personas enfadadas te sacan del sistema.
Actualizada en Agosto de 2026
Los tres piden lo mismo en lo esencial: SPF, DKIM, DMARC (con p=none basta) y que el dominio del From esté alineado con el de SPF o con el de DKIM. El umbral a partir del cual eso deja de ser recomendación y pasa a ser condición de entrega son 5.000 mensajes al día a cuentas de consumidor, y aquí está la letra pequeña que rompe arquitecturas: los subdominios suman.
La otra cifra que hay que saberse es el 0,30 por ciento de quejas. No es un aviso, es una puerta: al superarlo, Google te declara no elegible para mitigación de entrega, y solo recuperas la elegibilidad tras siete días consecutivos por debajo.
El umbral: 5.000 al día, y los subdominios suman
«A bulk sender is any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period.»
Tres matices que cambian el diseño de cualquier infraestructura de envío. Primero: los mensajes enviados desde subdominios cuentan hacia el umbral del dominio principal, así que trocear en news1, news2 y news3 para quedarse por debajo de 5.000 no funciona y nunca ha funcionado. Segundo: se cuenta contra cuentas personales del proveedor, no contra el total de tu lista. Y tercero, el que más sorprende: una vez cruzado el umbral, se es remitente masivo de forma permanente. Microsoft lo dice de forma explícita para Outlook.com: a partir de 5.000 mensajes con el mismo dominio en el From, todos los mensajes posteriores deben cumplir.
La tabla comparada de los tres
| Requisito | Google / Gmail | Yahoo | Microsoft / Outlook.com |
|---|---|---|---|
| Umbral de "masivo" | 5.000 msg/día a cuentas Gmail personales | Remitentes masivos, sin cifra pública | 5.000 msg/día a outlook.com, hotmail.com y live.com |
| SPF | Obligatorio | Obligatorio | Obligatorio |
| DKIM | Obligatorio. 1024 bits mínimo, 2048 recomendado | Obligatorio. 1024 bits mínimo | Obligatorio |
| DMARC | Obligatorio, con p=none basta | Obligatorio, con p=none basta | Obligatorio, con p=none basta |
| Alineación | El From alineado con SPF o con DKIM | Igual | Igual |
| Baja en un clic | RFC 8058 en marketing y suscripciones. Procesar en 2 días | Obligatoria. POST del RFC 8058 muy recomendado, mailto aceptable. Honrar en 2 días | Exigida como buena práctica: una forma visible de darse de baja |
| Tasa de quejas | Objetivo por debajo del 0,10 %. Nunca 0,30 % o más | Por debajo del 0,3 % | Listas limpias y quejas bajas, sin cifra pública |
| TLS | Obligatorio desde diciembre de 2023 | No publicado | No publicado |
| PTR y DNS inverso coherente | Obligatorio para todos los remitentes | No publicado | No publicado |
| Formato RFC 5322 y Message-ID | Obligatorio | No publicado | No publicado |
La aritmética del 0,30 por ciento
Google publica tres niveles y conviene traducirlos a personas, porque en porcentaje no se entiende el margen que hay:
| Tasa de quejas | Estado según Google | En una campaña de 5.000 entregados |
|---|---|---|
| Por debajo del 0,10 % | Nivel de cumplimiento recomendado | Menos de 5 personas te marcan como spam |
| Entre 0,10 % y 0,30 % | Ya hay impacto negativo en la entrega en bandeja | Entre 5 y 15 personas |
| 0,30 % o más | No elegible para mitigación de entrega | 15 personas bastan |
Ese es el dato que cambia la conversación: el margen entre "va bien" y "estás fuera" son diez personas enfadadas. Y hay dos detalles de definición que casi nadie tiene en cuenta. El primero: la tasa mide solo el marcado manual, literalmente "el porcentaje de tus mensajes que los destinatarios marcan manualmente como spam en Gmail", así que el filtrado automático no aparece. Puedes tener una tasa impecable y estar cayendo en la carpeta de correo no deseado. El segundo: el denominador es el correo entregado en bandeja, no el enviado, cosa que Yahoo dice de forma explícita, y por eso el número nunca cuadra con lo que te dice tu herramienta de envío.
Qué cambió y cuándo
| Fecha | Quién | Qué |
|---|---|---|
| Diciembre de 2023 | TLS obligatorio para transmitir correo | |
| 1 de febrero de 2024 | Google y Yahoo | Entran en vigor los requisitos de remitente masivo, con aplicación gradual mediante errores temporales 4xx |
| Junio de 2024 | Superar el 0,30 % te deja no elegible para mitigación de entrega | |
| Septiembre de 2024 | BIMI acepta certificados CMC además de VMC | |
| 5 de mayo de 2025 | Microsoft | Outlook.com exige SPF, DKIM y DMARC por encima de 5.000 mensajes al día. Primera fase: a la carpeta de correo no deseado |
| 30 de mayo de 2025 | Gmail deja de aceptar 3DES en conexiones SMTP entrantes | |
| 2025 | Microsoft | Segunda fase: rechazo con 550 5.7.515 |
| Noviembre de 2025 | Escalada de aplazamientos temporales (421) a rechazos permanentes (550) para el tráfico no conforme | |
| 22 de julio de 2026 | Microsoft | SNDS deja de publicar los impactos en trampas de spam en su informe de datos |
Lo que exige Google y no es autenticación
La mitad de los requisitos publicados no van de criptografía sino de formato y de honestidad, y son los que más se incumplen sin querer:
- Formato conforme al RFC 5322, con un Message-ID válido en todos los mensajes.
- La cabecera From debe llevar una sola dirección de correo.
- Nada de asunto ni contenido metido en el nombre visible del remitente, y nada de emojis ni caracteres no estándar en él.
- Prohibido ocultar contenido con HTML y CSS. Los enlaces del cuerpo tienen que ser visibles y comprensibles.
- DNS inverso válido y coherente (PTR) para los dominios o las IP que envían.
- TLS en la conexión, desde diciembre de 2023.
Lo que no vas a encontrar en ninguna de las tres guías oficiales es una lista de palabras prohibidas. No existe. En Gmail, Outlook y Yahoo decide el comportamiento agregado de miles de destinatarios, no un diccionario. Donde las palabras sí puntúan es en los filtros de reglas que hay detrás de mucho hosting español, y eso se resuelve por estructura del mensaje, no por sinónimos.
La baja en un clic, en dos frases
List-Unsubscribe: <https://empresa.es/u/8f3a1c9e-4b2d-4f77-9c1a-2b8e5d0f7a63>, <mailto:baja@empresa.es?subject=unsubscribe> List-Unsubscribe-Post: List-Unsubscribe=One-Click
Y las dos tienen que estar cubiertas por la firma DKIM, incluidas en su tag h=. Si no lo están, Gmail no muestra el botón nativo, que es justo el que evita que el usuario te marque como spam.
Google y Yahoo dan un plazo máximo de dos días para procesar la baja. En España hay además una obligación propia y anterior: la LSSI exige incluir una dirección electrónica válida donde ejercer la oposición, y prohíbe expresamente enviar comunicaciones que no la incluyan. Son dos cosas distintas y hay que cumplir las dos. La implementación exacta, con la trampa del GET de los escáneres de seguridad, está en la guía de la baja en un clic.
Cómo compruebas si cumples
- Da de alta en Google Postmaster Tools el dominio raíz y cada subdominio de envío por separado, y hazlo antes del primer envío para tener línea base. El panel de estado de cumplimiento es binario y no admite discusión.
- Mira el panel de errores de entrega: sube antes que la tasa de spam y es el detector precoz de un bloqueo.
- Si tienes IP propia, pide acceso a SNDS y date de alta en JMRP, que son por IP. En Yahoo, el bucle de quejas es por dominio DKIM.
- Comprueba la alineación en un mensaje real de cada flujo, mirando la cabecera Authentication-Results. Los registros en verde no prueban alineación.
- Ten presente el límite de volumen de Postmaster Tools: con poco tráfico a Gmail no verás datos, porque Google los oculta para proteger la privacidad de los usuarios.
Preguntas que salen siempre
Envío desde Google Workspace o Microsoft 365, ¿ya cumplo?
Cumples SPF y DKIM del proveedor, que no es lo mismo. Falta publicar DMARC en tu dominio y comprobar que el flujo alinea. Y si lo que vas a mandar son campañas, ojo: Microsoft dice por escrito que Exchange Online no está pensado para escenarios de envío masivo.
¿Me vale con p=none?
Para cumplir el requisito de los tres, sí. Para que nadie pueda suplantar tu dominio, no: eso solo lo consigue quarantine o reject, y ahí se llega por un runbook, no de un salto.
Estoy por debajo de 5.000 al día. ¿Puedo ignorar todo esto?
Puedes ignorar los requisitos reforzados, no los generales. Y hay una asimetría incómoda: el umbral se cruza una vez y ya no se vuelve atrás, así que la infraestructura conviene montarla antes de necesitarla.
Cumplir esta lista se reduce, en la práctica, a dos trabajos. El primero es publicar los tres registros y conseguir que alineen, que es lo que explica la guía de SPF, DKIM y DMARC. El segundo es subir la política de DMARC sin dejar de entregar por el camino, y eso tiene su propio runbook en la guía de DMARC sin romper nada, reescrito después de la revisión de mayo de 2026.
Fuentes
Todo lo que se afirma aquí sale de alguno de estos sitios. Si algo no lleva fuente, es una opinión y está dicho como tal.
- Google. Email sender guidelines · Consultada el 26 de agosto de 2026
- Google. Preguntas frecuentes sobre las directrices de remitente · Consultada el 26 de agosto de 2026
- Google. Postmaster Tools: definición de los paneles · Consultada el 26 de agosto de 2026
- Google. Anuncio del fin del cifrado 3DES en SMTP entrante (mayo de 2025) · Consultada el 26 de agosto de 2026
- Google. BIMI con certificados CMC (septiembre de 2024) · Consultada el 26 de agosto de 2026
- Yahoo. Sender best practices · Consultada el 26 de agosto de 2026
- Microsoft. Corregir el error NDR 550 5.7.515 en Outlook.com · Consultada el 26 de agosto de 2026
- Microsoft. Nuevos requisitos de Outlook para remitentes de alto volumen (mayo de 2025) · Consultada el 26 de agosto de 2026
- Microsoft. Portal SNDS (Smart Network Data Services) · Consultada el 26 de agosto de 2026
- Microsoft. Límites de Exchange Online · Consultada el 26 de agosto de 2026
- Mailgun. Política de uso aceptable (umbrales de rebote y queja) · Consultada el 26 de agosto de 2026
- Resend. Acceptable use policy (umbrales de rebote y queja) · Consultada el 26 de agosto de 2026
- IETF. RFC 8058: baja en un clic · Consultada el 26 de agosto de 2026
- BOE. Ley 34/2002 (LSSI), art. 21: comunicaciones comerciales por correo electrónico · Consultada el 26 de agosto de 2026
Esta guía explica cómo funcionan las cosas y cita las normas con enlace, pero no es asesoramiento jurídico.