Simulateur d’avancement de politique DMARC — chemin sécurisé vers le rejet

Votre parcours sécurisé de DMARC p=none à p=reject

Simulateur gratuit d’évolution de la politique DMARC. Entrez votre domaine et visualisez le parcours exact de déploiement, à risque réduit, de la surveillance à l’application complète — avec la progression pct= recommandée et le temps de stabilisation à chaque étape.

Comment fonctionne l’évolution de la politique DMARC ?

L’application de DMARC est le processus qui consiste à faire évoluer votre politique de p=none (surveillance uniquement) à p=quarantine (les e-mails en échec sont envoyés dans le dossier spam), puis à p=reject (les e-mails en échec sont entièrement bloqués). Chaque étape doit être introduite avec précaution — un passage direct et agressif à p=reject sans vérifier que tous les expéditeurs légitimes sont alignés entraînera des échecs immédiats de livraison pour la paie, la facturation, les réinitialisations de mot de passe et les campagnes marketing.

Le délai typique est de 10 à 16 semaines entre la publication de p=none et l’atteinte de p=reject; pct=100. Les grandes entreprises avec des environnements d’envoi complexes prennent souvent 4 à 6 mois en raison du nombre d’ESP tiers, de plateformes marketing et d’applications héritées qui doivent être inventoriés et alignés. Skysnag Protect réduit ce délai à 30 jours en automatisant la découverte des expéditeurs et leur alignement.
Techniquement oui, mais presque personne ne devrait le faire. Passer directement de p=none à p=reject sans visibilité via les rapports agrégés garantit que certains e-mails légitimes — généralement un système RH peu connu, un fournisseur de paie tiers ou un outil interne — échoueront à la livraison. Le déploiement progressif existe précisément pour identifier ces cas avant qu’ils ne provoquent un incident en production.
La balise pct= indique aux destinataires d’appliquer la politique DMARC uniquement à ce pourcentage de messages en échec. Par exemple, p=quarantine; pct=10 met en quarantaine seulement 10 % des messages en échec — les 90 % restants reviennent à la politique précédente (p=none). C’est le mécanisme clé pour un déploiement sécurisé, permettant d’identifier les cas limites avec un impact limité avant d’aller plus loin.
Les cas les plus fréquents sont : des expéditeurs tiers mal configurés au niveau de l’ESP (signatures DKIM manquantes), des enregistrements SPF dépassant la limite de 10 requêtes (PermError), des e-mails transférés via des listes de diffusion sans signature ARC, et des applications héritées qui usurpent l’en-tête From:. Corrigez ces problèmes pendant la phase de surveillance avant de passer à quarantine.
Oui. SPF ne survit pas au transfert des e-mails, car l’expéditeur de l’enveloppe SMTP change lorsque le message passe par des listes de diffusion, des alias ou Google Groups. Les signatures DKIM survivent au transfert, car elles sont des signatures cryptographiques appliquées au message lui-même. SPF et DKIM doivent tous deux être actifs et alignés pour une application robuste.
p=quarantine indique aux destinataires de filtrer les e-mails non conformes vers le dossier spam. p=reject indique aux destinataires de rejeter ces e-mails avec une erreur SMTP — le destinataire ne les voit jamais. Reject offre une protection plus stricte et constitue l’état requis pour l’éligibilité au BIMI ainsi que pour la coche bleue de Gmail.