Passer de rapports DMARC à une politique de rejet est une décision d'exploitation. La documentation Google actualisée en octobre 2026 recommande toujours une progression : utilisez vos rapports existants pour prouver que chaque service légitime survivra au changement.
1. Transformer les rapports en inventaire
Attribuez un propriétaire à chaque source : messagerie, facturation, CRM, formulaires et prestataires. Couvrez un cycle métier complet, y compris les envois mensuels ; quelques journées calmes ne suffisent pas.
Dans le XML agrégé, relevez source_ip, count, header_from et policy_evaluated. Comparez ces résultats d'alignement avec les domaines SPF/DKIM de auth_results. Un SPF pass sur le domaine du prestataire ne garantit pas DMARC pass pour votre domaine.
Pour examiner un rapport décompressé, avec un outil XML à jour et sans accès réseau :
xmllint --nonet --format report.xmldig +short TXT _dmarc.example.comN'activez pas la résolution d'entités externes. Les rapports peuvent contenir des informations sur vos infrastructures : limitez leur accès.
| Observation | Action avant durcissement |
|---|---|
| Service connu, DMARC fail | Corriger DKIM ou le domaine de retour |
| IP inconnue | Identifier le propriétaire, sans l'autoriser automatiquement |
| SPF fail après transfert, DKIM aligné pass | Vérifier le DMARC final chez le destinataire |
2. Corriger avant de changer la politique
Demandez au prestataire une signature DKIM alignée avec From ou un domaine de retour SPF aligné. Rejouez factures, invitations et réponses automatiques. Vérifiez les circuits de transfert et les listes qui modifient le contenu.
Publiez un seul TXT DMARC. Exemple de zone, avec une boîte de rapports réellement créée :
_dmarc.example.com. 300 IN TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc@example.com")Les chaînes sont concaténées en un seul enregistrement. Dans une interface DNS, saisissez leur valeur réunie.
Plan proposé : none pour observer, quarantine avec un faible pct pour une première étape, augmentation contrôlée, puis reject. Le pourcentage concerne le traitement des messages en échec, pas un pourcentage garanti de votre trafic total ; les destinataires gardent leurs décisions locales.
3. Autoriser reject sur des preuves
Avant chaque étape, exigez un test réussi pour chaque service et une explication des échecs connus. Consignez la date, l'ancienne valeur DNS et le responsable du retour arrière.
_dmarc.example.com. 300 IN TXT ( "v=DMARC1; p=reject; pct=100; " "rua=mailto:dmarc@example.com")Vérifiez aussi les sous-domaines et leurs politiques propres. Continuez les rapports après activation. En incident, restaurez la politique précédente, en tenant compte des caches DNS : cela ne récupère pas les messages déjà rejetés.
Erreurs courantes
Autoriser toute IP aperçue dans un rapport, oublier un outil de paie et durcir simultanément l'alignement vers strict rendent le changement difficile à maîtriser.
FAQ
Faut-il SPF et DKIM alignés pour passer DMARC ? Un mécanisme valide et aligné suffit ; disposer des deux améliore la robustesse.
Reject bloque-t-il tous les phishing ? Non : domaines ressemblants et comptes compromis restent possibles.
Vérification finale
Chaque expéditeur est identifié, les chemins indirects sont testés, les sous-domaines sont examinés et la procédure de repli est prête.