Référence pour suivre un message de l’envoi à la réception et diagnostiquer transport SMTP, SPF, DKIM, DMARC, alignement et réputation.
Ports & rôles SMTP
Port standard des échanges entre MTA ; souvent filtré en sortie chez les particuliers.
Port recommandé pour client/app authentifié avec STARTTLS
Couramment proposé par les fournisseurs pour TLS dès la connexion.
Accès boîte aux lettres, distinct de l’envoi SMTP.
Codes SMTP à reconnaître
250 indique généralement que l’étape SMTP a été acceptée.
Le MTA émetteur doit normalement retenter plus tard.
Vérifiez adresse, domaine et routage du destinataire.
Souvent lié à relais, anti-spam, SPF/DKIM/DMARC ou droits.
SPF
Le SPF est publié en TXT ; plusieurs enregistrements SPF séparés rendent la politique invalide.
Autorise l’infrastructure déclarée puis refuse les autres sources.
Les include, a, mx, exists et redirect peuvent consommer la limite.
Resolve-DnsName exemple.fr -Type TXTContrôlez qu’un seul SPF v=spf1 est publié.
DKIM
Permet plusieurs clés et rotations sans changer le domaine From.
Le DNS contient la clé publique ; la clé privée reste uniquement côté service émetteur.
Resolve-DnsName selector1._domainkey.exemple.fr -Type TXTUtilisez le sélecteur visible dans l’en-tête DKIM-Signature.
Conservez un chevauchement suffisant pour les messages encore en transit.
DMARC & alignement
La politique DMARC est publiée sous _dmarc.
Commencez souvent par none pour observer avant enforcement.
Un SPF pass seul ne suffit pas si le domaine n’est pas aligné.
DMARC passe si au moins un mécanisme aligné réussit.
DNS & tests de connectivité
Resolve-DnsName exemple.fr -Type MXVérifie les serveurs de réception publiés.
Resolve-DnsName _dmarc.exemple.fr -Type TXTContrôle politique et adresses de reporting.
Test-NetConnection smtp.exemple.fr -Port 587Valide seulement le TCP, pas l’authentification ni l’envoi.
openssl s_client -starttls smtp -connect smtp.exemple.fr:587 -servername smtp.exemple.frInspecte certificat et négociation STARTTLS depuis un système disposant d’OpenSSL.
En-têtes à analyser
Lisez de bas en haut pour reconstituer le chemin initial vers le destinataire.
C’est souvent la preuve la plus utile d’un échec d’authentification.
Utilisée dans l’évaluation SPF et le traitement des bounces.
À conserver pour corrélation dans les traces de messagerie.
Ordre de diagnostic
Confirmez que le message atteint le bon service avant l’authentification de domaine.
Identifiez la vraie source d’envoi, notamment pour applications et relais.
Vérifiez pass/fail et surtout l’alignement avec From.
Un message authentifié peut toujours être bloqué par contenu ou réputation.
À retenir
- Ne publiez qu’un seul enregistrement SPF v=spf1 par domaine.
- N’activez pas p=reject tant que toutes les sources d’envoi légitimes ne sont pas identifiées.
- Ne partagez jamais une clé privée DKIM dans un ticket ou un outil web.
- Conservez les en-têtes complets d’un message rejeté : ils valent souvent mieux qu’une capture d’écran.