Una tienda en línea de 14 personas nos escribió cuando sus confirmaciones de pedido dejaron de llegar a cerca de la mitad de sus clientes. Del lado de ellos no había cambiado nada. Lo que cambió es que los tres proveedores de correo que usan esos clientes publicaron cada uno una lista de requisitos para dominios que envían en volumen, y la tienda cruzó la línea el mes en que hizo su primera campaña de verdad.
Las tres listas se traslapan, y esa es la buena noticia. No son idénticas, y ahí es donde la gente se tropieza. Un dominio puede cumplir con Gmail y aun así ser rechazado de plano por Outlook.com, porque los proveedores difieren en lo que pasa cuando fallas más que en lo que piden. Abajo está la comparación con la que trabajamos en proyectos de clientes, con cada fila tomada de la página del propio proveedor y la fecha en que la revisamos.
En qué coinciden los tres proveedores y en qué no
Todo lo que hay en esta tabla se revisó el 16 de octubre de 2026 contra las páginas listadas al final del post. Donde un proveedor no publica una cifra, la celda lo dice en lugar de prestar un número de otro lado.
| Requisito | Gmail | Yahoo | Outlook.com |
|---|---|---|---|
| A quién aplican las reglas de volumen | Quien envía más de 5,000 mensajes al día a cuentas personales de Gmail; el FAQ dice cerca de 5,000 o más en cualquier periodo de 24 horas, y la clasificación queda puesta una vez que se alcanza | Remitentes masivos. La página de buenas prácticas de Yahoo expone las reglas sin publicar ahí un número diario | Dominios que envían 5,000 mensajes o más al día a direcciones de Outlook.com, Hotmail y Live, contados por el dominio de la dirección 5322.From |
| SPF y DKIM | Los dos, por encima del umbral. SPF o DKIM se exige a todo remitente, a cualquier volumen, desde el 1 de febrero de 2024 | Los dos | Los dos, y los dos tienen que pasar |
| Registro DMARC | Obligatorio; se acepta p=none | Obligatorio; al menos p=none, y tiene que pasar | Obligatorio; al menos p=none |
| Alineación del dominio del From | Obligatoria con SPF o DKIM | Obligatoria con SPF o DKIM | Obligatoria con SPF o DKIM, de preferencia los dos |
| Baja de suscripción en un clic | Obligatoria en correo comercial y promocional, con las cabeceras List-Unsubscribe y List-Unsubscribe-Post según el RFC 8058, y atendida en 48 horas. No se exige en correo transaccional | Obligatoria en correo de marketing y suscrito, se recomienda el método POST del RFC 8058, más un enlace visible en el cuerpo; atendida en dos días | Aparece como una práctica que Microsoft espera de quien envía mucho, una opción de baja claramente visible y una dirección From o Reply-To que pueda recibir respuestas, no como requisito de autenticación |
| Tasa de spam o de quejas | Debajo de 0.3% en Postmaster Tools, con 0.1% como objetivo de trabajo; arriba de 0.3% el remitente masivo queda sin derecho a mitigación hasta que la tasa se mantenga debajo siete días seguidos | Debajo de 0.3%, monitoreada con el Complaint Feedback Loop, que exige firmar con DKIM para inscribirse | No publica cifra. Microsoft se reserva el derecho de filtrar o bloquear por problemas de higiene |
| DNS directo e inverso | Obligatorio para todo remitente: la IP de envío necesita un registro PTR, y el nombre que ese PTR indica tiene que resolver de vuelta a esa IP | Se espera de todo remitente, junto con cumplir los RFC 5321 y 5322 | Sin requisito publicado aparte en el post de alto volumen |
| Cómo se ve el fallo | Rechazo o carpeta de spam, con un código SMTP que nombra el problema: 5.7.25 si el PTR no coincide, 5.7.29 si falta TLS. El FAQ de Gmail dice que el endurecimiento sobre el tráfico que no cumple viene subiendo desde noviembre de 2025 | Filtrado y limitación de tasa, sin una cadena de rebote publicada | Carpeta de spam desde el 5 de mayo de 2025, y una actualización en el mismo post de Microsoft dice que el correo que no cumple ahora se rechaza con 550 5.7.515 Access denied, sending domain [dominio] does not meet the required authentication level |
Dos columnas de esa tabla pesan más que el resto cuando estás atendiendo un problema en vivo. El texto del rebote te dice qué proveedor te está rechazando, y la fila de alineación te dice por qué, porque un dominio que pasa SPF y DKIM con el nombre equivocado falla DMARC en los tres.
Quién cuenta como remitente masivo en cada proveedor
Los umbrales son por proveedor y por día, contados en una ventana que nadie fuera del proveedor puede ver. Una campaña de 20,000 mensajes repartida entre cuatro proveedores puede dejarte arriba de la línea en uno y abajo en los otros, en la misma hora. Gmail cuenta solo cuentas personales de Gmail, así que el correo a una empresa que usa Google Workspace no suma al conteo, algo que sorprende a quien tiene una lista casi toda de direcciones corporativas.
El FAQ de Gmail agrega el detalle que importa para planear: una vez que un dominio alcanza el umbral, queda clasificado como remitente masivo. Un solo envío de Black Friday basta para dejarlo en esa categoría de forma permanente. El material de soporte de Microsoft describe el mismo umbral por el dominio de la cabecera From del sobre, lo que significa que un subdominio creado para una sola campaña se cuenta por su propio nombre.
Yahoo es el hueco honesto de la tabla. Su propia página de buenas prácticas expone completos los requisitos para remitentes masivos y ahí no les pone un número diario, así que no citamos ninguno. En la práctica la pregunta no es dónde está la línea: si envías el mismo mensaje a una lista de personas que se suscribieron, eres el tipo de remitente que describen estas reglas.
Qué configuramos en todo dominio de cliente, sin importar el volumen
Como el conteo es invisible y la clasificación es permanente, diseñar alrededor de un umbral es trabajo que vas a tener que repetir. En todo dominio que tocamos armamos la misma base, en este orden, y cumple con las tres listas a la vez:
- SPF con un include por sistema de envío. Un registro en el dominio organizacional, debajo del límite de 10 consultas, y primero fuera los includes muertos de plataformas que el cliente dejó de usar.
- DKIM firmado con el dominio propio del cliente, no con el de la plataforma de envío. Este es el cambio que arregla la mayor cantidad de fallos de alineación, y es el que casi todas las plataformas te dejan omitir.
- DMARC en
p=nonecon los reportes activados, leídos por algunas semanas antes de apretar nada. - DNS directo e inverso en cualquier IP desde la que el cliente envíe directo, que normalmente es una aplicación propia y no una plataforma de correo.
- TLS en la salida, que toda plataforma seria ya hace y que los envíos autogestionados a veces no.
- Baja en un clic en todo lo que el destinatario pidió recibir, con las dos cabeceras emitidas, cubiertas por la firma DKIM, y un endpoint que actúe con un POST en lugar de mostrar una página de confirmación.
- Marketing en su propio subdominio, para que la tasa de quejas de una campaña no se lleve las facturas con ella.
El registro DMARC con el que arrancamos se ve así, publicado como registro TXT en _dmarc.example.com:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; adkim=r; aspf=r"Esa es a propósito la política más débil. Le pide a cada proveedor que te mande reportes y a ninguno que actúe todavía. La subida de ahí hasta p=reject es un trabajo aparte, que cubrimos en nuestra guía de despliegue, y no debería empezar hasta que los reportes muestren pasando a todos los remitentes legítimos.
Los fallos que encontramos más seguido
Casi todo dominio que nos llega con un problema de remitente masivo está fallando en una de seis cosas, y ninguna es exótica:
- DKIM firmado con el dominio de la plataforma. SPF pasa, DKIM pasa, DMARC falla, y el reporte se ve sano hasta que lees las columnas de identificadores.
PermErrorde SPF por demasiadas consultas. Pasando de diez el registro deja de evaluarse, así que SPF no pasa ni falla de forma limpia.- Un registro DMARC publicado en el nombre equivocado, casi siempre en el dominio raíz en vez de
_dmarc, o en_dmarc.example.com.example.comporque el panel de DNS agrega la zona. - Dos registros SPF o dos registros DMARC en el mismo nombre, herencia de una migración. En pareja los dos son inválidos.
- Una cabecera
List-Unsubscribe-Postcon un endpoint que ignora el POST. La cabecera promete un clic y el servidor pide una confirmación, que es justo lo que incumple el requisito. - El reenvío. Un alias del destinatario retransmite tu mensaje, SPF se rompe en el salto nuevo y lo único que sostiene la alineación es DKIM. Explicamos por qué en este post sobre reenvío y SPF.
Cómo revisar tu dominio hoy
Antes de cambiar un registro, averigua cuál de las ocho filas de arriba le falta de verdad a tu dominio. Pasa el dominio por las revisiones de abajo y después lee las cabeceras de un mensaje real llegado a cada uno de los tres proveedores, para confirmar que SPF, DKIM y DMARC pasan con tu propio nombre de dominio y no con el de una plataforma.
Si ya estás rebotando, el texto del rebote es más rápido que cualquier herramienta. Un 550 5.7.515 es Microsoft diciéndote que no se cumple el nivel de autenticación. Un 5.7.26 de Gmail significa que el mensaje iba sin autenticar; un 5.7.25, que el DNS inverso no coincide. Nuestra guía del rechazo por reputación baja de Gmail cubre el único caso en que los registros están todos bien y el dominio sigue rechazado.
Qué vigilamos el mes siguiente
La autenticación es la parte que puedes verificar en una tarde. La reputación es la que toma semanas, y es la que decide si el correo llega a la bandeja de entrada en lugar de solo ser aceptado. Los treinta días después de un arreglo vigilamos tres cosas con el cliente: la tasa de spam en Postmaster Tools, las tasas de aprobación por fuente de envío en los reportes agregados de DMARC, y el texto mismo del rebote, porque un proveedor que cambia de criterio lo dice en la respuesta SMTP antes de que aparezca en cualquier otro lado.
La tasa de quejas es la señal más lenta en recuperarse, y ese es el argumento real para separar el subdominio. Un dominio que estuvo arriba de 0.3% en Gmail tiene que mantenerse debajo siete días seguidos antes de volver a tener derecho a mitigación, y ese reloj no arranca hasta que se detiene el correo que causó las quejas.
Cómo ayuda Guanacos Tech
Hacemos esto como un trabajo de alcance fijo para equipos pequeños y medianos en Norteamérica y Latinoamérica: leer los registros actuales y el último mes de reportes, alinear el dominio contra las tres listas de proveedores, arreglar lo que falta en el orden de arriba, confirmarlo con un mensaje real a cada proveedor y después vigilar las tasas contigo el mes siguiente. Cómo trabajamos cabe en una página. Si prefieres que las ocho filas queden verificadas en lugar de investigadas, para eso existe la consultoría de entregabilidad de correo, y media hora con tu panel de DNS y un rebote reciente abiertos alcanza para decir a qué proveedor le estás fallando y qué hace falta para resolverlo.
Fuentes
- Google, Email sender guidelines (Ayuda de Gmail)
- Google, Email sender guidelines FAQ (Ayuda de Gmail)
- Yahoo, Sender Best Practices
- Microsoft, Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders
- Microsoft, Fix NDR error 550 5.7.515 in Outlook.com
- RFC 8058, Signaling One-Click Functionality for List Email Headers