Mis à jour le 6 min de lecture

Configurer DMARC progressivement sans casser vos envois

Pourquoi passer en politique reject d'un coup est risqué, et comment construire la transition étape par étape sans bloquer vos expéditeurs légitimes.

MailDMARCDélivrabilitéSécurité
Enveloppes de courrier - illustration de la délivrabilité mail

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 9989) est devenu le standard pour empêcher l'usurpation de votre domaine en mail. C'est aussi un critère que Gmail et Outlook regardent pour décider si vos mails arrivent en boîte de réception ou en spam : Gmail l'exige depuis février 2024 des expéditeurs qui envoient plus de 5 000 messages par jour (Google), et Outlook.com depuis mai 2025 (Microsoft). Mais activer DMARC trop vite, en politique reject directement, peut bloquer dès le premier jour les envois légitimes des services que vous aviez oubliés. Voici comment construire la transition.

1. Comprendre les trois politiques DMARC

DMARC se décline en trois politiques, dans l'ordre de sévérité croissante :

  • none : aucune action, juste de la surveillance. Les serveurs destinataires vous envoient des rapports d'authentification mais traitent les mails normalement.

  • quarantine : les mails qui échouent à DMARC sont mis en spam, mais arrivent quand même.

  • reject : les mails qui échouent sont purement rejetés au niveau SMTP. Ils ne parviennent jamais au destinataire.

Passer en reject directement sans audit est une cause fréquente de pannes mail silencieuses. Vous découvrez 3 mois plus tard qu'un fournisseur cloud envoyait vos notifications à vos clients depuis votre domaine, et que tout ça est bloqué depuis le début.

2. Étape 1 - SPF strict avant tout

Avant même de toucher à DMARC, posez un enregistrement SPF qui liste TOUS les services autorisés à envoyer en votre nom : votre serveur mail principal, votre prestataire transactionnel (SendGrid, Mailgun, etc.), votre CRM s'il envoie des mails (Salesforce, HubSpot), votre outil de newsletter (Mailchimp), vos services internes (alertes monitoring, etc.).

Terminer par -all (rejet strict, pas ~all qui est juste un soft fail). Si vous n'êtes pas sûr de la liste complète, partez sur ~all pendant un mois de transition puis passez à -all.

3. Étape 2 - DKIM sur tous les flux émetteurs

DKIM signe chaque mail avec votre clé privée. Le destinataire vérifie la signature avec la clé publique publiée dans votre DNS. Sans DKIM, DMARC ne peut pas aligner correctement (SPF seul est trop fragile aux transferts).

Chaque service doit avoir sa propre clé DKIM publiée sur un sélecteur dédié (ex : mail._domainkey, mailchimp._domainkey). Cela permet de révoquer une clé si un service est compromis, sans casser les autres.

4. Étape 3 - DMARC en politique none + rapports

Publiez DMARC en politique p=none avec une adresse rua= pour recevoir les rapports d'agrégation. Format typique :

v=DMARC1; p=none; rua=mailto:dmarc@votreentreprise.com; ruf=mailto:dmarc-forensic@votreentreprise.com; fo=1; aspf=s; adkim=s

Les serveurs Gmail, Outlook, Yahoo vont commencer à vous envoyer des rapports XML quotidiens. Parsez-les avec parsedmarc ou un service en ligne. Vous verrez exactement quels IP et quels domaines envoient en votre nom, et combien échouent SPF/DKIM.

5. Publier l'enregistrement chez votre hébergeur DNS

Un enregistrement DMARC est un enregistrement DNS de type TXT, publié sur le sous-domaine _dmarc de votre domaine. La démarche est la même partout : ajouter un enregistrement TXT nommé _dmarc, avec pour valeur la ligne ci-dessus. Seul l'emplacement dans l'interface change :

  • Scaleway : dans la console, section Domaines et DNS, ouvrir la zone DNS du domaine puis ajouter un enregistrement de type TXT nommé _dmarc.

  • Gandi : dans la gestion du domaine, onglet des enregistrements DNS, ajouter un enregistrement TXT de nom _dmarc.

  • Cloudflare : dans DNS, puis Records, ajouter un enregistrement TXT de nom _dmarc. Cloudflare propose aussi une fonction de gestion DMARC qui regroupe les rapports reçus.

Trois pièges reviennent souvent :

  • Saisir le nom complet (_dmarc.votreentreprise.com) dans une interface qui ajoute déjà le domaine : l'enregistrement devient _dmarc.votreentreprise.com.votreentreprise.com et n'est jamais trouvé.

  • Publier deux enregistrements DMARC pour le même domaine : les serveurs destinataires ignorent alors la politique (RFC 9989).

  • Conclure trop vite que l'enregistrement ne fonctionne pas : la propagation dépend de la durée de cache (TTL). Vérifiez avec dig TXT _dmarc.votreentreprise.com ou un outil en ligne.

6. Étape 4 - Analyser 4 à 8 semaines avant de durcir

Pendant 4 à 8 semaines, regardez les rapports DMARC. L'objectif : descendre le taux d'échec SPF+DKIM aligné sous 1% sur tous vos flux légitimes. Tant que ce n'est pas le cas, ne passez PAS en quarantine : vous bloqueriez du trafic réel.

Pour chaque flux qui échoue, deux options : (a) ajouter le service à votre SPF + activer son DKIM, ou (b) si c'est un service que vous n'utilisez plus, supprimer sa configuration.

7. Étape 5 - Quarantine puis reject

Quand le taux d'échec légitime est proche de zéro, passez à p=quarantine. La révision du standard publiée en mai 2026 (RFC 9989) a supprimé l'ancien tag pct, qui appliquait la politique à un pourcentage des mails et que les serveurs interprétaient de façon inégale. Elle le remplace par un mode test, t=y, qui demande aux destinataires d'appliquer la politique inférieure : p=quarantine; t=y est traité comme p=none, p=reject; t=y comme p=quarantine, et les rapports continuent d'arriver.

Une progression prudente : p=quarantine; t=y, puis p=quarantine, puis p=reject; t=y, et enfin p=reject, en surveillant les rapports deux à quatre semaines à chaque palier. Du p=none au p=reject, comptez typiquement 3 à 4 mois. C'est long mais c'est ce qui distingue une configuration DMARC robuste d'un site cassé pendant 6 mois sans s'en rendre compte.

8. Erreurs courantes à éviter

  • Activer DMARC reject sans avoir SPF et DKIM en place : 100% des mails seront rejetés.

  • Oublier les services tiers (CRM, transactionnel) qui envoient en votre nom.

  • Utiliser une adresse rua= qui n'est pas du même domaine que le DMARC sans publier l'autorisation prévue par le standard pour les destinations externes (RFC 9990).

  • Activer DMARC sur un domaine parking utilisé pour les mails legacy : très souvent, il y a des flux historiques que personne ne connaît plus.

  • Ne pas surveiller les rapports DMARC après la mise en reject : un nouveau service ajouté plus tard peut casser sans alerte.

DMARC ne se configure pas une fois pour toutes : chaque nouvel outil qui envoie des e-mails au nom de votre domaine doit être ajouté au SPF et signé en DKIM, sinon il réapparaît en échec dans les rapports. C'est ce suivi dans la durée que prend en charge le service anti-spam et délivrabilité. Si vous changez de messagerie, c'est le bon moment pour repartir sur une configuration propre : le guide pour quitter Microsoft 365 intègre ces étapes, et le comparatif serveur mail souverain vs Microsoft 365 aide à choisir. Besoin d'un regard extérieur sur votre configuration actuelle ? Demandez un audit gratuit.

Réalisation associée

Serveur mail managé

Postfix + Dovecot + Rspamd opérés en interne, SPF/DKIM/DMARC alignés, MTA-STS publié, délivrabilité Gmail et Outlook validée.

Voir la réalisation complète →

Un sujet à creuser ensemble ?

Audit gratuit, devis adapté à votre contexte, sans engagement.