SPF, DKIM et DMARC : enregistrements, alignement et livraison
Choisissez le bon domaine et le bon sélecteur, interprétez le DNS et recherchez les causes des e-mails non reçus.
Équipe technique de check.uk.app · Vérifié le 26 septembre 2026
Partir des identités réelles du message
L’adresse From visible n’est pas nécessairement l’identité SPF. SPF évalue généralement le domaine de l’expéditeur de l’enveloppe SMTP ; DKIM utilise d= comme domaine de signature et s= comme sélecteur. DMARC vérifie l’alignement avec le domaine From visible : une validation SPF ou DKIM réussie et alignée peut satisfaire l’authentification. Utilisez les en-têtes originaux d’un message reçu dans une boîte que vous contrôlez.
Interroger les bons noms DNS
Remplacez example.com et selector1 par les identités fournies par votre prestataire de messagerie. Les trois commandes supposent que ces domaines coïncident ; interrogez chaque domaine réel séparément s’ils diffèrent. dig nécessite un paquet d’utilitaires DNS. Sans sélecteur, notre outil ne tente pas de découvrir les enregistrements DKIM.
dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.comInterpréter les résultats dans les limites du vérificateur
check.uk.app examine uniquement le nom d’hôte soumis. Il ne développe pas les chaînes include de SPF, n’applique pas l’héritage DMARC du domaine parent, ne vérifie pas les signatures des messages ni l’alignement. L’absence d’un enregistrement _dmarc sur un sous-domaine ne prouve donc pas qu’aucune politique DMARC ne s’applique.
Plusieurs enregistrements SPF commençant par v=spf1 pour un même nom constituent une erreur de configuration ; les autres TXT sont autorisés. Plusieurs chaînes entre guillemets dans un seul TXT ne sont pas plusieurs enregistrements SPF. Pour DKIM, un p= vide révoque la clé ; une clé publiée ne prouve pas, à elle seule, que les messages sortants sont correctement signés.
Modifier les enregistrements selon les données du prestataire
Recensez tous les expéditeurs légitimes avant de modifier SPF. Maintenez un seul enregistrement SPF par domaine évalué et respectez la limite de recherches DNS du standard. Publiez DKIM exactement comme fourni pour le sélecteur ; ne remplacez pas aveuglément des clés en cours d’utilisation.
Commencez les changements DMARC par l’observation et l’analyse des sources d’envoi légitimes. p=none ne demande ni quarantaine ni rejet au titre de DMARC, mais ne garantit pas l’arrivée dans la boîte de réception. Configurez une boîte que vous contrôlez pour les rapports et confirmez toute autorisation nécessaire pour les rapports externes. Renforcez la politique seulement après avoir vérifié l’alignement.
Enquêter sur la livraison au-delà du DNS
Pour un e-mail d’inscription manquant, retrouvez l’événement de l’application, l’entrée de la file d’attente et la réponse SMTP au même instant. Une acceptation SMTP ne prouve pas l’arrivée dans la boîte de réception. Examinez les rejets, le dossier spam du destinataire et les Authentication-Results fiables du prestataire récepteur. Ne faites pas confiance à des en-têtes d’authentification arbitraires ajoutés par l’expéditeur.
Sauvegardez les valeurs DNS et TTL avant toute modification. Après publication, vérifiez les réponses faisant autorité et récursives, puis envoyez un message contrôlé à votre propre boîte. Comparez l’authentification avant et après ; l’expiration des caches peut retarder les changements. Restaurez les enregistrements si des expéditeurs légitimes échouent. check.uk.app n’envoie aucun e-mail pendant ce test.
