Les outils de vérification d'adresse transforment parfois une seule réponse SMTP en un verdict définitif « la boîte aux lettres existe ». Cette étiquette cache plusieurs observations différentes : si une route existe, si un serveur a accepté une commande du destinataire et si un message a finalement atteint une boîte aux lettres. Gardez ces observations séparées lorsque vous décidez de corriger une adresse ou de contacter un client.
Enregistrer l'étape de la transaction
Dans SMTP , RCPT TO identifie un destinataire pour la transaction en cours. Une réponse réussie à ce stade ne signifie pas que le serveur a accepté le corps du message. L'acceptation finale suit normalement la finalisation des DONNÉES. Le récepteur pourrait être un relais intermédiaire plutôt que le système de boîte aux lettres final. RFC 5321 sections 3.3 et 4.1.1.3.
Enregistrez la réponse exacte, l'horodatage, l'itinéraire de correspondance, expéditeur d'enveloppe et serveur de réception. Un refus temporaire n’est pas la même chose qu’une erreur permanente du destinataire. Un rejet de politique générique peut refléter le client ou la transaction plutôt que l'absence de destination. Ne réduisez pas tous les 550 à « cette personne n’existe pas » et n’interprètez pas un délai d’attente comme une réponse négative de l’annuaire.
Comparez trois politiques de destinataires hypothétiques
Supposons qu'un récepteur sélectif renvoie 250 pour known@example.test et 550 pour unknown@example.test . Une politique d'acceptation -all différente pourrait renvoyer 250 pour les deux, tandis qu'un échec temporaire pourrait renvoyer 451 pour les deux. Ces réponses supposées ne peuvent à elles seules établir la livraison vers une boîte aux lettres distincte pour l’une ou l’autre adresse.
Il s’agit de cas de politique inventés, et non de contrôles de destinataires exécutés ou d’une description d’un quelconque domaine public. Le fait est qu’une réponse visible peut s’adapter à plusieurs configurations sous-jacentes. Les preuves d'annuaire et de routage autorisées peuvent les distinguer ; une sonde répétée ne résout pas automatiquement l’incertitude.
Utiliser un chemin de vérification légitime
Pour une adresse dans un système que vous administrez, consultez le répertoire autorisé ou le propriétaire de la boîte aux lettres, y compris les alias, les groupes et les règles de routage. Pour un contact externe, préférez un canal de communication établi ou un workflow de confirmation basé sur le consentement. La confirmation réussie d'un message spécifique constitue une preuve d'accès plus solide qu'une enquête SMTP spéculative, mais elle ne prouve toujours pas l'identité juridique d'une personne ni son consentement général au marketing.
N'énumérez pas les adresses de tiers et n'interrogez pas les destinataires à plusieurs reprises simplement parce qu'un outil le permet. Respectez les règles du service et évitez de transformer un contrôle de qualité de contact en trafic abusif. Testez uniquement dans un périmètre autorisé, avec une cadence et des conditions d'arrêt définies.
Rapporter un verdict limité
Utilisez des étiquettes telles que « commande du destinataire acceptée », « refus temporaire », « refus permanent avec diagnostic » et « non établi ». Préservez les preuves sous-jacentes afin qu’un réviseur ultérieur puisse les réinterpréter. Si la livraison est importante, suivez un message réel autorisé jusqu'à l'acceptation finale et la confirmation du destinataire plutôt que de présenter le succès du RCPT comme une garantie de la boîte de réception. Les contrôles d'authentification restent une tâche différente : l'acceptation du destinataire ne prouve pas SPF, DKIM ou DMARC passé.
Reconnaître un rejet ultérieur au sein de la même transaction
Dans un autre échange hypothétique, RCPT TO reçoit 250, DATA reçoit 354 et la réponse finale après le contenu du message est 554. 5.7.1. La commande du destinataire a réussi, mais le serveur n'a finalement pas accepté le message. Il s'agit d'un refus au cours de la transaction, et non d'un rebond ultérieur après acceptation. Une réponse 354 est une autorisation de transmettre du contenu, et non un résultat de livraison.
L'exemple prend en charge une étiquette précise : commande du destinataire acceptée ; message rejeté après DATA. Il n'établit pas si la boîte aux lettres du destinataire existe, pourquoi un fournisseur public applique une politique ou si l'authentification de l'expéditeur a réussi. Aucune connexion SMTP ou vérification de boîte aux lettres n'a été effectuée pour cet exemple.
Utilisez une échelle de preuves
- Syntaxe ou route DNS trouvée : aucune des deux n'établit de boîte aux lettres.
- RCPT accepté : rapporte uniquement le résultat de la commande du destinataire.
- DONNÉES finales acceptées : identifier le système acceptant ; la livraison ultérieure reste séparée.
- Confirmation du destinataire autorisé : enregistrez l'adresse spécifique, le but et l'heure.
- Non résolu : conserver l'incertitude au lieu de forcer la validité ou la non-validité.