DMARC
Domain-based Message Authentication, Reporting and Conformance : authentification des courriels par leur domaine
Deux preuves et une exigence
Avec SPF, le domaine publie la liste des serveurs autorisés à envoyer en son nom ; avec DKIM, chaque message porte une signature que le destinataire vérifie grâce à une clé publiée dans le DNS. DMARC ajoute l’exigence qui manquait : l’une de ces deux preuves doit porter sur le domaine que le lecteur voit dans le champ « De ». Sans cet alignement, un attaquant peut réussir le contrôle SPF avec son propre domaine tout en affichant celui d’un autre.
Observer, isoler, refuser
La règle connaît trois niveaux : tout laisser passer en recevant les rapports (p=none), envoyer les messages douteux dans les indésirables (quarantine), les refuser (reject). Les rapports quotidiens révèlent tout ce qui envoie au nom du domaine, y compris le logiciel de facturation, la lettre d’information ou le copieur que personne n’avait déclaré. On corrige d’abord ces oublis, puis on durcit : passer d’emblée au refus bloquerait ses propres courriels.
Ce qui lui échappe
DMARC protège le nom de domaine exact, pas ses imitations : un domaine voisin, enregistré pour du typosquatting, passe tous les contrôles puisqu’il est authentique. Il ne dit rien non plus d’une boîte réellement piratée, dont les messages partent signés en règle.
Devenu une condition d’envoi
Gmail l’exige depuis février 2024 des expéditeurs qui adressent plus de 5 000 messages par jour à ses utilisateurs, et Outlook.com au même seuil depuis mai 2025. En mai 2026, l’IETF en a fait une norme à part entière (RFC 9989), après onze ans comme simple document d’information. Une fois la règle au niveau du refus, le nom de l’entreprise cesse de signer les courriels des autres.
Mise à jour : 28 septembre 2026
