Administrar un servidor de correo en 2026 significa controlar bastante más que Postfix, Exim o el proveedor SMTP elegido. Gmail y Outlook.com coinciden ya en exigir SPF, DKIM y DMARC a los dominios que superan aproximadamente los 5.000 mensajes diarios, mientras Yahoo e iCloud aplican requisitos similares para el correo masivo. DNS inverso, reputación de IP, alineación DMARC, bajas, rebotes y tasas de spam forman parte de una infraestructura que necesita monitorización continua.
Las claves de la entregabilidad del email en 30 segundos
- Gmail y Outlook.com sitúan alrededor de 5.000 mensajes diarios la frontera que activa requisitos adicionales para grandes remitentes.
- SPF, DKIM y DMARC deben configurarse correctamente; publicar los registros no significa necesariamente superar las validaciones.
- Gmail recomienda mantener las denuncias de spam por debajo del 0,1 % y no alcanzar el 0,3 %.
- Yahoo exige menos del 0,3 % y bajas procesadas en dos días.
- PTR, TLS, reputación de IP, errores SMTP y separación entre correo transaccional y marketing también deben monitorizarse.
La principal diferencia respecto a hace unos años es que la autenticación ha dejado de ser una recomendación reservada a administradores especialmente cuidadosos. Los grandes proveedores la utilizan para decidir si aceptan, rechazan o filtran los mensajes.
Y una configuración que funciona con Gmail no garantiza exactamente el mismo comportamiento en Outlook, Yahoo o iCloud.
Para desarrolladores y administradores de sistemas, la entregabilidad debe tratarse por eso como un problema distribuido: cada destinatario aplica sus propias reglas sobre una base técnica cada vez más común.
Gmail y Outlook convergen en SPF, DKIM y DMARC
Google lleva aplicando sus requisitos reforzados desde febrero de 2024 y endureció la aplicación contra tráfico que incumple las normas a partir de noviembre de 2025.
Gmail considera remitente masivo a quien envía aproximadamente 5.000 mensajes o más durante 24 horas a cuentas personales de Gmail. Además, agrega el tráfico procedente del mismo dominio principal. Enviar 3.000 mensajes desde news.example.com y otros 2.000 desde shop.example.com no evita el umbral: para Google pertenecen a example.com. Una vez alcanzada, la consideración de remitente masivo es permanente.
Microsoft dio un paso parecido para Outlook.com, Hotmail.com y Live.com.
Desde mayo de 2025 exige SPF, DKIM y DMARC a los dominios que envían más de 5.000 mensajes diarios. Microsoft decidió además rechazar el correo que no alcance el nivel requerido de autenticación mediante el error:
550 5.7.515 Access denied, sending domain does not meet the required authentication level
La medida afecta al servicio de consumo Outlook.com, algo que conviene distinguir de las políticas particulares que puedan aplicarse dentro de organizaciones que utilizan Microsoft 365.
La comparación básica queda así:
| Requisito | Gmail | Outlook.com | Yahoo | iCloud |
|---|---|---|---|---|
| SPF | Sí | Sí | Sí | Sí |
| DKIM | Sí para bulk | Sí para >5.000/día | Sí para bulk | Sí |
| DMARC | Sí para bulk | Sí para >5.000/día | Sí para bulk | Sí |
| PTR/rDNS | Sí | Recomendado | Sí | Sí |
| Umbral público bulk | ~5.000/día | >5.000/día | Sin cifra pública | Sin cifra pública |
| One-click unsubscribe | Marketing bulk | Buena práctica | Marketing bulk | Baja requerida |
| Spam máximo publicado | evitar ≥0,3 % | Sin equivalente público idéntico | <0,3 % | Sin porcentaje público |
Las diferencias son relevantes. Yahoo, por ejemplo, explica expresamente que no publica una cifra concreta de mensajes para determinar qué considera un bulk sender. Analiza el dominio autenticado o el dominio From, pero también utiliza información sobre IP y contenido.
Que SPF, DKIM y DMARC existan en DNS no significa que funcionen
Aquí aparece uno de los problemas más frecuentes en producción.
Un administrador comprueba:
dig TXT example.com
ve un registro SPF y considera terminado el trabajo.
No necesariamente.
SPF debe autorizar realmente la infraestructura que está enviando el mensaje. Si una aplicación nueva comienza a utilizar otro relay SMTP que no está incluido correctamente, la autenticación puede fallar.
DKIM introduce otra capa. El MTA o proveedor firma criptográficamente el mensaje y el destinatario obtiene mediante DNS la clave pública correspondiente al selector utilizado.
Después llega DMARC.
DMARC no se limita a preguntar si SPF o DKIM han pasado. Comprueba también la alineación con el dominio que el usuario ve en From:.
Por ejemplo, una plataforma podría enviar:
From: [email protected]
pero utilizar como Return-Path un dominio perteneciente al proveedor de email. SPF podría superar su comprobación para ese dominio técnico y, aun así, no aportar la alineación necesaria con example.com.
DKIM puede resolver el problema si la firma utiliza correctamente un dominio alineado.
Para Gmail, el dominio From: debe estar alineado con el dominio SPF o DKIM en el correo directo de grandes remitentes. Yahoo establece igualmente este requisito para superar DMARC.
Esto explica por qué comprobar únicamente que el registro DMARC existe tampoco resulta suficiente.
En mayo de 2026, además, DMARC alcanzó una nueva etapa de estandarización con RFC 9989, que sustituye a RFC 7489 y RFC 9091 dentro del Standards Track del Internet Engineering Task Force (IETF).
Gmail ofrece una métrica que ningún sysadmin debería ignorar
Gmail añade una variable especialmente útil para operaciones: Postmaster Tools.
Google recomienda mantener las denuncias de spam por debajo del 0,1 % y evitar que alcancen o superen el 0,3 %. Una tasa superior al 0,1 % ya puede perjudicar la llegada a bandeja de entrada.
Eso significa que disponer de una infraestructura técnicamente perfecta tampoco garantiza entregabilidad.
Un dominio puede superar SPF, DKIM y DMARC, disponer de PTR correcto, utilizar TLS y continuar deteriorando su reputación porque demasiados destinatarios pulsan «Marcar como spam».
Yahoo establece también el 0,3 % como límite para remitentes masivos. Su Sender Hub permite consultar información relacionada con las denuncias, mientras su Complaint Feedback Loop (CFL) puede comunicar que un usuario ha marcado un mensaje como spam.
Aquí marketing y sistemas comparten responsabilidad.
Sistemas puede garantizar autenticación y observar la infraestructura. Pero si una aplicación continúa enviando a usuarios inactivos o una campaña utiliza una lista de mala calidad, la reputación puede deteriorarse aunque el MTA esté impecablemente configurado.
Gmail Postmaster, Yahoo Sender Hub y las herramientas de Microsoft no muestran lo mismo
Para operar correo a escala tampoco basta con consultar una blacklist pública.
Cada gran receptor dispone de información propia.
Gmail Postmaster Tools proporciona métricas relacionadas con reputación de dominio e IP, autenticación, errores de entrega y denuncias de spam. Google ha añadido además información específica sobre el cumplimiento de sus requisitos.
Yahoo dispone de Sender Hub y Complaint Feedback Loop. Una característica interesante es que Yahoo calcula su tasa de denuncias utilizando como denominador los mensajes entregados en Inbox, algo que puede provocar diferencias respecto a las métricas calculadas internamente por el remitente.
Microsoft mantiene herramientas específicas para su infraestructura de consumo y sus propios mecanismos de reputación. Por eso un operador puede observar buena entregabilidad hacia Gmail y problemas hacia Outlook.com sin que exista necesariamente una contradicción.
Una blacklist externa sigue siendo útil para detectar incidentes, especialmente cuando una IP aparece asociada a spam, malware o infraestructura comprometida. Pero no representa por sí sola la reputación interna que Google, Microsoft, Yahoo o Apple asignan a un remitente.
El mejor monitor sigue siendo el conjunto: respuestas SMTP, colas del MTA, DMARC, feedback loops disponibles, herramientas Postmaster y métricas internas.
Los códigos SMTP deberían terminar en el sistema de monitorización
Para un sysadmin, uno de los errores consiste en limitar la observabilidad del correo a «enviado» y «fallido».
Un 250 OK del servidor SMTP remoto significa que el siguiente sistema ha aceptado el mensaje. No garantiza que el correo termine en Inbox.
También hay que diferenciar errores temporales 4xx de rechazos permanentes 5xx.
Los primeros pueden indicar throttling, reputación temporal, límites de volumen o problemas transitorios. El MTA normalmente reintentará la entrega siguiendo su política de colas.
Los segundos requieren otra respuesta operativa.
Si Outlook devuelve 550 5.7.515 por incumplimiento de autenticación, repetir indefinidamente la entrega no solucionará SPF, DKIM o DMARC.
Apple recomienda expresamente que quienes envían correo a iCloud registren los errores SMTP temporales y permanentes y actúen sobre ellos. También exige DNS inverso, SPF, DKIM y publicación de DMARC para correo masivo.
Un sistema con cierto volumen debería por tanto agregar códigos SMTP por destino y detectar cambios.
Si ayer Outlook aceptaba el 99 % del tráfico y hoy comienza a devolver una determinada familia de errores, esa señal puede resultar más útil que esperar a que usuarios internos informen de que «los correos no llegan».
Separar marketing y transaccional también es arquitectura
Una aplicación SaaS puede generar simultáneamente varios tipos de mensajes:
confirmaciones de cuenta, recuperación de contraseña, alertas de seguridad, facturas, notificaciones, newsletters y campañas comerciales.
Enviar todo mediante exactamente el mismo flujo crea un dominio de fallo innecesariamente grande.
Si una newsletter dispara las denuncias de spam, los correos de recuperación de contraseña pueden quedar expuestos al deterioro de la misma reputación.
Apple recomienda explícitamente segmentar el correo de marketing y el transaccional, manteniendo a la vez dominios e IP de envío coherentes.
En infraestructuras suficientemente grandes puede plantearse separación mediante subdominios, DKIM, streams y pools de IP.
Por ejemplo:
transactional.example.com
notifications.example.com
marketing.example.com
La separación no permite escapar artificialmente de las políticas de los proveedores. Gmail cuenta el volumen de subdominios pertenecientes al mismo dominio principal para determinar la condición de remitente masivo.
Su utilidad es operativa: aislar problemas, medir cada flujo y evitar que un cambio en una aplicación afecte indiscriminadamente a todos los mensajes.
El PTR sigue importando en 2026
Con toda la atención puesta sobre DMARC, es fácil olvidar elementos mucho más antiguos.
El DNS inverso o PTR continúa formando parte de las recomendaciones y requisitos de Gmail, Yahoo e iCloud.
Una IP utilizada para SMTP debería disponer de un PTR coherente que resuelva hacia un hostname válido, acompañado de la correspondiente resolución directa.
Yahoo recomienda específicamente PTR válidos, significativos y no genéricos para las IP de envío. También desaconseja nombres que hagan parecer que el servidor utiliza una dirección asignada dinámicamente.
Para un servidor dedicado de correo, algo conceptualmente coherente sería:
203.0.113.25 -> mail.example.com
y posteriormente:
mail.example.com -> 203.0.113.25
A ello se añaden HELO/EHLO coherente, TLS, formato RFC correcto y ausencia de configuraciones peligrosas como un open relay.
Yahoo llega incluso a recomendar que los operadores anuncien correctamente todo su espacio IP para reducir la exposición a secuestros BGP que puedan utilizar direcciones del bloque para enviar correo fraudulento.
La entregabilidad termina encontrándose así directamente con la administración de redes.
Una IP nueva también necesita construir reputación
Cambiar de proveedor SMTP o estrenar una dirección IPv4 dedicada plantea otro problema: la nueva IP carece de historial suficiente.
Enviar repentinamente un millón de mensajes desde ella no es equivalente a hacerlo desde una infraestructura que lleva meses manteniendo un comportamiento estable.
El denominado IP warm-up intenta construir progresivamente ese historial.
No existe una tabla universal válida para todos los proveedores y volúmenes. El comportamiento de los destinatarios, la calidad de las listas y el tipo de mensajes importan tanto como la cantidad.
Para sistemas, la idea relevante es evitar cambios bruscos sin observabilidad.
Si se migra de infraestructura, conviene controlar separadamente entregas hacia Gmail, Outlook, Yahoo e iCloud, además de hard bounces, soft bounces, denuncias y respuestas SMTP.
También debe conocerse el historial de las direcciones utilizadas. Una IPv4 «nueva» para una empresa puede haber pertenecido anteriormente a otro cliente.
One-click unsubscribe también tiene una implementación técnica
La baja con un clic tampoco consiste simplemente en añadir al HTML:
<a href="...">Darse de baja</a>
Gmail exige one-click unsubscribe para mensajes promocionales y de suscripción de grandes remitentes. Yahoo hace lo mismo para marketing y recomienda la implementación definida por RFC 8058.
El mecanismo utiliza encabezados como:
List-Unsubscribe: <https://example.com/unsubscribe/opaque-id>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
El proveedor puede realizar entonces una petición HTTPS POST contra el endpoint especificado.
Eso introduce una responsabilidad para desarrollo.
El endpoint tiene que funcionar, ser idempotente cuando proceda y procesar correctamente la baja sin depender de que el usuario inicie sesión. Yahoo exige atender las solicitudes en un máximo de dos días.
Los correos puramente transaccionales reciben un tratamiento diferente. Gmail y Yahoo aclaran que el requisito de baja con un clic no se aplica, por ejemplo, a restablecimientos de contraseña o confirmaciones directamente relacionadas con acciones del usuario.
La checklist real empieza antes de pulsar «Enviar»
Para desarrolladores y administradores, la entregabilidad de 2026 debería formar parte de las pruebas de despliegue.
Una nueva aplicación que comienza a enviar correo debería incorporarse al inventario de remitentes, utilizar DKIM correctamente, quedar cubierta por SPF cuando corresponda y aparecer posteriormente en los informes DMARC.
El pipeline también debería comprobar que las plantillas generan mensajes RFC válidos, que los rebotes terminan en una suppression list y que una dirección dada de baja no vuelve a introducirse accidentalmente desde otro CRM.
La observabilidad debería cubrir como mínimo autenticación, volumen por proveedor, respuestas SMTP, colas, rebotes, denuncias y reputación disponible.
Y conviene evitar una interpretación equivocada: cumplir SPF, DKIM y DMARC no otorga un pase directo a Inbox.
Gmail, Outlook, Yahoo e iCloud utilizan más señales para tomar sus decisiones. Apple dice expresamente que combina reputación de dominio e IP, comprobaciones de contenido y feedback de usuarios, y que no ofrece una allowlist para grandes remitentes.
La tendencia, sin embargo, está clara. Gmail y Outlook han colocado la barrera de 5.000 mensajes en un lugar muy visible y Yahoo y Apple siguen una filosofía técnica parecida.
En 2026 el correo electrónico continúa funcionando sobre protocolos diseñados hace décadas, pero mantener una buena entregabilidad exige operar identidades criptográficas, DNS, reputación, IP, TLS, HTTP para las bajas y telemetría SMTP.
Para el equipo de marketing el síntoma puede seguir siendo «la campaña está llegando a spam». Para desarrollo y sistemas, el diagnóstico empieza bastante antes.
Preguntas frecuentes
¿Qué exigen Gmail y Outlook al superar 5.000 correos diarios?
Gmail exige a los grandes remitentes SPF, DKIM, DMARC y otras medidas relacionadas con DNS, TLS, spam y bajas. Outlook.com exige SPF, DKIM y DMARC a dominios que superan 5.000 mensajes diarios.
¿Tener SPF, DKIM y DMARC garantiza llegar a Inbox?
No. Son mecanismos de autenticación y política, pero los proveedores también utilizan reputación de IP y dominio, denuncias, comportamiento del tráfico y otras señales para clasificar los mensajes.
¿Qué proveedor tiene el límite de spam más claro?
Gmail recomienda permanecer por debajo del 0,1 % y no alcanzar el 0,3 %. Yahoo establece para remitentes masivos una tasa inferior al 0,3 %.
¿Conviene separar correo transaccional y marketing?
Sí, especialmente para poder observar y contener los problemas de cada flujo. iCloud lo recomienda expresamente, aunque separar subdominios no permite eludir las reglas de volumen de Gmail para el dominio principal.
