Cette application s'exécute sur le serveur
Comment ça marche
Le protocole de messagerie ne vérifie pas l'expéditeur : n'importe quel serveur peut mettre votre domaine comme expéditeur. Trois enregistrements DNS ferment cette porte. SPF liste les serveurs autorisés à envoyer au nom du domaine. DKIM signe chaque message avec une clé privée dont la partie publique est publiée dans le DNS. DMARC relie les deux : il exige qu'au moins l'un réussisse et corresponde au domaine visible de l'expéditeur, indique au destinataire quoi faire des échecs et demande des rapports sur tout ce qui a été envoyé en votre nom.
Depuis février 2024, Gmail et Yahoo exigent SPF, DKIM et DMARC de quiconque envoie plus de 5 000 messages par jour à leurs utilisateurs, et l'absence de l'un d'eux se traduit par des e-mails rejetés ou classés en spam. D'où l'intérêt de vérifier les trois ensemble : un SPF impeccable sert peu sans DMARC, et un DMARC en reject avec un DKIM mal publié bloque votre propre courrier.
La vérification s'effectue depuis notre serveur avec des requêtes DNS publiques, comme le ferait n'importe quel serveur de messagerie. Le SPF est évalué entièrement, en suivant chaque include et redirect pour compter les requêtes DNS, car dépasser la limite de 10 annule tout l'enregistrement. Les enregistrements MX et les enregistrements facultatifs MTA-STS, TLS-RPT et BIMI sont aussi interrogés.
Exemples
github.comSPF · 10 / 10Huit includes de fournisseurs (Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…) et ceux qu'ils incluent amènent l'évaluation pile à la limite de 10 requêtes DNS. Un fournisseur de plus et tout le SPF renverrait une erreur permanente.example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sLa bonne configuration pour un domaine qui n'envoie ni ne reçoit d'e-mails : MX nul, SPF qui n'autorise personne et DMARC en reject. Elle protège les domaines parqués, cible fréquente de l'usurpation.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %Un déploiement progressif : seul un message en échec sur quatre part en spam, et les rapports arrivent à la boîte indiquée dans rua pour repérer les expéditeurs légitimes pas encore authentifiés.Cas d'usage
- Diagnostiquer pourquoi les e-mails du domaine arrivent en spam ou sont rejetés par Gmail, Outlook ou Yahoo.
- Vérifier que le SPF ne dépasse pas 10 requêtes DNS avant d'ajouter un nouveau fournisseur d'envoi, comme un CRM ou une plateforme de newsletters.
- Vérifier que la clé DKIM d'un fournisseur a été correctement publiée après sa configuration.
- Planifier le passage de DMARC de none à quarantine puis à reject sans couper le courrier légitime.
- Auditer les domaines d'un client ou d'une entreprise rachetée, y compris les domaines parqués qui ne devraient pas envoyer d'e-mails.
- Examiner la configuration d'un expéditeur suspect lors de l'analyse d'un hameçonnage.
Questions fréquentes
Pourquoi indique-t-il qu'aucun DKIM n'a été trouvé alors que mon domaine signe ses e-mails ?
Parce que DKIM ne permet pas de lister les clés d'un domaine : chacune se trouve en <sélecteur>._domainkey.<domaine> et il faut connaître le sélecteur pour l'interroger. L'outil essaie les sélecteurs les plus courants, mais beaucoup de fournisseurs utilisent des noms propres ou datés. Ouvrez un e-mail envoyé depuis le domaine, cherchez l'en-tête DKIM-Signature et copiez la valeur de s= ; avec ce sélecteur, la vérification est exacte.
Que se passe-t-il si le SPF dépasse 10 requêtes DNS ?
La RFC 7208 oblige le destinataire à renvoyer une erreur permanente (permerror), ce qui compte comme un échec SPF pour DMARC. Les mécanismes include, a, mx, ptr et exists et le modificateur redirect consomment des requêtes, y compris ceux présents dans chaque include ; ip4 et ip6 n'en consomment pas. Pour réduire le nombre, retirez les fournisseurs inutilisés, remplacez des includes par des plages ip4 ou envoyez depuis des sous-domaines ayant leur propre SPF.
~all ou -all ?
Avec DMARC en place, la différence est faible : le destinataire applique la politique DMARC et non le qualificatif SPF. ~all est la norme, car certains destinataires rejettent immédiatement avec -all avant d'évaluer DKIM, ce qui peut faire perdre des e-mails transférés que DKIM aurait sauvés. Sans DMARC, -all est le seul moyen de demander le rejet de ce qui n'est pas autorisé.
Comment passer DMARC de none à reject sans perdre d'e-mails ?
Commencez en p=none avec une adresse dans rua et lisez les rapports agrégés pendant quelques semaines : ils montrent chaque serveur qui envoie avec votre domaine et s'il passe SPF ou DKIM. Authentifiez les expéditeurs légitimes manquants, passez à quarantine avec un pct faible, augmentez pct progressivement et terminez en reject. Passer directement à reject bloque souvent des outils de facturation, des CRM ou des systèmes internes oubliés.
Une clé DKIM de 1024 bits suffit-elle ?
Elle fonctionne, car la RFC 8301 impose aux destinataires d'accepter les clés de 1024 à 4096 bits, mais la même norme recommande aux signataires d'utiliser au moins 2048. Les clés de moins de 1024 bits ne sont pas considérées comme valides. Passer à 2048 est simple : on publie la nouvelle clé sous un autre sélecteur, on change la signature, puis on révoque l'ancienne en laissant p vide.
À quoi servent MTA-STS, TLS-RPT et BIMI ?
MTA-STS (RFC 8461) demande aux serveurs expéditeurs d'exiger TLS lors de la livraison vers vos MX, ce qui empêche les attaques qui rabaissent la connexion en texte clair. TLS-RPT (RFC 8460) vous envoie des rapports quand ces livraisons échouent. BIMI affiche le logo de la marque à côté de l'expéditeur dans les clients qui le prennent en charge, et ne fonctionne qu'avec DMARC en quarantine ou reject. Aucun n'est obligatoire, mais les trois comptent.