Pourquoi DMARC p=none est insuffisant en 2026
SPF et DKIM authentifient l'envoi : ils prouvent qu'un serveur était autorisé et que le message n'a pas été altéré. Mais ils ne dictent rien au serveur destinataire. C'est DMARC qui décide : que fait le serveur de réception avec un e-mail qui échoue SPF ou DKIM ? En p=none, la réponse est « rien » — l'e-mail est livré normalement, et le propriétaire du domaine reçoit des rapports. Ce mode d'observation avait un sens en phase de déploiement initiale. En 2026, Google et Microsoft ont changé les règles : ils lisent activement la politique DMARC des expéditeurs de plus de 100 messages par jour. Un domaine resté en p=none est traité comme un domaine sans politique. Résultat : des taux de livraison dégradés, un classement préférentiel en spam, et dès que le taux de plainte dépasse 0,3 %, un throttling immédiat — le débit d'envoi est bridé côté serveur destinataire, sans erreur explicite côté expéditeur. Le seuil recommandé par Google Postmaster Tools pour rester sous le radar est inférieur à 0,1 %.
Ce que vous risquez en restant en p=none après 2026
- Throttling silencieux — Google et Microsoft brident le débit d'acceptation de vos messages dès 0,3 % de plaintes, sans bounce explicite.
- Classement systématique en spam — sans politique active, les heuristiques des grandes boîtes traitent vos envois comme non vérifiés.
- Usurpation de domaine sans protection — un tiers peut envoyer en votre nom ; sans DMARC actif, les destinataires ne peuvent pas distinguer le vrai envoi du faux.
- Rapports rua inutilisés — en p=none, les rapports arrivent mais personne ne bloque : vous observez l'abus sans l'arrêter.
- Perte de réputation d'expéditeur — une réputation dégradée prend des semaines à remonter, même après avoir corrigé la politique.
- Blocage de campagnes e-mail — les ESPs (Mailchimp, Brevo, SendGrid) refusent d'envoyer pour des domaines dont la réputation est marquée.
- Risque d'escalade vers p=reject forcé — Google peut décider unilatéralement d'appliquer une politique plus restrictive si le domaine est associé à du phishing.
Les trois politiques DMARC : p=none, p=quarantine, p=reject
| Politique | Effet sur les e-mails qui échouent | Cas d'usage |
|---|---|---|
| p=none | Livré normalement — aucune action sur le message. Rapports rua envoyés. | Phase d'observation initiale (2-4 semaines maximum). Ne convient plus aux expéditeurs actifs en 2026. |
| p=quarantine | Dirigé vers le dossier spam/quarantaine du destinataire. Rapports rua envoyés. | Étape intermédiaire recommandée : protection active, mais les faux positifs restent accessibles dans le spam. |
| p=reject | Refusé définitivement en SMTP 554 par le serveur destinataire. Rapports rua envoyés. | Objectif final : protection maximale. À atteindre après 2-4 semaines en quarantine sans faux positifs. |
Check-list SPF + DKIM + DMARC + List-Unsubscribe : 8 étapes
Vérifier l'enregistrement SPF
Assurez-vous qu'un enregistrement TXT existe à la racine de mondomaine.com et qu'il liste toutes vos sources d'envoi actives. Exemple : v=spf1 include:_spf.votre-fournisseur.com include:sendgrid.net ~all. Un seul enregistrement SPF par domaine — deux enregistrements SPF simultanés invalident les deux. Vérifiez avec dig TXT mondomaine.com ou MXToolbox.
Vérifier la signature DKIM
Chaque source d'envoi (serveur principal, ESP, outil marketing) doit signer les messages avec une clé DKIM publiée en DNS. Exemple d'enregistrement : mail._domainkey.mondomaine.com TXT "v=DKIM1; k=rsa; p=MIGfMA0…". Envoyez un message test et consultez les en-têtes : cherchez dkim=pass dans Authentication-Results. Si plusieurs sources envoient en votre nom, chacune a son propre sélecteur.
Publier un enregistrement DMARC avec adresse rua
Créez un enregistrement TXT sur _dmarc.mondomaine.com. Si vous êtes encore en p=none, la valeur de départ est : v=DMARC1; p=none; rua=mailto:[email protected]; pct=100. Si vous êtes prêt pour p=quarantine : v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100. Le champ rua est l'adresse qui recevra les rapports agrégés quotidiens. Sans lui, vous volez à l'aveugle.
Lire un rapport DMARC agrégé (format rua)
Les rapports arrivent sous forme de fichiers XML zippés. Les champs clés : source_ip (serveur émetteur), count (nombre de messages), disposition (none / quarantine / reject), dkim et spf (pass ou fail pour chaque vérification). Un rapport qui montre des source_ip inconnues avec dkim=fail et spf=fail signale une usurpation active de votre domaine. Un source_ip légitime avec un spf=fail signale que ce serveur n'est pas listé dans votre SPF — ajoutez-le avant de passer à p=quarantine.
Passer à p=quarantine après 2 à 4 semaines d'observation
Ne passez pas directement à p=reject. Le délai de 2 à 4 semaines en p=none puis en p=quarantine sert à identifier les sources légitimes oubliées : une liste de diffusion externe, un outil CRM, une newsletter d'un sous-domaine. Passer directement à p=reject sans cette phase risque de bloquer vos propres envois si une source légitime n'est pas couverte. Mettez à jour le DNS : v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100.
Ajouter l'en-tête List-Unsubscribe one-click (RFC 8058)
Depuis 2026, Gmail et Outlook exigent des expéditeurs de plus de 100 e-mails/jour que leurs messages de type liste (newsletters, campagnes) incluent l'en-tête HTTP List-Unsubscribe-Post: List-Unsubscribe=One-Click. L'en-tête complet a deux parties : List-Unsubscribe: <https://mondomaine.com/unsubscribe?id=abc123> et List-Unsubscribe-Post: List-Unsubscribe=One-Click. Sans cela, Google affiche un bouton de désabonnement généré automatiquement — moins précis — et peut dégrader votre score d'expéditeur. La plupart des ESPs le gèrent automatiquement ; vérifiez que votre configuration l'active bien.
Surveiller le taux de plaintes dans Google Postmaster Tools
Google Postmaster Tools (postmaster.google.com) donne accès au taux de spam de votre domaine, à la réputation d'expéditeur et à la livraison. Créez un compte, vérifiez votre domaine par enregistrement DNS TXT, et surveillez quotidiennement le tableau « Spam rate ». Objectif : rester sous 0,1 %. Entre 0,1 % et 0,3 %, risque de throttling. Au-dessus de 0,3 %, throttling immédiat selon les directives Google 2026.
Passer à p=reject une fois la quarantaine stabilisée
Après 2 à 4 semaines en p=quarantine sans faux positifs dans votre dossier spam et sans source légitime inconnue dans vos rapports rua, passez à p=reject : v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100. Ce niveau protège votre domaine contre le phishing et satisfait les exigences les plus strictes. Continuez à surveiller les rapports rua mensuellement.
Lire et analyser un rapport DMARC agrégé
Un rapport DMARC agrégé est un fichier XML envoyé quotidiennement à l'adresse rua= de votre enregistrement. Chaque rapport couvre 24 heures d'envoi depuis votre domaine, tel que vu par le serveur destinataire (Gmail, Outlook, etc.).
Structure d'un enregistrement de rapport :
<record>
<row>
<source_ip>198.51.100.42</source_ip>
<count>1247</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
</record>Lisez les rapports en cherchant trois cas :
- dkim=pass + spf=pass sur vos IP connues : vos envois légitimes passent correctement.
- dkim=fail + spf=fail sur des IP inconnues : usurpation active — vos rapports documentent que quelqu'un envoie en votre nom sans autorisation.
- dkim=fail sur une IP connue : cette source envoie en votre nom mais n'est pas couverte par une clé DKIM — corrigez avant de passer en p=quarantine.
Des outils comme dmarcian.com ou MXToolbox DMARC Analyzer lisent et agrègent automatiquement ces fichiers XML pour rendre le suivi opérationnel.
Tester avant de changer la politique
mail-tester.com envoie un e-mail de test et rend un score sur 10 accompagné d'un rapport détaillé : SPF, DKIM, DMARC, listes noires, score de contenu. Utilisez-le avant et après chaque changement de politique. MXToolbox DMARC Check vérifie directement l'enregistrement DNS sans envoi. Ces deux outils suffisent pour diagnostiquer 95 % des problèmes de délivrabilité liés à l'authentification.
Dépannage : quatre cas fréquents
DMARC échoue mais SPF et DKIM passent individuellement. L'alignement DMARC exige que le domaine dans l'en-tête From corresponde au domaine vérifié par SPF ou DKIM. Si vous envoyez depuis [email protected] mais que votre ESP signe DKIM avec autresdomaine.com, SPF et DKIM passent chacun — mais DMARC échoue par non-alignement. Corrigez en configurant votre ESP pour signer DKIM avec votre domaine (mondomaine.com) ou en ajoutant l'IP de l'ESP à votre SPF du domaine expéditeur.
Rapport rua vide après 48 heures. Vérifiez que l'adresse rua appartient au même domaine que l'enregistrement DMARC (ou publiez un enregistrement d'autorisation sur le domaine externe). Gmail et Outlook n'envoient de rapports que si votre domaine envoie suffisamment de trafic vers eux — en dessous d'un certain volume, aucun rapport n'est généré.
Taux de plaintes en hausse malgré DMARC actif. DMARC protège l'authentification, pas le contenu. Si les destinataires cliquent sur « Spam », la politique DMARC n'y peut rien. Vérifiez la fréquence d'envoi, la pertinence du contenu, et l'état de l'en-tête List-Unsubscribe one-click : sans désabonnement facile, les destinataires utilisent le bouton spam comme alternative.
List-Unsubscribe one-click non reconnu par Gmail. Gmail exige la forme HTTP POST (RFC 8058) : l'en-tête List-Unsubscribe-Post: List-Unsubscribe=One-Click doit accompagner l'URL. Un lien de désabonnement seul en mailto: ou en HTTPS sans le champ List-Unsubscribe-Post n'est pas reconnu comme one-click. Consultez la documentation de votre ESP pour activer cette option.
De p=quarantine à p=reject : la route
Passer de p=quarantine à p=reject est la dernière étape — et la plus facile si les précédentes ont été bien menées. À ce stade, tous vos envois légitimes passent SPF et DKIM, vos rapports rua ne montrent plus de sources inconnues, et votre taux de plaintes est inférieur à 0,1 %.
Le changement est un simple remplacement de valeur dans l'enregistrement DNS : p=quarantine devient p=reject. Le TTL standard des enregistrements TXT DNS est de 3600 secondes (1 heure) : prévoyez une propagation de 1 à 4 heures selon les résolveurs.
Pourquoi ne pas passer directement à p=reject sans passer par p=quarantine ? En p=quarantine, les faux positifs arrivent dans le spam du destinataire — ils sont accessibles et réclamables. En p=reject, ils sont rejetés définitivement en SMTP : ni l'expéditeur ni le destinataire ne peuvent les récupérer. La phase intermédiaire sert de filet de sécurité pour identifier les dernières sources légitimes mal configurées.
Après le passage à p=reject, continuez à consulter Google Postmaster Tools une fois par semaine pendant le premier mois, puis mensuellement. Une rotation de clé DKIM ou un nouvel ESP ajouté sans configuration DKIM peut rompre silencieusement l'alignement.
