Erreurs à éviter en écrivant un DMARC
Un enregistrement DMARC est court, mais quelques erreurs bloquent vos propres e-mails ou vous laissent aveugle. Les voici, avec la façon de les éviter.
p=reject dès le premier jour
Pourquoi. Lettres d’information, factures ou support pas encore alignés sont refusés d’un coup, et vous l’apprenez par vos clients.
Correction. Commencez en p=none avec une adresse rua, et n’avancez que quand les rapports montrent toutes les sources légitimes en réussite.
L’enregistrement au mauvais nom
Pourquoi. Publié sur le domaine lui-même, ou en _dmarc.exemple.fr.exemple.fr parce que l’interface ajoute la zone : les outils disent alors « No DMARC record found ».
Correction. Nommez-le seulement _dmarc ; l’interface ajoute le domaine. Vérifiez-le avec le vérificateur DMARC après publication.
Une adresse de rapports sans mailto:
Pourquoi. rua=dmarc@exemple.fr n’est pas valide : les destinataires n’envoient aucun rapport.
Correction. Écrivez rua=mailto:dmarc@exemple.fr. Le générateur ajoute mailto: pour vous.
Des rapports vers un autre domaine sans son autorisation
Pourquoi. Les destinataires n’envoient des rapports vers un autre domaine que s’il a publié <votre domaine>._report._dmarc.<son domaine> : sinon ils sont abandonnés sans bruit.
Correction. Utilisez une adresse de votre propre domaine, ou un service qui publie l’enregistrement d’autorisation pour vous.
Rester en p=none pendant des années
Pourquoi. L’enregistrement existe et les rapports arrivent, mais les e-mails falsifiés sont toujours distribués : les outils signalent « DMARC policy not enabled ».
Correction. Quand les rapports sont propres, passez à quarantine, puis à reject. Perimetry Cloud vous dit quand chaque étape est sans risque.
Un alignement strict trop tôt
Pourquoi. adkim=s ou aspf=s fait échouer les services qui signent ou envoient avec un sous-domaine, comme mail.exemple.fr, alors qu’ils sont bien à vous.
Correction. Gardez l’alignement souple jusqu’à ce que les rapports montrent que chaque source utilise le domaine exact.