Última actualización: julio de 2026

En resumen: Casi todos los proveedores cloud y de servidores bare metal bloquean por defecto el envío de correo electrónico saliente a través del puerto TCP 25 para evitar el spam y proteger la reputación de sus direcciones IP. Esta guía compara las políticas de 13 grandes proveedores, detalla sus procedimientos específicos de desbloqueo y explica por qué el envío a través de un relay smarthost por el puerto 587 suele ser la mejor alternativa técnica.

Cuando instalas tu propio servidor de correo (como Postfix, Mailcow o Microsoft Exchange) en un servidor virtual (VPS, instancia cloud) o dedicado, los intentos de envío hacia destinatarios externos suelen fallar por tiempo de espera de conexión (timeout). En la mayoría de los casos, este problema no se debe a una mala configuración de tu servidor, sino a un filtro de red ascendente impuesto por tu proveedor para bloquear el tráfico saliente en el puerto TCP 25.

Por qué los proveedores cloud bloquean el puerto 25

Las rangos de direcciones IP en los centros de datos se asignan dinámicamente y se reciclan con mucha frecuencia entre miles de usuarios. Actores maliciosos aprovechan a menudo estas instancias para lanzar campañas automatizadas masivas de spam y phishing. Sin bloqueos de red en el puerto 25, subredes enteras terminarían rápidamente en listas negras globales (DNSBL) como Spamhaus o UCEPROTECT, perjudicando la entregabilidad del correo de todos los clientes que comparten esa infraestructura.

Políticas de los 13 proveedores al detalle

Cada proveedor aplica criterios y procedimientos distintos para eliminar las restricciones del puerto 25 saliente, desde un simple botón de activación en el panel de control hasta estrictas verificaciones de identidad e historial de facturación. Elige tu proveedor en la siguiente lista para revisar los requisitos exactos, las citas oficiales y las guías paso a paso de desbloqueo:

Proveedores europeos y alemanes

  • Hetzner Cloud & Dedicated: El puerto 25 está bloqueado por defecto en todos los nuevos servidores cloud. Tras un mes de historial activo y facturas pagadas, puedes solicitar el desbloqueo manual en la sección de límites de la Cloud Console.
  • Netcup: Los puertos de envío de correo tienen restricciones de fábrica. Una vez pagadas las facturas y verificados tus datos de contacto, puedes desactivar el bloqueo al instante desde el Server Control Panel (SCP).
  • Contabo: El tráfico saliente no está bloqueado totalmente en la red, pero está sujeto a estrictos límites diarios de volumen para prevenir el abuso. Para aumentarlos es necesario contactar con el soporte técnico.
  • IONOS: Bloqueado de forma centralizada en servidores Cloud y Dedicados. Para retirar la restricción debes configurar tres requisitos técnicos (FQDN, rDNS, SPF) y realizar una llamada de verificación con el servicio de atención al cliente.
  • STRATO: Restringido por defecto en productos de servidor (especialmente servidores Root Windows) por motivos de seguridad. El desbloqueo requiere abrir un ticket de soporte tras configurar un registro DNS inverso (rDNS) válido.
  • OVHcloud: Bloqueado por defecto en todas las instancias VPS, Dedicados y Public Cloud. El equipo de soporte técnico revisa cada solicitud de desbloqueo de forma manual e individual.
  • Scaleway: Restringe por defecto los puertos SMTP remotos 25, 465 y 587. Una vez completada la verificación de identidad (KYC), puedes activar el envío SMTP marcando una casilla directamente en tu grupo de seguridad (Security Group).

Plataformas cloud globales y proveedores de EE. UU.

  • Amazon Web Services (AWS EC2): El puerto 25 saliente está restringido y bloqueado para todos los destinos públicos IPv4 e IPv6. La eliminación requiere enviar un formulario oficial de solicitud para cada región de AWS de forma independiente.
  • Microsoft Azure: Abierto para suscripciones Enterprise Agreement, pero bloqueado permanentemente para el modelo de pago por uso (Pay-As-You-Go). Las suscripciones Dev/Test pueden solicitar el desbloqueo a través de la herramienta de diagnóstico del portal.
  • Google Cloud (GCP Compute Engine): El puerto 25 saliente hacia Internet está estrictamente bloqueado (incluso para relays de Google Workspace). Google obliga a enrutar el tráfico saliente a través de relays autenticados en el puerto 587 o 465.
  • DigitalOcean: Bloquea por defecto los puertos salientes 25, 465 y 587 en todos los Droplets e IPs reservadas sin excepciones, recomendando encarecidamente el uso de proveedores de correo externos.
  • Vultr: El puerto TCP 25 está incluido en la lista predeterminada de puertos bloqueados, pero puede eliminarse solicitándolo mediante la apertura de un ticket de soporte técnico.
  • Oracle Cloud Infrastructure (OCI): Bloqueado por defecto en todos los arrendamientos (tenancies) creados después del 23 de junio de 2021. El envío de correo exige presentar una solicitud formal de aumento de límites de servicio para obtener una exención.

El desafío subyacente: reputación de IPs de centro de datos

Incluso si tu proveedor aprueba la solicitud y desbloquea el puerto 25 saliente, enviar correo directamente desde una instancia cloud presenta grandes obstáculos de entregabilidad. Las principales plataformas receptoras —como Gmail, Yahoo, Apple iCloud y Microsoft Outlook— aplican algoritmos de filtrado muy agresivos al tráfico que se origina en subredes de centros de datos.

Debido a la alta rotación histórica de estas direcciones IP, los mensajes enviados directamente desde un VPS suelen terminar en la carpeta de spam o ser rechazados al coincidir con listas negras DNS (como Spamhaus o UCEPROTECT), independientemente de que los registros SPF, DKIM y DMARC estén perfectamente configurados.

La solución recomendada: relay smarthost mediante el puerto 587

Para evitar tanto los bloqueos del puerto 25 como la mala reputación asociada a los rangos de IP de centros de datos, debes enrutar el correo saliente por el puerto 587 (Submission) utilizando un relay smarthost autenticado. El puerto 587 está diseñado específicamente para el envío cifrado por parte de clientes y permanece abierto en casi todos los proveedores (con la excepción de DigitalOcean e inicialmente Scaleway).

Un fragmento de configuración habitual en el archivo /etc/postfix/main.cf para enviar correo a través de un relay smarthost autenticado es el siguiente:

relayhost = [smtp.provider.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

O envía de forma fiable a través de Dispatch. Si prefieres evitar la gestión de tickets de soporte, los trámites de verificación KYC, la monitorización de listas negras y la administración de tu propio relay, puedes canalizar todo tu tráfico de correo saliente de forma rápida y segura a través de Dispatch.

Verificar tu configuración

Una vez que tu flujo de relay externo o smarthost esté activo, comprueba la autenticación de tus cabeceras de correo (SPF, DKIM, DMARC) y la entregabilidad general de tu dominio con el escáner gratuito MXAudit.