Ressources · 34
Fiabiliser l’envoi et la délivrabilité des emails
Vérifier identité de l’expéditeur, types de messages, désabonnement et causes de rejet.
· 8 min
Ce que ce guide permet
- Cartographier les flux
- Authentifier les domaines
- Faciliter le retrait
- Diagnostiquer les rejets
Contrôle express
- Quels systèmes expédient sous le domaine ?
- SPF, DKIM et DMARC sont-ils vérifiés sur les messages réels ?
- Le message est-il promotionnel ou transactionnel ?
- Le désabonnement requis fonctionne-t-il ?
- Les rejets sont-ils classés par cause ?
Méthode pas à pas
- 01
Inventorier les envois
Séparer newsletters, automatisations, reçus et alertes. Pour chaque flux, documenter domaine, prestataire, volume, raison d’envoi et responsable.
Livrable : carte des flux et domaines.
- 02
Vérifier l’authentification
Tester SPF, DKIM, DMARC et l’alignement du domaine From sur des exemples livrés. Une configuration DNS attendue ne prouve pas le résultat de chaque chemin d’envoi.
Livrable : en-têtes et résultats d’authentification contrôlés.
- 03
Clarifier l’attente du destinataire
Contrôler inscription, fréquence, contenu promis et séparation promotionnel/transactionnel. Éviter d’ajouter une publicité non attendue à un message de service.
Livrable : règles par type de message.
- 04
Tester le retrait
Pour les messages promotionnels concernés, vérifier lien visible et mécanisme one-click conforme aux exigences du fournisseur et à RFC 8058. Tester le traitement effectif du retrait.
Livrable : preuve de désabonnement de bout en bout.
- 05
Observer la réputation
Suivre rejets permanents et temporaires, plaintes et signaux fournis par les destinataires. Analyser par flux et fournisseur plutôt qu’une moyenne globale.
Livrable : diagnostic des causes de non-livraison.
- 06
Corriger et retester
Traiter d’abord authentification, listes non qualifiées, erreurs techniques et désabonnement défaillant. Reprendre les volumes progressivement selon le contexte.
Livrable : plan de correction et résultat observé.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Authentification | Messages réels avec résultats SPF/DKIM/DMARC attendus | Corriger le chemin d’envoi |
| Rejets | Taux et causes par flux | Nettoyer ou réparer |
| Retrait | Demandes promotionnelles appliquées | Réparer les en-têtes et le traitement |
| Plainte | Signalements suivis par campagne | Réviser ciblage et fréquence |
Erreurs fréquentes
- Supposer qu’un DNS publié prouve tous les flux
- Mélanger transactionnel et promotionnel
- Confondre ouverture et livraison en boîte de réception
- Afficher un lien de désabonnement qui ne retire pas réellement
Questions fréquentes
SPF seul suffit-il ?
Non. Les exigences varient selon le destinataire et le volume ; vérifier également DKIM, DMARC et l’alignement applicable.
Tous les messages nécessitent-ils le one-click ?
Les règles de fournisseur distinguent notamment messages promotionnels et transactionnels ; classer chaque flux avant de conclure.
Une ouverture prouve-t-elle une livraison ?
Non. Les métriques d’ouverture ont leurs propres limites et ne remplacent pas les résultats d’acheminement.
Sécurité email : identité, alignement et transport
L’authentification d’un domaine, la confidentialité du transport et l’arrivée en boîte de réception sont trois questions distinctes. SPF, DKIM et DMARC renseignent l’identité du domaine utilisé ; MTA-STS et DANE concernent les liaisons entre serveurs ; les rapports aident à observer les écarts. Aucun de ces signaux ne prouve que le contenu du message est bienveillant.
Références et statut consultés le .
Quel mécanisme répond à quelle question ?
| Mécanisme et source | Ce qui est contrôlé | Où chercher la preuve | Limite à retenir |
|---|---|---|---|
| SPF | Autorisation de l’IP d’envoi pour le domaine de l’enveloppe SMTP ; DMARC s’appuie sur MAIL FROM. | TXT du domaine évalué et résultat du serveur de réception. Limite de 10 termes déclenchant des recherches DNS pendant l’évaluation, pas simplement 10 requêtes réseau. | Un transfert peut changer l’IP observée. Plusieurs enregistrements SPF sélectionnés produisent permerror ; une réussite SPF ne prouve pas l’alignement avec From. |
| DKIM | Vérification cryptographique des parties signées du message, pour le domaine d= de la signature. | DKIM-Signature, sélecteur s=, domaine d= et clé publiée sous sélecteur._domainkey. RFC 8301 impose RSA ≥ 1 024 bits, recommande ≥ 2 048 bits et exclut rsa-sha1. | Une signature valide d’un autre domaine ne suffit pas pour DMARC. Les transformations des parties signées peuvent invalider la signature ; DKIM ne chiffre pas le message. |
| DMARC | Lien entre le domaine From visible et au moins un identifiant authentifié et aligné par SPF ou DKIM. | Politique TXT découverte via _dmarc et résultats fiables produits à la réception. Consigner le mode d’alignement et le domaine effectivement évalué. | pass n’est ni une garantie de livraison ni une appréciation du contenu. Le récepteur conserve sa politique locale ; les erreurs DNS et messages non conformes demandent un traitement distinct. |
| Rapports DMARC agrégés / d’échec | Observation des flux utilisant le domaine ; statistiques agrégées d’une part, informations sur des messages en échec d’autre part. | Destinations rua / ruf, période couverte et rapports reçus. Les formats sont désormais décrits dans deux RFC distincts de mai 2026. | Un rapport absent ne prouve pas l’absence d’envoi. Les rapports détaillés peuvent exposer des données de message ; prévoir accès, minimisation et conservation adaptés. |
| MTA-STS | Politique du domaine destinataire pour le transport SMTP TLS et les hôtes MX attendus. | TXT _mta-sts, politique HTTPS sous /.well-known/mta-sts.txt et certificat. Trois modes : testing, enforce et none. | Concerne les serveurs compatibles et le transport, sans fournir de chiffrement de bout en bout. La découverte initiale et le cache ont leurs propres limites. |
| TLS-RPT | Signalement des succès et échecs de négociation ou de validation TLS entre serveurs. | TXT _smtp._tls, destinations de rapports et données JSON reçues, rapprochées des journaux de transport. | Observer n’impose pas le chiffrement. Ne pas confondre ces rapports TLS avec les rapports DMARC sur l’identité du domaine. |
| DANE pour SMTP | Authentification du transport TLS à partir d’enregistrements TLSA protégés par DNSSEC. | Chaîne DNSSEC validée, TLSA du service SMTP et correspondance avec le certificat ou la clé présentée. | DNSSEC doit être validé dans ce chemin. DANE ne valide pas le domaine From et ne remplace pas SPF, DKIM ou DMARC. |
| ARC | Transmission d’évaluations d’authentification le long d’un chemin comportant des intermédiaires. | Jeux d’en-têtes ARC, validation de la chaîne et décision de confiance envers les intermédiaires. | RFC 8617 a le statut Experimental. ARC n’est pas un cadre de confiance et ne transforme pas automatiquement un message en message sûr ou livrable. |
DMARC en 2026 : ce qui change dans la documentation
- Référentiel
- RFC 9989, publié en mai 2026, remplace RFC 7489 et RFC 9091. Les rapports agrégés et d’échec sont séparés dans RFC 9990 et RFC 9991.
- Découverte et alignement
- Le texte définit un parcours DNS, dit DNS Tree Walk. Ne déduisez pas le domaine organisationnel en conservant naïvement les deux derniers labels.
- Déploiement en test
- pct est retiré ; le nouveau t=y demande, pour les messages en échec, un traitement d’un niveau inférieur : reject devient quarantine, quarantine devient none. t=n est le comportement par défaut.
- Interopérabilité
- Le standard déconseille p=reject pour les domaines de messagerie à usage général. Inventoriez les transferts et listes de diffusion et vérifiez les implémentations réellement utilisées avant une modification de politique.
La publication d’un RFC ne prouve pas que chaque fournisseur applique déjà cette version. Vérifiez sa documentation, les résultats observés et les exceptions de votre propre flux. Les exemples ici sont pédagogiques ; ils ne proposent aucun enregistrement DNS prêt à déployer. RFC 9989 →
Comprendre la logique DMARC avec un scénario
Modèle simplifié : un message From conforme, une politique DMARC déjà découverte, un résultat SPF MAIL FROM et une seule signature DKIM examinée. L’alignement est fourni par vous, selon le mode et les domaines évalués. L’outil ne résout aucun DNS, ne vérifie aucune signature et ne prédit aucune livraison.
(SPF pass ET aligné) OU (DKIM pass ET aligné)
Pour plusieurs signatures DKIM, vérifiez chaque couple résultat / d= : une seule signature valide et alignée peut suffire. N’associez pas le succès d’une signature au domaine aligné d’une autre signature en échec. Les erreurs de découverte DNS, l’absence de politique et un From invalide sortent de ce modèle. Tous les choix restent locaux dans votre navigateur.
Six cas pédagogiques, lisibles sans JavaScript
| Scénario | SPF : résultat / alignement | DKIM : résultat / alignement | Lecture attendue |
|---|---|---|---|
| SPF aligné suffit | pass — authentifié Oui | fail — échec constaté Non | pass — au moins une voie authentifiée et alignée La voie SPF satisfait les deux conditions. |
| DKIM aligné suffit | fail — échec constaté Non | pass — authentifié Oui | pass — au moins une voie authentifiée et alignée La voie DKIM satisfait les deux conditions, indépendamment de l’autre voie dans ce modèle. |
| Deux pass sans alignement | pass — authentifié Non | pass — authentifié Non | fail — aucune voie authentifiée et alignée dans ce scénario Le succès technique de deux domaines tiers ne valide pas From. |
| Domaines alignés, authentification absente | fail — échec constaté Oui | fail — échec constaté Oui | fail — aucune voie authentifiée et alignée dans ce scénario L’identité d’un domaine proche ne remplace pas une authentification réussie. |
| Preuves incomplètes | Résultat non renseigné Alignement non renseigné | fail — échec constaté Non | Indéterminé — compléter les observations L’absence de preuve sur une voie ne permet pas de l’inventer. |
| DKIM prouvé, SPF non renseigné | Résultat non renseigné Alignement non renseigné | pass — authentifié Oui | pass — au moins une voie authentifiée et alignée Une preuve positive complète suffit même si l’autre voie reste inconnue. |
Préparer une revue de messagerie exploitable
| Flux | Preuves à rapprocher | Décision utile |
|---|---|---|
| Alertes, reçus et réinitialisations | Prestataire et domaine From, identités d’enveloppe et DKIM, identifiant de suivi, réponse SMTP et événement de livraison disponible. | Séparer incident de transport, erreur d’authentification et absence de lecture. Définir une alternative pour le service critique. |
| Campagnes et newsletters | Domaines et sous-domaines utilisés, résultats d’alignement, échantillon représentatif de chaque plateforme, mécanisme de retrait et erreurs par flux. | Réparer le chemin d’envoi concerné avant de modifier une politique globale ; ne pas confondre authentification et attente du destinataire. |
| Transferts et listes de diffusion | Chemin avant/après intermédiaire, transformations du message, résultats SPF/DKIM et informations ARC lorsqu’elles existent. | Expliquer la rupture observée et la politique locale ; ne pas supposer qu’une chaîne ARC valide impose la réception. |
| Transport vers les MX | Politique MTA-STS ou TLSA pertinente, certificats, validation DNSSEC si DANE, rapports TLS et journaux horodatés. | Relier les échecs au serveur et à la période concernés. Tester les changements sur un périmètre autorisé et conserver un retour arrière. |
Prolonger avec la gouvernance des domaines et du DNS →
Sources primaires et dates de publication
Les dates ci-dessous sont celles des RFC, au mois près ; la date de consultation est distincte. Les descriptions et cas sont des synthèses éditoriales, pas des extraits normatifs complets.
- SPF · RFC 7208 · Proposed Standard · Publication :
§3.2, §4.5, §4.6.4 - DKIM · RFC 6376 · Internet Standard · Publication :
§3, §6 - DKIM cryptography · RFC 8301 · Proposed Standard · Publication :
§3.1–3.2 - DMARC · RFC 9989 · Proposed Standard · Publication :
§4.4, §4.7, §4.10, §5.3.5, §5.4, appendix C - DMARC aggregate reports · RFC 9990 · Proposed Standard · Publication :
§2–3 - DMARC failure reports · RFC 9991 · Proposed Standard · Publication :
§2–3; privacy considerations - MTA-STS · RFC 8461 · Proposed Standard · Publication :
§3, §5, §10.2 - SMTP TLS Reporting · RFC 8460 · Proposed Standard · Publication :
§3–4 - DANE for SMTP · RFC 7672 · Proposed Standard · Publication :
§2, §3 - ARC · RFC 8617 · Experimental · Publication :
§2, §7, appendix A.2
Références officielles
Pour aller plus loin
Analyses associées
