SPF et DMARC : stopper l’usurpation d’un domaine récepteur

Deux sens, et vous n’en avez configuré qu’un

Pointer un domaine ici ne demande qu’un seul enregistrement DNS. Cet enregistrement — le MX — répond à une seule question : où va le courrier adressé à ce domaine ? C’est tout ce dont un catch-all a besoin, et dès qu’il se résout, le domaine fonctionne. À ce moment-là pourtant, il n’est qu’à moitié configuré, car un nom de domaine sert dans deux sens, et l’enregistrement MX ne dit rien du second.

Le second sens est le plus intéressant. Rien dans le protocole de messagerie n’empêche un inconnu d’écrire votre domaine dans l’en-tête From: d’un message envoyé depuis sa propre machine. Il n’a besoin d’accéder ni à votre DNS, ni à votre bureau d’enregistrement, ni à votre boîte — l’adresse dans un message est une prétention, pas un justificatif, et elle l’a toujours été. Ce qui décide si cette prétention est crue, c’est ce que votre domaine dit de qui est autorisé à la formuler :

Le domaine qui ne dit rien

Un serveur destinataire ne trouve ni SPF ni politique DMARC, et doit se rabattre sur ses propres heuristiques : réputation, contenu, comportement passé du domaine. Un domaine tout neuf, sans historique et sans politique, est à peu près la cible idéale à usurper, car rien ne contredit l’usurpation, et il n’y a rien sur quoi rejeter la faute après coup.

Le domaine qui dit non

Ce même serveur trouve une politique publiée qui indique qu’aucune machine, nulle part, n’est autorisée à envoyer au nom de ce domaine, et que les échecs doivent être rejetés. Cela cesse d’être une question d’appréciation. Le message est refusé à la porte, généralement sans même atteindre un dossier spam.

Ce n’est pas une hypothèse d’école à propos de grandes marques. Les domaines sans courrier sortant sont choisis précisément parce qu’ils n’ont aucune politique — un nom que personne ne protège, utilisé quinze jours puis abandonné, vaut plus, pour un expéditeur de courrier indésirable, qu’un nom qui se défend.

Pourquoi vous pouvez sauter l’étape qui prend six mois à tout le monde d’autre

Si vous avez déjà lu quoi que ce soit sur DMARC, vous avez lu que c’est un projet long et minutieux. Ce conseil est juste, et il ne vous concerne pas. Il est écrit pour un domaine qui envoie du courrier, et il est long pour une seule raison : avant de pouvoir dire au monde entier de rejeter tout ce qui échoue, il faut trouver chaque système qui envoie légitimement en votre nom et le faire passer les contrôles un par un. Dans une organisation normale, cette liste est plus longue que prévu, et elle se découvre plutôt qu’elle ne se connaît d’avance :

1. Publier une politique qui ne fait rien. p=none demande aux destinataires de faire un rapport sans rien changer, afin qu’un expéditeur oublié ne puisse pas être coupé par la politique elle-même.
2. Lire les rapports pendant des semaines. Le système de facturation, le service d’assistance, l’outil de newsletter, la plateforme de recrutement à laquelle quelqu’un s’est inscrit en 2019 — chacun apparaît comme une source en échec, et chacun doit être autorisé ou mis au rebut.
3. Durcir par étapes. Passer à quarantine, attendre, observer, et seulement ensuite à reject, car chaque étape du durcissement peut arrêter silencieusement du courrier dont quelqu’un dépend.

Chacune de ces étapes existe pour protéger des expéditeurs légitimes contre votre propre politique. Un domaine pointé vers une boîte en réception seule n’a aucun expéditeur légitime. La liste n’est ni longue, ni difficile à établir, ni partiellement inconnue — elle est vide. Et une politique qui rejette tout ne peut pas casser un expéditeur qui n’existe pas.

Il existe aussi un argument de second ordre pour aller directement à l’état final. Un domaine resté sur p=none publie une politique qui ne demande rien, et un serveur destinataire le traite presque comme un domaine sans politique du tout. L’enregistrement existe, donc cela a l’air réglé — ce qui est pire qu’un chantier visiblement inachevé, car personne ne revient pour le terminer.

Les trois enregistrements

Les trois sont des enregistrements TXT, et tous les trois se placent à côté du MX que vous avez déjà. Les noms sont écrits comme la plupart des interfaces DNS les attendent — relatifs à la zone, avec @ signifiant le domaine lui-même. Si la vôtre demande un nom pleinement qualifié, écrivez plutôt yourdomain.com, _dmarc.yourdomain.com et *._domainkey.yourdomain.com.

Si votre fournisseur exige que la valeur soit entre guillemets, mettez-la entre guillemets. Certaines interfaces les ajoutent automatiquement et finissent par les stocker deux fois, ce qui produit un enregistrement qu’aucun vérificateur ne peut lire — si une valeur revient de dig entourée de deux paires de guillemets, c’est exactement ce qui s’est passé.

Les trois valeurs, prêtes à coller. Copiez-les plutôt que de les retaper : un point-virgule manquant dans l’enregistrement DMARC rend toute la liste de balises illisible par un analyseur, et une politique illisible est traitée comme une absence totale de politique.

SPF — sur le domaine lui-mêmev=spf1 -allCopier

DMARC — sur le nom _dmarcv=DMARC1; p=reject; sp=reject; adkim=s; aspf=sCopier

DKIM — sur le nom *._domainkeyv=DKIM1; p=Copier

Ce que chaque mot de ces enregistrements fait vraiment

Cinq décisions, et il vaut la peine de savoir laquelle est laquelle — surtout pour reconnaître, plus tard, celle qu’il faudra assouplir si le domaine se met un jour à envoyer du courrier.

-all

La fin de l’enregistrement SPF, et la seule partie qui compte ici. Cela signifie tout ce qui n’est pas listé ci-dessus est une usurpation, et rien n’est listé ci-dessus. L’alternative courante, ~all, signifie probablement une usurpation, mais livrez-la quand même et marquez-la — ce qui est la bonne réponse tant que vous êtes encore en train de recenser vos propres expéditeurs, et la mauvaise dès que vous êtes certain qu’il n’y en a aucun.

p=reject

Ce qu’un serveur destinataire doit faire du courrier qui prétend venir de ce domaine et échoue au contrôle. none signifie se contenter d’un rapport, quarantine signifie traiter comme suspect, reject signifie refuser pendant la conversation SMTP. Reject est le seul qui empêche totalement le message d’arriver sous les yeux d’un humain.

sp=reject

La même chose, appliquée à chaque sous-domaine — y compris ceux qui n’existent pas. Sans elle, un usurpateur utilise billing.yourdomain.com, qui n’a pas d’enregistrements propres, et n’hérite de rien pour l’en empêcher. Cette balise reprend par défaut la valeur de p, donc l’enregistrement se comporte à l’identique sans elle ; elle est écrite explicitement parce qu’une politique que vous ne voyez pas en relisant l’enregistrement est une politique que vous présumerez absente.

adkim=s, aspf=s

Alignement strict. Il exige que le domaine authentifié soit exactement celui de l’en-tête From:, et non simplement un domaine apparenté — de sorte qu’un message venant de anything.yourdomain.com ne puisse pas emprunter un laissez-passer qui appartenait au parent. Le mode souple est la valeur par défaut, et le mode strict est ce qu’un domaine qui n’a rien à autoriser devrait afficher.

v=DKIM1; p=

Une clé publique DKIM sans clé à l’intérieur. La spécification indique explicitement qu’une clé vide signifie révoquée, si bien que toute signature qui nomme un sélecteur sous ce domaine échoue à la vérification au lieu d’être ignorée. Le caractère générique couvre tout nom de sélecteur qu’un usurpateur pourrait inventer, puisque c’est lui qui choisit ce nom.

Et l’enregistrement qui doit rester exactement tel quel

Rien de ce qui précède ne touche au courrier entrant, et rien ne devrait le faire. L’enregistrement MX est ce qui fait de chaque adresse du domaine une boîte ici, et rien de tout cela ne le modifie :

Enregistrement MX — inchangé10 smtp.grabmail.ioCopier

Les trois nouveaux enregistrements et celui-ci répondent à des questions différentes, donc ils n’interagissent pas : SPF et DMARC sont lus par des serveurs qui décident s’ils doivent accepter du courrier qui prétend venir de vous, et le MX est lu par des serveurs qui décident où livrer le courrier qui vous est adressé. Un domaine doté des quatre est un domaine qui reçoit tout et ne se porte garant de personne.

Vérifier votre travail, en trois commandes

Le DNS n’est pas un endroit où l’on suppose. Chacun de ces enregistrements est publié pour être lu par des inconnus, ce qui veut dire que vous pouvez le lire exactement comme eux le liront — sans compte, sans outil, sans site où coller votre domaine :

$ dig +short TXT      yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short MX       yourdomain.com

Remplacez par votre propre domaine. Ce que vous cherchez, c’est ceci, aux autres enregistrements TXT près que vous avez peut-être déjà sur ce nom :

"v=spf1 -all"
"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
10 smtp.grabmail.io.

Quatre façons dont cela peut mal tourner, à peu près par ordre de fréquence :

La première commande ne répond rien du tout

L’enregistrement ne s’est pas encore propagé, ou il a été ajouté sur le mauvais nom. Les enregistrements TXT du domaine lui-même se placent sur @, pas sur www — une interface qui revient par défaut au dernier nom que vous avez modifié en est habituellement la cause.

Deux enregistrements SPF reviennent

Un domaine n’a droit qu’à un seul enregistrement. Deux n’est pas plus strict qu’un — c’est une erreur permanente, et un serveur destinataire qui en trouve deux considère le contrôle SPF comme cassé plutôt que comme un échec. Si vous aviez déjà un enregistrement SPF, modifiez-le au lieu d’en ajouter un second.

La ligne DMARC revient, mais rien ne l’applique

Lisez la valeur avec attention : elle doit commencer par v=DMARC1, et les balises sont séparées par des points-virgules. Un enregistrement auquel il manque la balise de version, ou dans lequel un point-virgule est devenu une virgule, n’est pas une politique plus faible — c’est une politique illisible par un analyseur, ce qui compte comme une absence totale de politique.

La réponse du MX a changé

Elle ne devrait pas avoir changé. Si la ligne MX a maintenant disparu, ou affiche un simple point, ou liste un hôte qui n’est pas smtp.grabmail.io, arrêtez-vous et remettez-la avant de faire quoi que ce soit d’autre — c’est l’enregistrement dont dépend votre boîte.

La partie que presque tout le monde oublie : les sous-domaines

DMARC et SPF ne découpent pas l’espace de noms de la même façon, et c’est dans cet écart qu’un domaine pourtant soigneusement protégé présente une brèche. sp=reject couvre réellement chaque sous-domaine, qu’il existe ou non. SPF ne fonctionne pas du tout de cette façon : il est recherché sur le nom exact figurant dans l’enveloppe, et un nom sans enregistrement SPF propre n’a pas d’enregistrement SPF — il n’hérite pas de celui du parent.

DMARC couvre déjà la deuxième ligne à lui seul, donc ceci relève de la ceinture et des bretelles plutôt que de combler une brèche — mais un enregistrement SPF générique ne coûte qu’une ligne et referme l’écart au niveau SPF aussi, ce qui compte pour les destinataires qui vérifient le SPF sans mettre en œuvre DMARC :

SPF générique — un enregistrement TXT de plus* TXT v=spf1 -allCopier

Un enregistrement DNS générique ne répond que pour les noms qui n’ont pas d’enregistrement propre. Si mail.yourdomain.com a déjà le moindre enregistrement TXT, le générique n’est pas consulté pour ce nom, et il faudrait y publier l’enregistrement SPF explicitement. Pour un domaine utilisé uniquement comme catch-all, cette situation est assez rare pour valoir la peine d’être connue plutôt que d’être anticipée.

Les rapports, et s’ils valent la peine d’être activés

DMARC a un volet rapports : ajoutez une balise rua, et les destinataires participants vous envoient un résumé quotidien de tout ce qui a prétendu être votre domaine et de ce qui lui est arrivé. C’est la seule partie de DMARC qui vous apprend quelque chose que vous ne saviez pas déjà, et sur un domaine pointé ici, cela ne coûte rien à collecter, car l’adresse de destination peut être une adresse du domaine lui-même :

DMARC avec rapports — remplacez le domainev=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.comCopier

Envoyer les rapports vers une adresse du même domaine évite un piège de la spécification qui surprend beaucoup de monde : si rua désigne une adresse sur un domaine différent, cet autre domaine doit publier un enregistrement l’autorisant à recevoir vos rapports, et tant qu’il ne le fait pas, la plupart des expéditeurs n’en enverront aucun. Même domaine, aucun enregistrement de ce genre requis, rien à rater. Ce qui arrive vaut la peine d’être connu avant d’activer la fonction :

• Ce sont des fichiers XML compressés en gzip, en pièce jointe. Pas un résumé à lire devant son café. Les petits domaines en reçoivent une poignée par jour de la part des grands fournisseurs de messagerie, chacun de quelques kilo-octets ; il vous faudra un outil pour les décompresser et les lire.
• Le vide est le bon résultat. Un domaine qui n’envoie rien devrait générer des rapports ne listant que des échecs, et une semaine calme signifie que personne ne vous usurpe actuellement — ce qui est une information, et la seule façon de l’obtenir.
• Ils arrivent comme du courrier ordinaire. Ici, cela veut dire une boîte ordinaire : lisible dans le navigateur et via l’API comme n’importe quoi d’autre, et supprimée après 5 jours avec tout le reste.

Si vous préférez ne pas les collecter du tout, omettez simplement la balise. Un enregistrement DMARC sans rua est parfaitement valide et protège tout aussi bien ; les rapports servent à savoir ce qui se passe, pas à faire appliquer la politique.

Ce que cela ne fait pas

Ces enregistrements ont une portée étroite, et être clair sur leurs limites, c’est la différence entre un contrôle sur lequel on s’appuie correctement et un contrôle sur lequel on s’appuie à tort. Quatre choses qu’ils ne couvrent pas :

Ils ne filtrent pas votre propre boîte

SPF et DMARC sur votre domaine sont des instructions destinées aux serveurs qui reçoivent du courrier en provenance de vous. Ils sont lus par les systèmes de messagerie des autres, jamais par le vôtre, et ils n’ont aucun effet sur ce qui atterrit dans le catch-all. Ce qui arrive reste tout ce que le monde envoie à une adresse dont le seul justificatif est de la connaître.

Ils n’empêchent pas un nom dans l’en-tête From:

Un message affichant Your Company <attacker@gmail.com> passe tous les contrôles, car le domaine authentifié est réellement celui de l’attaquant. DMARC protège le domaine, pas le nom d’affichage placé devant lui — et sur un téléphone, c’est souvent tout ce qui est affiché.

Ils ne touchent pas à un domaine sosie

Un domaine à un caractère du vôtre est le domaine de quelqu’un d’autre, avec les enregistrements de quelqu’un d’autre. Rien de ce que vous publiez ne l’atteint. C’est un problème de bureau d’enregistrement et de surveillance, et c’est réellement un problème différent.

Ils ne rendent pas la boîte privée

Il n’y a toujours aucun mot de passe sur une adresse ici : quiconque la connaît peut la lire, c’est le compromis que fait tout le service. Votre propre domaine élimine le fait de deviner l’adresse, pas la lecture — la version honnête de tout cela se trouve dans le guide sur les domaines catch-all.

Le faire, du début à la fin

Tout le travail, dans l’ordre qui laisse le domaine fonctionnel à chaque étape :

1. Confirmez d’abord le MX. dig +short MX yourdomain.com doit répondre smtp.grabmail.io et rien d’autre. Corrigez cela avant d’ajouter quoi que ce soit, car le reste ne sert à rien sur un domaine qui ne reçoit pas.
2. Ajoutez l’enregistrement SPF sur @, sauf s’il y en a déjà un — auquel cas modifiez-le, car deux enregistrements sont une erreur, pas un réglage plus strict.
3. Ajoutez l’enregistrement DMARC sur _dmarc, directement avec la politique stricte. Il n’y a ici aucun déploiement progressif à planifier, et rien à casser en le sautant.
4. Ajoutez l’enregistrement DKIM générique sur *._domainkey, et l’enregistrement SPF générique si vous voulez fermer la couche des sous-domaines deux fois.
5. Relisez les quatre avec dig, contre un résolveur public, une fois que le TTL a eu le temps d’expirer.
6. Envoyez-vous quelque chose. Écrivez depuis n’importe où à l’une de vos propres adresses sur le domaine, puis ouvrez la boîte. Si le message arrive, le côté réception a survécu au changement, et c’est la seule régression qui vaille la peine d’être vérifiée.

Le domaine est alors terminé : il accepte toute adresse que vous inventerez jamais dessus, et ne se porte garant de personne. Si vous n’avez pas encore connecté le domaine, commencez par le guide sur le catch-all — c’est un seul enregistrement et les mêmes cinq minutes — puis revenez sur cette page ensuite, ce qui est l’ordre qui ne laisse rien à moitié fait.

Questions