Mettez vos domaines en conformité, et sachez qui écrit en votre nom
N'importe quel serveur peut expédier un message en se présentant sous votre domaine : rien, dans le protocole d'origine, ne l'en empêche. SPF, DKIM et DMARC, déclarés au niveau de votre DNS, donnent aux serveurs destinataires le moyen de vérifier cette identité — et la règle à appliquer quand elle ne tient pas. C'est la gestion d'une politique DMARC, habituellement gérée par des outils tiers. Et comme on aime bien être en avance, e-securemail est déjà prêt à implémenter DMARCBis et DKIM2.
Demander une démoCe qui se joue entre l'envoi et la réception
DMARC — Domain-based Message Authentication, Reporting & Conformance — ajoute deux choses à SPF et DKIM : une instruction pour le serveur destinataire lorsque l'authentification échoue, et un rapport qui vous revient sur ce qu'il a effectivement vu passer.
1. Deux messages, un seul domaine
Le vôtre, expédié par vos serveurs légitimes. Et celui d'un usurpateur, expédié d'ailleurs mais signé de votre nom de domaine.
2. Le destinataire interroge votre DNS
Google, Microsoft, Yahoo et les autres vérifient MX, SPF et DKIM, puis lisent la politique DMARC que vous avez publiée.
3. Livraison, puis rapport
Le message légitime arrive. L'autre est laissé, mis en quarantaine ou rejeté selon votre politique. Un rapport XML — le RUA — repart vers l'adresse que vous avez déclarée.
Trois politiques, à adopter dans cet ordre
Ce ne sont pas trois options à choisir, mais trois étapes d'un même réglage. On observe d'abord, on bloque ensuite.
p=noneObserver sans rien bloquer
Aucun message n'est écarté. Vous recevez les rapports agrégés, qui ne contiennent que des volumes, des adresses IP et des verdicts d'authentification — sans exemples de messages, donc sans données personnelles. C'est l'étape où l'on découvre qui envoie en votre nom.
p=quarantineMettre en quarantaine
Les messages non authentifiés sont traités comme suspects et rangés en quarantaine plutôt que livrés. Ils restent consultables : c'est le filet de sécurité qui permet de rattraper une source légitime oubliée.
p=rejectRejeter
Le serveur destinataire refuse le message. Plus personne ne peut se présenter sous votre domaine. C'est l'objectif — mais seulement une fois toutes vos sources légitimes identifiées et alignées.
L'ordre compte
Publier p=reject sans avoir inventorié vos émetteurs — CRM, outil de facturation, plateforme d'emailing, prestataire de newsletters — revient à faire rejeter vos propres messages par vos clients. Les rapports servent précisément à établir cet inventaire avant de durcir la politique.
Émetteur, et pas seulement lecteur
En plus d'intégrer les remontées de rapports DMARC dans la console d'administration e-securemail, Secuserve est le premier éditeur SaaS français de sécurisation de la messagerie à devenir émetteur de rapports DMARC.
Les domaines que nous protégeons émettent donc à leur tour des rapports vers les domaines dont ils reçoivent du courrier. La boucle de contrôle ne s'arrête pas à nos clients : elle profite aussi à leurs correspondants.
Du XML brut à quelque chose de lisible
Un rapport DMARC est un fichier XML expédié par les grands opérateurs de messagerie. e-securemail les collecte, les enrichit et les restitue en tableaux et graphiques.
- L'alignement SPF et l'alignement DKIM, en proportion de messages conformes
- L'action réellement appliquée par les destinataires : none, quarantine ou reject
- Les rapporteurs — quels opérateurs vous renvoient ces rapports, et pour quel volume
- L'origine géographique des messages expédiés sous votre domaine
- La volumétrie par domaine d'expédition
Qui envoie en votre nom
La vue par source liste chaque émetteur qui utilise vos noms de domaine. Pour chaque ligne : la date, l'organisme qui a rapporté, l'expéditeur et le destinataire, le pays, l'adresse IP, et le verdict SPF, DKIM et DMARC.
C'est là qu'on repère l'adresse IP inconnue qui expédie sous votre domaine — et surtout qu'on distingue le prestataire légitime mal configuré, à corriger, de la tentative d'usurpation, à bloquer. Les deux produisent le même échec d'authentification ; seul le contexte les sépare.
Des rapports sans données personnelles
Les rapports agrégés se demandent sans exemples de messages. Ce qui remonte se limite alors à des volumes, des adresses IP et des verdicts d'authentification.
L'absence de DMARC complique la démonstration de conformité pour les organisations qui manipulent des données personnelles ou sensibles. Mais l'inverse mérite autant d'attention : une collecte réglée sur les rapports d'échec détaillés ferait remonter des extraits de messages réels. Le type de rapport demandé n'est pas un détail technique.
Le DNS est au cœur de votre délivrabilité
SPF, DKIM et DMARC ne sont pas les seuls enregistrements en jeu. La plateforme surveille l'ensemble de la conformité DNS d'un domaine, et le périmètre s'étend au fil des versions.
e-securemail modifie les messages qu'il relaie — bandeaux d'alerte, mentions légales, liens réécrits. Une modification en transit casse normalement les signatures d'origine : la solution implémente donc le protocole ARC, qui conserve le résultat d'authentification constaté avant relayage.
Le suivi s'accompagne d'alertes et de conseils de configuration, avec l'assistance de nos équipes pour la mise en place des enregistrements.
Prêts à tester e-securemail sur votre messagerie actuelle ?
Nos experts analysent votre configuration actuelle et vous proposent une démonstration adaptée à votre messagerie.