¿Te bloquea Exchange Online al crear un conector de recepción porque detecta que la IP está “reservada” o es privada? A continuación encontrarás una guía completa, paso a paso y con ejemplos reales, para identificar la causa y adoptar la solución definitiva sin afectar el flujo de correo.
Contexto del conector SMTP en Exchange Online
En Microsoft 365, los inbound connectors permiten que dispositivos locales (impresoras, aplicaciones line‑of‑business, firewalls, appliances de seguridad como Proofpoint o Mimecast, etc.) envíen correos salientes a través de los centros de datos de Microsoft. Para proteger la plataforma contra suplantaciones y spam, Exchange Online verifica la dirección IP pública de origen y la compara con varias listas de reputación y con los rangos excluidos por los RFC 1918, RFC 6598, RFC 5735 y similares. Si la IP pertenece a un bloque reservado, la creación o actualización del conector falla inmediatamente con un mensaje muy descriptivo.
Cómo detecta Exchange Online las IP reservadas
Durante la operación de guardado, el servicio ejecuta una validación sintáctica (formato numérico, ausencia de CIDR inválido) y otra semántica: comprueba si la IP o el rango propuesto coincide con una de las entradas que figuran en la base de datos interna de direcciones no enrutables. Entre ellas destacan:
- RFC 1918 – 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
- RFC 5735 / 3330 – Bloques para documentación (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24).
- RFC 6598 – 100.64.0.0/10 usado en CGNAT.
- 0.0.0.0/8 (dirección nula), 127.0.0.0/8 (loopback), 169.254.0.0/16 (APIPA), 224.0.0.0/4 (multicast) y 240.0.0.0/4 (futuro).
La comprobación es inmediata; no se envía tráfico a Internet ni se consulta DNS externo. Así se evita aceptar accidentalmente redes internas que nunca deberían aparecer como remitentes válidas.
Problema reproducido
Unable to create a connector … IP range ‘1.1.1.3’ contains reserved IP addresses.
Aunque el ejemplo muestra 1.1.1.3, el texto de error se dispara con cualquier dirección en los bloques anteriores, incluidos formatos CIDR o listas separadas por comas.
Solución paso a paso
| Paso | Qué hacer | Por qué es necesario |
|---|---|---|
| 1 | Identifica la IP real que sale a Internet desde tu dispositivo o servicio (Proofpoint, firewall, servidor on‑premises). Revisa los registros o visita, desde el propio host, un sitio de “what is my IP”. | Exchange Online solo acepta IPs públicas, estáticas y enrutables. |
| 2 | Comprueba que la IP no esté en un bloque reservado. Los rangos más habituales son: • 0.0.0.0/8, 10.0.0.0/8 • 100.64.0.0/10 (CGNAT) • 127.0.0.0/8 • 169.254.0.0/16 • 172.16.0.0/12, 192.168.0.0/16 • 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 • 224.0.0.0/4 y 240.0.0.0/4 | Estos bloques jamás se enrutan en Internet y Exchange Online los bloquea. |
| 3 | Si la IP resulta ser privada o reservada, configura NAT o modifica la ruta de salida para usar una IP pública fija asignada por tu ISP. | Permite que Microsoft 365 valide la autenticidad del remitente y aplique reputación. |
| 4 | En el Centro de administración de Exchange (EAC), crea o edita el conector, indicando solo las IPs públicas válidas. | El conector utiliza la lista para confiar en el host remitente. |
| 5 | Ejecuta pruebas con “Comprobación de conectores” en el EAC o con el cmdlet Test‑InboundConnector. Examina los encabezados de los mensajes de prueba. | Verifica que los mensajes salgan exactamente por la IP pública declarada. |
| 6 | Si el problema persiste, abre un ticket a Soporte de Microsoft 365 y facilita: IP de origen, nombre y configuración del conector, hora y GUID del mensaje rechazado. | El soporte puede consultar los registros internos y aislar la causa. |
Detección y verificación de la IP saliente
En muchas empresas, el tráfico SMTP de varias sucursales converge en un mismo firewall o en un load‑balancer. Esto complica saber cuál es la IP pública vista por Microsoft. Para confirmarla:
- En la línea de comandos del servidor Windows que envía correo, ejecuta:
nslookup -querytype=TXT o365ip.ms
y consulta las rutas de egress. - Envía un correo de prueba a tu buzón de Outlook personal. En los encabezados del mensaje recibido (mensaje original) busca la primera entrada
Received: from. Allí verás la IP pública real. - Repite desde cada ubicación o dispositivo que pueda usar el conector.
Ejemplo práctico con PowerShell
Ejecutar en Exchange Online PowerShell v3
$myConnector = Get-InboundConnector -Identity "Relay Oficina Central"
if ($myConnector -eq $null) { Write-Host "Conector inexistente" -ForegroundColor Red }
Probar sintaxis e IP
Test-InboundConnector -Identity "Relay Oficina Central" -SenderAddress [admin@midominio.com](mailto:admin@midominio.com)
Si la prueba arroja el error de IP reservada, confirma inmediatamente la publicación de la IP en tu firewall:
Ejemplo genérico en un ASA / FTD show run | include nat | include smtp
Gestión de múltiples appliances o ubicaciones
Cuando existen varias puertas de enlace (por ejemplo, clusters de IronPort o appliances virtuales en distintas regiones), lo ideal es:
- Asignar un rango dedicado de IPs públicas para cada clúster.
- Añadir todas las IPs al conector, separadas por coma o usando notación CIDR si forman un bloque continuo.
- Documentar cada salto de NAT para simplificar auditorías y revisiones futuras.
- Sincronizar los firewall policies y las ACL para evitar que un dispositivo utilice la IP de otro clúster accidentalmente.
Buenas prácticas adicionales
- PTR coherente: crea un registro inverso (PTR) que apunte a un nombre FQDN alineado con SPF, DKIM y DMARC. Mejora la reputación ante filtros antispam.
- IPs empresariales o de centro de datos: Microsoft penaliza las IP residenciales o dinámicas. Usa bloques asignados a organizaciones.
- Límites de relay: restringe el conector a dominios específicos mediante la pestaña Scope en el EAC.
- Monitorización proactiva: habilita alertas de bloqueo de conectores y verifica los informes de “Anomalous Mail Flow” en el portal de cumplimiento.
- Revisiones periódicas: al cambiar de ISP o migrar a SD‑WAN, actualiza la lista de IPs en el conector y re‑ejecuta el cmdlet
Test‑InboundConnector.
Preguntas frecuentes
¿Puedo usar un rango /24 completo?
Sí, siempre que todas las direcciones pertenezcan a tu organización y sean enrutables. Sin embargo, añadir IPs que nunca enviarán correo puede exponer al dominio a suplantaciones.
¿Qué ocurre si mi ISP me cambia la IP pública?
Debe solicitarse bloque estático o actualizar el conector cada vez. De lo contrario, Exchange Online rechazará los correos con 550 5.7.1 debido a una “source IP mismatch”.
¿El error puede deberse a IPv6?
Sí, la lógica de validación es idéntica. Rangos como fc00::/7 y fe80::/10 (link‑local) también se rechazan.
Conclusión
El mensaje “IP range contains reserved IP addresses” es una salvaguarda esencial para la higiene del correo en Microsoft 365. Identificar la IP pública real, descartando rangos privados o de CGNAT, y registrar correctamente el conector resolverá el bloqueo de manera definitiva. Con las buenas prácticas descritas —PTR coherente, registros SPF/DKIM/DMARC alineados y pruebas recurrentes— garantizarás un flujo de correo seguro, trazable y respetuoso con las políticas antispam de Microsoft y de los receptores externos.