Lors de la création d’un connecteur SMTP entrant dans Exchange Online, l’erreur « IP range … contains reserved IP addresses » indique que la plage saisie n’est pas routable sur Internet. Voici un guide détaillé pour diagnostiquer et corriger le problème de façon durable.
Vue d’ensemble de la question
Lors de l’ajout ou de la mise à jour d’un connecteur entrant (Inbound connector) dans Exchange Online, vous obtenez :
Unable to create a connector. IP range ‘1**.1*.1.3*’ contains reserved IP addresses.
Le service refuse donc l’adresse ou la plage d’adresses IP déclarée pour le relais SMTP.
Pourquoi l’erreur apparaît
Un connecteur entrant Exchange Online validé par adresse IP exige des adresses publiques, fixes et routables sur Internet. Les plages privées ou spéciales (réservées, lien local, loopback, CGNAT, multicast, etc.) sont interdites, car elles ne permettent pas à Microsoft 365 d’identifier de manière fiable la source du trafic SMTP.
Plages IPv4 non autorisées courantes
| Plage | Type | Pourquoi interdit | Exemple de symptôme |
|---|---|---|---|
| 10.0.0.0/8 | Privée (RFC 1918) | Non routable sur Internet | Erreur « contains reserved IP addresses » à l’enregistrement |
| 172.16.0.0/12 | Privée (RFC 1918) | Non routable sur Internet | Même symptôme |
| 192.168.0.0/16 | Privée (RFC 1918) | Non routable sur Internet | Même symptôme |
| 169.254.0.0/16 | Lien local / Auto-IP | Adresses auto‑attribuées, non routables | Détection d’une IP « 169.254.x.x » dans des logs locaux |
| 100.64.0.0/10 | CGNAT (RFC 6598) | Partagée par l’ISP, pas d’identité unique | Flux sortants masqués par l’opérateur |
| 127.0.0.0/8 | Loopback | Interface locale, jamais routée | Non applicable au trafic SMTP sortant |
| 0.0.0.0/8 | Spéciale | Adresse non spécifique, non routable | Souvent liée à une mauvaise détection d’IP |
| 224.0.0.0/4 | Multicast | Non utilisé pour SMTP | Invalide à l’enregistrement |
| 240.0.0.0/4 | Réservée | Non routable en pratique | Invalide à l’enregistrement |
Plages IPv6 non autorisées courantes
| Plage | Type | Pourquoi interdit | Exemple de symptôme |
|---|---|---|---|
| fc00::/7 | Unique Local (ULA) | Non routable globalement | Refus si déclarée dans le connecteur |
| fe80::/10 | Lien local | Non routable | Invalide |
| ::1/128 | Loopback | Local uniquement | Invalide |
Diagnostic rapide
Avant toute modification, validez ces points :
- Votre relais SMTP sort-il réellement avec une IP publique fixe ? S’il sort via un NAT d’opérateur (CGNAT) ou via plusieurs IP, Exchange Online ne peut pas vous reconnaître.
- La plage saisie contient‑elle uniquement des IP publiques routables ? Bannissez toute IP privée/speciale.
- Vos journaux et en‑têtes de mails confirment‑ils la même IP ? Une divergence = un autre NAT s’interpose.
Identifier la véritable IP source
Depuis votre appliance ou passerelle
- Ouvrez les journaux de votre passerelle SMTP (serveur Edge, Proofpoint, Cisco ESA, FortiMail, etc.).
- Repérez l’adresse publique de sortie utilisée pour les connexions vers outlook.com / *.protection.outlook.com.
À partir d’un message déjà remis
Récupérez un e‑mail envoyé via votre infrastructure vers une boîte Microsoft 365 et lisez ses en‑têtes. Cherchez la première ligne Received: côté Microsoft 365 :
Received: from mail.example-relay.local (203.0.113.45)
by ... .protection.outlook.com (version=TLS1_2 cipher=...) with SMTP;
Tue, 23 Jul 2024 10:15:23 +0000
Ici, 203.0.113.45 (plage de documentation) est l’adresse vue par Exchange Online. C’est celle qu’il faut déclarer dans le connecteur, pas une IP privée interne ni une IP masquée par un autre NAT.
Attention aux environnements multi‑sorties
- Load balancer / HA pair : deux nœuds différents peuvent sortir par deux IP publiques distinctes.
- Pare‑feux multiples : selon la route active, l’e‑gress change.
- Cloud / IaaS : sans IP élastique dédiée, l’e‑gress peut basculer.
Corriger le connecteur dans le Centre d’administration Exchange
- Ouvrez Exchange Admin Center > Mail flow > Connectors.
- Add a connector (ou modifiez l’existant).
- Choisissez le type :
- On‑premises (hybride), ou
- Partner organization (passerelle tierce).
- Dans la section How do you want to identify the partner, choisissez By verifying the sender IP address.
- Renseignez uniquement l’IP publique (ou la plage CIDR) réellement utilisée (ex.
203.0.113.45/32pour une IP unique). - Enregistrez.
Évitez d’entrer une plage couvrant des blocs interdits (par ex. 203.0.112.0/20 si cela englobe des IP réservées). La saisie doit cibler exclusivement des IP publiques routables.
Équivalents PowerShell Exchange Online
Connexion (module Exchange Online PowerShell v2) :
Connect-ExchangeOnline
Créer un connecteur partenaire IP‑based :
New-InboundConnector `
-Name "Relay - Partner" `
-ConnectorType Partner `
-SenderIPAddresses 203.0.113.45 `
-RequireTls $true `
-RestrictDomainsToIPAddresses $true `
-SenderDomains "*"
Mettre à jour un connecteur existant :
Set-InboundConnector `
-Identity "Relay - Partner" `
-SenderIPAddresses 203.0.113.45,198.51.100.27
Vérifier la valeur actuelle :
Get-InboundConnector "Relay - Partner" | fl Name,ConnectorType,SenderIPAddresses,RequireTls,SenderDomains
Validation côté réseau
- Sortie SMTP 25/TCP : autorisée depuis l’IP publique déclarée vers Microsoft 365. Pas de filtrage sortant qui force un autre NAT.
- NAT statique : fixez une traduction source statique pour l’IP du relais.
- Pas de CGNAT : si votre FAI applique le CGNAT, demandez une IP publique fixe dédiée.
- Reverse DNS : en dehors du connecteur, configurez un PTR cohérent (bon pour la réputation).
- SPF : ajoutez l’IP (ou l’include de votre passerelle) à votre enregistrement SPF.
Checklist de contrôle
| Élément | Où regarder | Comment | Résultat attendu |
|---|---|---|---|
| IP e‑gress réelle | Logs passerelle / en‑têtes | Rechercher la première IP « Received » vue par Microsoft | Une IP publique unique |
| Stabilité NAT | Pare‑feu | Règle SNAT dédiée | Pas de bascule d’IP |
| Ouverture 25/TCP | Firewall e‑gress | Vérifier policy/route | Flux vers *.protection.outlook.com |
| Connecteur EXO | EAC / PowerShell | SenderIPAddresses exactes | Uniquement IP publiques |
Scénarios fréquents et corrections
| Scénario | Symptôme | Cause | Correction |
|---|---|---|---|
| Relais derrière CGNAT | Erreur à la création | IP source 100.64.0.0/10 | Commander une IP publique fixe dédiée |
| Deux pare‑feux en actif/actif | Remises aléatoires / intermittentes | IPs e‑gress différentes | Déclarer les 2 IP, ou forcer un e‑gress unique |
| Appliance en cluster | Divergence de connecteur | SNAT par nœud | SNAT commun / VIP e‑gress |
| Range trop large | Refus « contains reserved » | La plage englobe un bloc réservé | Réduire la plage au strict nécessaire |
| Adresse privée saisie | Refus immédiat | RFC 1918 | Remplacer par IP publique routable |
Format de saisie des adresses IP
- IP unique :
203.0.113.45 - Plage CIDR :
198.51.100.0/28(16 adresses) - Plusieurs IP : séparez par des virgules en PowerShell, ajoutez‑les une par une dans l’EAC
Évitez les plages start‑end (203.0.113.10-203.0.113.20) si votre interface ne les supporte pas explicitement. Le format CIDR est la méthode la plus stable.
Tests et validation après modification
- Relance d’un envoi de test vers une boîte M365 et vérification des en‑têtes
Received. - Traçage (Message trace) depuis le Centre de sécurité & conformité pour confirmer la connexion via le connecteur.
- Vérification PowerShell de la configuration :
Get-InboundConnector | ft Name,ConnectorType,SenderIPAddresses - Surveillance de la réputation et des NDR éventuels (4xx/5xx) pour affiner SPF/DKIM/TLS si nécessaire.
Scripts utiles côté administrateur
Détecter une adresse privée/réservée en PowerShell
# Renvoie $true si l'IP est privée ou réservée (simplifié IPv4)
function Test-PrivateOrReservedIPv4 {
param([string]$Ip)
if (-not [System.Net.IPAddress]::TryParse($Ip, [ref]([System.Net.IPAddress]$null))) { return $true }
$bytes = ([System.Net.IPAddress]::Parse($Ip)).GetAddressBytes()
$b0,$b1 = $bytes[0],$bytes[1]
switch ($true) {
{ $b0 -eq 10 } { return $true } # 10.0.0.0/8
{ $b0 -eq 172 -and $b1 -ge 16 -and $b1 -le 31 } { return $true } # 172.16.0.0/12
{ $b0 -eq 192 -and $b1 -eq 168 } { return $true } # 192.168.0.0/16
{ $b0 -eq 169 -and $b1 -eq 254 } { return $true } # 169.254.0.0/16
{ $b0 -eq 100 -and $b1 -ge 64 -and $b1 -le 127 } { return $true } # 100.64.0.0/10
{ $b0 -eq 127 } { return $true } # 127.0.0.0/8
{ $b0 -eq 0 } { return $true } # 0.0.0.0/8
{ $b0 -ge 224 } { return $true } # 224.0.0.0/4 et 240.0.0.0/4
default { return $false }
}
}
Utilisez cette fonction pour filtrer rapidement une liste d’IP candidates avant saisie dans le connecteur.
Bonnes pratiques d’architecture
- Centraliser la sortie SMTP derrière une ou deux IP publiques fixes maximum, documentées.
- Séparer l’e‑gress mail du reste du trafic Internet pour éviter tout changement d’IP imprévu.
- Verrouiller la configuration NAT (SNAT source) et versionner les règles pare‑feu.
- Aligner l’identité DNS (PTR/rDNS, HELO/EHLO, SPF, DKIM) pour une meilleure délivrabilité.
- Surveiller les changements chez les prestataires de sécurité mail (plages d’IP pouvant évoluer). Si les IP changent souvent, envisagez l’authentification par certificat plutôt que par IP.
Quand escalader au support
Si l’erreur persiste après correction :
- Ouvrez un ticket Microsoft 365 et joignez :
- La configuration du connecteur (captures EAC ou sortie
Get-InboundConnector). - Des extraits de journaux montrant l’IP source et les tentatives de connexion.
- Un message de test avec en‑têtes complets.
- La configuration du connecteur (captures EAC ou sortie
- Demandez la vérification côté Microsoft des logs de transport pour confirmer l’IP vue à l’entrée.
FAQ
Puis‑je déclarer une plage très large pour “être tranquille” ?
Non. Outre l’aspect sécurité, une plage large risque d’englober des blocs réservés et sera refusée. Déclarez uniquement les IP nécessaires.
Mon prestataire e‑mail change d’IP sans prévenir. Que faire ?
Privilégiez un connecteur basé sur certificat plutôt que sur IP, ou exigez une IP dédiée contractuellement.
Le connecteur est valide mais mes mails sont rejetés
Cela peut provenir d’autres contrôles (TLS requis, SPF/DKIM/DMARC, réputation). Le connecteur IP règle l’authentification de la source, pas la réputation globale.
Exemple de procédure complète
- Identifier l’IP e‑gress via en‑têtes ou journaux (
203.0.113.45). - Vérifier qu’elle n’est pas privée (voir tableau).
- Forcer le NAT source vers cette IP si nécessaire.
- Déclarer l’IP dans le connecteur EAC/PowerShell.
- Tester un envoi vers M365 et confirmer l’IP dans
Received. - Documenter le changement et mettre à jour l’inventaire (NAT, EAC, SPF).
Modèle de documentation à réutiliser
Titre: Relais SMTP > Exchange Online (connecteur entrant)
IP publique e‑gress: 203.0.113.45 (/32)
Type de connecteur: Partner
Authentification: IP address + TLS requis
SenderDomains: *
Règles NAT: SNAT fixe depuis 10.20.30.40 vers 203.0.113.45 pour TCP/25
Pare-feu sortant: Autorisé vers *.protection.outlook.com:25
SPF: v=spf1 ip4:203.0.113.45 include:gateway.example -all
Contact FAI: support@isp.example (ticket #123456)
Date & Change ID: 2025-09-10 / CHG-04567
Résumé opérationnel
Cette erreur se corrige en remplaçant toute IP privée ou spéciale par l’IP publique e‑gress réelle et fixe de votre relais, en consolidant le NAT source, puis en validant via un envoi de test et le traçage. Documentez et surveillez. Si doute persistant, sollicitez le support avec des journaux précis.
Annexe : rappel des plages interdites
IPv4 : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, 100.64.0.0/10, 127.0.0.0/8, 0.0.0.0/8, 224.0.0.0/4, 240.0.0.0/4.
IPv6 : fc00::/7, fe80::/10, ::1/128 (et, de manière générale, toute adresse non globale).
Conclusion
En Exchange Online, un connecteur IP‑based doit refléter exactement l’adresse publique de votre trafic SMTP sortant. La moindre présence d’une adresse réservée dans la plage saisie entraîne un refus immédiat. En identifiant la véritable IP e‑gress, en l’isolant via un NAT statique et en la déclarant précisément dans le connecteur, vous rétablissez un chemin de remise fiable, sécurisé et conforme aux bonnes pratiques de Microsoft 365.