SPF en pratique : recenser tous les expéditeurs

Module 4: Délivrabilité : SPF, DKIM et DMARC en pratique · Temps de lecture : 12 minutes

Objectif pédagogique : Après cette leçon, vous saurez repérer tous les services qui envoient des e-mails au nom de votre domaine, les regrouper dans un seul enregistrement SPF, compter les recherches récursivement jusqu'à la limite de dix, et choisir en connaissance de cause entre ~all et -all.

Notions clés : inventaire des expéditeurs, expéditeur d'enveloppe (Return-Path), un seul enregistrement SPF, include, redirect, limite de 10 recherches DNS (RFC 7208 paragraphe 4.6.4), recherches vides (void lookups, deux maximum), comptage récursif, permerror, flattening, SPF pour les sous-domaines, SPF sur un domaine qui n'envoie pas de courrier, ~all et -all

Petit rappel

Un enregistrement SPF est un enregistrement TXT sur votre domaine qui commence par v=spf1 et énumère les serveurs autorisés à envoyer du courrier au nom de votre domaine. La structure, les caractères + - ~ ? et les trois erreurs les plus courantes (deux enregistrements, +all, plus de dix recherches) sont expliqués dans le cours DNS, leçon 4.3. Lisez-la d'abord si le SPF est nouveau pour vous. Cette leçon traite de la partie délicate : en pratique, presque personne ne sait précisément qui envoie du courrier au nom de son domaine.

Étape 1 : l'inventaire

Le SPF ne fonctionne que si tous les expéditeurs y figurent. Si vous en oubliez un, son courrier finira en spam ou sera refusé dès que vous durcirez votre politique DMARC. Parcourez donc cette liste. Dans une petite entreprise moyenne, vous en trouvez déjà facilement cinq ou six :

Deux bonnes méthodes pour les trouver :

1. Lire les en-têtes. Envoyez-vous à vous-même un e-mail depuis chaque système (une facture, une réinitialisation de mot de passe, une newsletter test) et examinez dans les en-têtes les champs Return-Path et Authentication-Results (leçon 1.5). Vous y verrez par quel domaine et quel serveur il est passé.
2. Rapports DMARC. Configurez DMARC en p=none avec une adresse de rapport (leçon 4.4). Après quelques semaines, les rapports (leçon 4.5) vous montreront chaque serveur ayant envoyé du courrier au nom de votre domaine, y compris ceux que vous aviez oubliés. C'est l'inventaire le plus fiable.

Tous les services ne doivent pas figurer dans votre SPF

C'est souvent ici que les choses se compliquent. Le SPF examine l'expéditeur d'enveloppe (le Return-Path), et non l'adresse De. De nombreux services de newsletter et d'envoi utilisent un Return-Path sur leur propre domaine, par exemple bounce-123@mail.mailer.example. Le destinataire vérifie alors l'enregistrement SPF de mailer.example, pas le vôtre. Un include de ce service dans votre enregistrement ne sert alors à rien, sinon à coûter une recherche.

Ce dont ce service a réellement besoin pour passer le contrôle DMARC, c'est d'une signature DKIM avec votre domaine (leçon 4.3), ou d'un sous-domaine Return-Path qui vous appartient (par exemple bounce.example.com en CNAME vers le service). Consultez donc la documentation du service pour savoir ce qu'il demande. S'il indique « ajoutez include: à votre SPF », faites-le. S'il indique seulement « créez ces enregistrements CNAME pour le DKIM et le domaine de retour », alors rien ne doit être ajouté à votre enregistrement principal. Le module 7 approfondit ce sujet.

Étape 2 : un seul enregistrement, et bien compter

Tous les expéditeurs vont dans un seul enregistrement. Supposons que votre inventaire donne : le serveur de messagerie de votre hébergeur, Microsoft 365 pour quelques collaborateurs, votre logiciel de comptabilité et une assistance technique. L'enregistrement devient alors par exemple :

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Combien cela fait-il de recherches ? Comptez chaque a, mx, include, exists, ptr et redirect, puis comptez aussi tout ce qui figure dans les enregistrements derrière chaque include :

À 11, le destinataire renvoie une permerror : l'ensemble de l'enregistrement SPF n'est alors plus pris en compte, pour aucun expéditeur. Le courrier de votre propre serveur de messagerie est donc moins bien évalué parce que l'assistance technique coûte trois recherches. Et le plus traître, c'est que votre enregistrement peut être à 9 aujourd'hui et à 11 demain, sans que vous ayez rien changé, parce qu'un service a étendu son propre enregistrement.

De plus : deux recherches vides au maximum

Le RFC 7208 mentionne aussi les void lookups : des recherches qui ne donnent aucun résultat (le nom n'existe pas, ou n'a pas d'enregistrement SPF ni d'adresse). Plus de deux de ces recherches entraîne également une permerror. Cela se produit surtout avec d'anciens includes de services que vous n'utilisez plus et qui ont supprimé leur enregistrement, ou avec un a: vers un serveur qui n'existe plus. Il faut donc faire le ménage.

Étape 3 : repasser sous la barre des dix

Si vous dépassez dix, il existe quatre solutions, de la meilleure à la moins bonne :

1. Supprimez ce qui n'est pas nécessaire. Les services que vous n'utilisez plus. Les services qui envoient avec leur propre Return-Path (voir ci-dessus) et qui n'ont donc rien à faire dans votre SPF. a si votre site web lui-même n'envoie pas de courrier. mx si votre MX pointe vers un service déjà présent via un include dans votre enregistrement.
2. Utilisez un sous-domaine. Faites envoyer un service depuis nieuws.example.com ou factuur.example.com. Ce sous-domaine recevra son propre enregistrement SPF contenant uniquement ce service, et ne comptera pas dans les dix de votre domaine principal. L'alignement dans DMARC (leçon 4.4) fonctionne aussi par défaut pour les sous-domaines.
3. Utilisez ip4: et ip6: pour vos propres serveurs fixes. Ceux-ci ne coûtent aucune recherche. Faites-le uniquement pour des adresses que vous gérez vous-même et qui ne changent pas.
4. Le flattening (remplacer tous les includes par les adresses IP qui s'y trouvent actuellement). Cela ramène le nombre à 0, mais l'enregistrement devient incorrect dès qu'un service change ses adresses, ce que font régulièrement les grands services. Ne le faites qu'avec un outil qui le met à jour automatiquement, et de préférence pas du tout.

redirect ou include ?

redirect= signifie : utilisez l'enregistrement SPF de cet autre domaine à la place de celui-ci. Cela coûte une recherche, comme un include. C'est pratique si vous avez de nombreux domaines qui doivent avoir exactement la même politique : v=spf1 redirect=_spf.example.com sur chaque domaine, et l'enregistrement réel à un seul endroit. Un enregistrement avec redirect= ne doit pas comporter de all, sinon le redirect est ignoré. Gmail l'utilise lui-même : gmail.com a v=spf1 redirect=_spf.google.com.

Étape 4 : ~all ou -all ?

La ligne de conduite recommandée dans ce cours, identique à celle du cours DNS :

• Commencez par ~all (softfail). Le courrier d'un serveur absent de votre enregistrement est considéré comme suspect, mais n'est généralement pas refusé immédiatement. Si vous oubliez un expéditeur, les dégâts restent limités.
• Passez à -all (fail) lorsque vous êtes certain que tous les expéditeurs figurent dans l'enregistrement, par exemple après avoir examiné les rapports DMARC pendant quelques semaines et constaté qu'il n'y a plus de sources inconnues.

Avec DMARC en place, la différence est plus faible qu'on ne le pense souvent. DMARC décide sur la base de « SPF ou DKIM réussi et aligné ». Un softfail revient pour DMARC à un simple « échec ». La véritable protection vient donc d'une politique DMARC stricte, et non de -all. Certains destinataires refusent déjà le courrier à cause de -all, avant même l'évaluation DMARC ; c'est une raison pour ne choisir -all que lorsque votre enregistrement est réellement complet.

Un domaine qui n'envoie jamais de courrier

Avez-vous des domaines qui n'envoient jamais de courrier (une ancienne marque, un domaine de faute de frappe) ? Protégez-les alors contre les abus avec :

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Ici, -all est tout de suite la bonne option : personne n'est autorisé à envoyer du courrier. La dernière ligne est un null MX (RFC 7505) : « ce domaine ne reçoit pas de courrier ». example.com lui-même est configuré exactement de cette façon.

En pratique : à quoi cela ressemble dans un panneau

Dans une offre d'hébergement de WebOké, l'enregistrement par défaut est v=spf1 a mx include:webawere.nl ~all. Si vous ajoutez un service, vous modifiez cet enregistrement (dans DirectAdmin : DNS Management, le crayon à côté de l'enregistrement SPF, champ Inclure le domaine ; dans Mon WebOké : l'assistant SPF sous l'onglet DNS). Conservez include:webawere.nl tant que votre courrier ou votre site web passe par ces serveurs. Chez d'autres fournisseurs, l'include par défaut porte un autre nom, mais le principe est le même : compléter, et non créer un second enregistrement.

Résumé

• Commencez par dresser un inventaire de tous les expéditeurs ; les rapports DMARC et les en-têtes y aident.
• Un service avec son propre Return-Path n'a rien à faire dans votre SPF ; il a besoin du DKIM avec votre domaine.
• Comptez de manière récursive : chaque include, a, mx, exists, ptr et redirect, y compris à l'intérieur des includes. Au-delà de dix, ou plus de deux recherches vides, c'est une permerror.
• Repassez sous la barre des dix en faisant le ménage et en utilisant des sous-domaines ; le flattening uniquement avec une maintenance automatique.
• Commencez par ~all, passez à -all quand vous êtes sûr. Domaines qui n'envoient jamais de courrier : -all, DMARC reject et null MX.

Quiz

Exercice

Exercice Z4.2 : Faire compter récursivement le SPF de votre domaine. Indiquez votre propre domaine (ou sidn.nl si vous n'en avez pas). Comptez d'abord vous-même combien de recherches DNS coûte l'enregistrement SPF, y compris tout ce qui se trouve dans les includes, et saisissez le nombre, ainsi que la fin de l'enregistrement (~all, -all, ?all ou +all). Le programme recompte en direct, recherches vides comprises, et affiche l'arborescence.

Exercice O4.2 : Votre inventaire des expéditeurs. À l'aide du tableau de cette leçon, établissez une liste de tous les systèmes qui envoient du courrier au nom de votre domaine. Indiquez pour chacun : via quel serveur ou service, s'il doit figurer dans votre SPF (Return-Path propre ou non), et s'il signe avec DKIM en utilisant votre domaine. Envoyez-vous un e-mail test depuis au moins deux systèmes et notez à partir des en-têtes le domaine du Return-Path et le domaine DKIM (d=).

Pour aller plus loin

Les étapes décrites dans ces articles s'appliquent aux panneaux de WebOké ; chez d'autres fournisseurs, le fonctionnement est comparable.

• Cours DNS gratuit 4.3: SPF : qui a le droit d'envoyer des e-mails au nom de votre domaine ?
• Guide DirectAdmin 5.7: Configurer et compléter le SPF
• Comment fonctionne l'enregistrement SPF dans le DNS ?
• Ajouter ou modifier un enregistrement SPF dans DirectAdmin
• Guide WebOké 5.5: Assistants DNS : MX, SPF, DMARC, CAA et SRV
• RFC 7208 (SPF), paragraphe 4.6.4 (limites) et 6.1 (redirect) ; RFC 7505 (null MX)