Guide · lecture 7 minutes

Passer DMARC de p=none à p=quarantine sans casser vos envois

This guide is written in French. The DNS records and values it gives are language-independent — you can follow them as they are.

Vous avez publié un enregistrement DMARC il y a des mois. Il dit p=none. Depuis, rien n'a changé : ni mieux, ni pire. C'est normal, et c'est exactement ce que cet enregistrement demandait.

La suite fait peur à juste titre. Durcir DMARC sans savoir qui envoie pour votre domaine, c'est signer pour que vos propres factures finissent en quarantaine. Voici l'ordre qui évite ça.

Ce que p=none fait, et ne fait pas

DMARC pose une question au serveur qui reçoit votre message : le domaine affiché dans le champ From est-il couvert par SPF ou par DKIM ? La politique, elle, dit quoi faire quand la réponse est non.

Avec p=none, la réponse est « rien ». Le message passe comme avant. Un domaine en p=none reste usurpable par n'importe qui, et vous n'en saurez rien tant qu'aucune adresse de rapport n'est déclarée. C'est le cas le plus fréquent sur les domaines que nous lisons : une politique publiée, aucun rua, donc aucune visibilité.

Depuis 2024, Gmail et Yahoo exigent un DMARC publié pour les envois en volume. Publié, pas forcément strict. p=none suffit à cocher la case ; il ne protège pas votre nom.

La seule question qui compte : l'alignement

SPF peut passer et DMARC échouer quand même. Ce n'est pas une contradiction : les deux ne regardent pas le même domaine.

SPF vérifie l'adresse d'enveloppe, celle du Return-Path, que votre destinataire ne voit jamais. Beaucoup d'outils y mettent leur propre domaine. SPF passe, sur leur domaine. DMARC compare ce domaine à celui du champ From, votre domaine à vous, ne trouve pas la même racine, et conclut à l'échec.

DKIM a le même piège : la signature porte un domaine, le d=. Si votre outil signe avec le sien au lieu du vôtre, la signature est valide et l'alignement échoue.

Un seul des deux suffit à faire passer DMARC. En pratique, DKIM est le plus solide : il survit à une redirection automatique, SPF non. C'est donc lui qu'il faut aligner en premier — c'est presque toujours une case « domaine d'envoi personnalisé » à activer chez votre outil, plus deux ou trois enregistrements CNAME à publier.

Avant de toucher à la politique, ouvrez les yeux

Une adresse de rapport coûte une ligne et vous donne, chaque jour, la liste des serveurs qui envoient sous votre nom. Publiez-la maintenant, et laissez-la travailler deux à quatre semaines.

Les rapports arrivent en XML compressé, un par opérateur et par jour. Illisibles à l'œil, mais vous n'avez besoin que d'une chose : la liste des adresses IP qui envoient pour vous. Chacune doit correspondre à un outil que vous reconnaissez.

Ceux qu'on oublie, dans cet ordre de fréquence :

• le logiciel de facturation
• le CRM
• le formulaire de contact du site
• les emails de réinitialisation de mot de passe de votre application
• l'outil de signature électronique
• le prestataire qui envoie la newsletter
• l'ancienne plateforme d'emailing que personne n'a résiliée

Le passage, en trois paliers

pct applique la politique à un pourcentage seulement du trafic non aligné. C'est votre garde-fou : si un envoyeur a été oublié, il ne perd qu'une fraction de ses messages, et les rapports vous le signalent avant les autres.

Palier 1, une à deux semaines. Dix pour cent des messages non alignés partent en quarantaine :

Palier 2, une à deux semaines de plus, si les rapports sont propres :

Palier 3, la politique pleine :

Restez là. p=reject est le vrai objectif, mais il ne se justifie qu'après plusieurs mois sans surprise dans les rapports : en quarantaine, un message légitime mal aligné reste récupérable dans le dossier spam ; en rejet, il est perdu.

Ajoutez sp=none si vos sous-domaines envoient encore sans être alignés : la politique du domaine s'applique par défaut à tous ses sous-domaines, y compris ceux que vous avez oubliés.

Les trois erreurs qui cassent un envoi

Durcir SPF en même temps que DMARC. Un -all ajouté le même jour, avec un envoyeur manquant dans la liste, et le message est refusé avant même que DMARC ne parle. Un changement à la fois.

Passer en alignement strict sans raison. aspf=s et adkim=s exigent le domaine exact, pas la même racine : un envoi depuis un sous-domaine cesse alors d'être aligné avec un From sur le domaine principal. Le mode souple, par défaut, est le bon choix.

Oublier les listes de diffusion. Une liste réécrit souvent le sujet et casse la signature DKIM. Si vos équipes écrivent à des listes publiques, attendez-vous à des échecs dans les rapports qui ne viennent pas de votre configuration.

Comment savoir que c'est bon

Relisez le DNS après chaque palier : la propagation peut prendre jusqu'à 48 heures, et un enregistrement dupliqué par erreur invalide DMARC entièrement.

Puis envoyez un vrai message, depuis l'outil que vous utilisez vraiment, et lisez les en-têtes reçus. La ligne Authentication-Results doit dire dmarc=pass — et vous devez savoir lequel des deux, SPF ou DKIM, l'a fait passer. C'est ce qui vous dira si vous pouvez durcir sans risque.